To resolve this problem, either remove the reference ", Version=4.0.0.308, Culture=neutral, PublicKeyToken=fda5729e2db3a64f, processorArchitecture=MSIL" or retarget your application to a framework version which contains "System.Runtime, Version=2.6.10.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". The primary reference ", Version=4.0.0.308, Culture=neutral, PublicKeyToken=fda5729e2db3a64f, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the framework assembly "System.Runtime, Version=2.6.10.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. NET 4.0 as the target framework reports a mismatch as it uses 2.6.8.0: Prepping a new plugin release using alpha 5 CoreAudio here but seems there's reference to: Or during the reloading of device lists in library internally it does it too quickly during reconnects and requires a longer delay for certain sources (HDMI audio in this case) GetDevices call however that is more of workaround than an actual fix. Possible solution in AudioSwitcher library might be to always reload the CoreAudio class in case of unknown devices during. In the case of MP1-Audioswitcher I have to reload the CoreAudio class like so as otherwise it would need an Mediaportal a9d22e5.Restart AudioSwitcher app and it will no longer list the unknown device.AudioSwitcher app will now list an device named "unknown" which can be set as active and is indeed the HDMI audio device just not with the proper name however with same device.id.Will still list HDMI audio device correctly.Let the AVR go into standby or power off so that it does passthru HDMI signal.Make HDMI audio device the default (Denon AVR in my case).Noticed this unknown device bug for a while in the AudioSwitcher windows app and in my MP1-Audioswitcher (Mediaportal plugin) recently as well.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |