Hi Technodevotee, Kevin I had time to test tonight. Reimaged my old desktop to 1903 Windows 10. Deleted existing partition left unallocated (so not an upgrade). Network cable out while reimaging / going through setup so no chance to update windows so a check of my machines winver was 18362.239 after installing and I held it at this using a group policy edit. I did this as there was some talk earlier I forgot from who where they had managed to get it to work unsure how and then windows 10 got some updates and killed it. I downloaded the 8.8.4 provided above then installed DVLink 6.0 version as per video above went through tuning wizard found all my channels when I went to click on any to play from the guide got nothing which was my experience last time I tried a version above 8.8.1 Followed your advice and swapped out the ehsehell.exe for the one from my working 1809 windows 10 machine which was installed using 8.8.1 and now circle went round but got the message about windows not seeing any tuner cards. Umm a bit further but no joy rebooted still the same. Umm decided to manually drop the older encdec.dll in system32 folder was surprised when it did not ask me to overwrite as I thought 1803 onwards was missing it so the 8.8.4 installer should put it back but there was no encdec.dll there but dropped my earlier version in place. Swapped out msvidctl.dll for earlier one and made the reg change manually restarted and now video is playing, also via a remote desktop connection which I have never seen before! Good work Kevin! I decided to let all updates go through and the winver went up to 18362.295 but it carried on working / playing channels. Quick question have you tried seeing if you can play non dvblink channels i.e. forget about DVBLink and use Media Center to tune channels in the old way letting media centre tune using you physical tuner cards. If that doesn't work this issue isn't based around DVBLink at all if it fails using standard tuners in the old way? Best Regards Gareth
The problem I was investigating is specific to DVBLink. WMC 8.8.4 itself works fine on 1903 with no additional work required. Replacing parts of WMC including ehshell.exe was a way of proving where the problem lies with regard to the interaction between WMC after 8.8.1 and DVBLink rather than a recommended way of fixing it. Replacing ehshell.exe to get DVBLink working obviously undoes some of the changes that were made to make it work without any additional work and as you found, that means rolling back MSVidCtl. I had already done that at the beginning of my investigations. You could use it as a temporary fix to save uninstalling / reinstalling WMC but you might just as well stick with 8.8.1 and do all the workarounds (you can use my add-ons or utility to make it easier).
Hi Kevin, I actually tried this approach to create application manifests for the dvblink_client.exe file back in November 2018. The manifest was embedded inside the dvblink_client.exe file. The dvblink_client.exe file was Authenticode signed. So, my approach was like this: * Remove the Authenticode signature from the exe file. * Delete the embedded manifest resource. * Put a new manifest file next to the exe file. However, when I did this, the DVBLink Windows Service refused to start without any helpful error messages. Then I tried to re-sign the exe with a valid and trusted Authenticode certificate, but it still would not start. I might have missed something, or the service was explicitly checking that it was signed with a particular certificate. I don't know. I did not have time to pursue that path anymore than that, so currently I am using 8.8.1 (with MSVidCtl.dll, EncDec.dll and CPFilters.dll manually rolled back in System32) on 1903 and everything works.
Starting with 8.8.2, ehshell.exe no longer includes an embedded application manifest so that we can have a separate .manifest file, which is easier to tweak for those interested. Replacing it by an older version simply forces Windows to ignore the external manifest and prevent it from loading the local MSVidCtl/EncDec/CPFilters. Removing the 3 assembly manifest references from ehshell.exe.manifest would have exactly the same effect. It's a real mystery, tho', as the local DLLs should be identical to the system-wide ones if you replace them in System32 Using API monitor would certainly help determine what's causing the error. Could that be due to an invalid manifest?
Yes, maybe. It was nine months ago, so I don't remember all details and the test system is long gone. Maybe I'll give this approach a new go sometime later. Could you please point me to that API monitor tool that you mention?
I use files from 1709 in all my replacer scripts because that was the last version of Windows 10 where everything worked perfectly in WMC 12 (the basis for V13). I'm not sure which version(s) you use, which is why I replaced them with mine.
MSVidCtl and EncDec were extracted from Windows 8.1 Pro and CPFilters from Windows 10 1809 (for some reasons, it didn't work with the one from 8.1).
I don't know if it is a DLL version issue or what but there was another user on TGB who said he was getting 'all tuners are in use' with 8.8.4 on 1903 so I recommended he tried my roll_back_dlls utility and it is working now. What is really odd to me is how each of the cases seems to be a different issue. Three different users, three different issues - there's no pattern to it.
The utility only replaces the DLLs in system32 but WMC shouldn't even be using those should it? I was thinking about a modification to offer the option of replacing the ones in ehome or maybe a different version but how many people have installed 8.8.4 and it works perfectly and how many have had problems with it? I've got four PCs with completely different motherboards and completely different tuners and 8.8.4 works fine on all of them. One won't run full screen but I think that is something to do with the Intel Graphics because it is the same with every version I've tried so I just use j.c.f's launcher.
Normally no, but you said you restored the ehshell.exe from 8.8.1, which has exactly this consequence: it ignores the local DLLs. So I suggest keeping the 8.8.4 executable and replacing the local DLLs from Windows 8.1 by the ones you use from 1709, just to see if it makes any difference.
Are we at cross purposes here - are we talking about general issues or are we talking about the issue with DVBLink? One of the first things I tried when troubleshooting the issue with live TV on DVBLink was to replace the DLLs in ehome with the ones from 1709. What I haven't tried is doing the same thing when other people (not using DVBLink) report issues. I was going to try making another version of utility that offer a choice of which DLLs to replace depending on what version of files it finds.
Hi Gareth Thanks for posting this, it's about time for me to change design on WMC. Best regards Michael
Looks like I need to re-enable my insider updates! Can I ask which other versions you tried? Did you try V13 with the workarounds? It is interesting that it is kernelbase because we've seen issues with that when metadata downloading is enabled in WMC.