And on a side note about automatic deletions on Windows I had another interesting incident a month ago. I was using Robocopy to transfer archived stuff to a new disk and noticed warnings in the log that it didn't particularly like some old exes. Not to worry I thought, and made a note to copy them manually afterwards. But looking later revealed that not only had Robocopy/Windows left them out from the copy, but had also removed them from the source disk. Now this was not a big deal for me (deleted exes were primarily flash utilities for phones I no longer own) but still a very annoying behaviour not to have control over what you may store on your own disks!
Guys, the script is an add-on for a Windows Media Center installer and the file named fs-readme.txt says the following: Code: It needs to be placed in the same folder as the WMC installer because, like most of my other scripts, it isn't self-contained and relies on files that exist in the installer folder. Unzip it into the installer folder so that all the CMD files are in the same folder and all the BAT files are in the folder below.
Well when you say it that way, it's as though only an idiot wouldn't have seen that. Thanks for the correction to my mistake, and I'm sure the next Windows 10 2004 update will go without a hitch now.
Hmm, just applied the usual patch Tuesday stuff to my 1809 playback box and got a Decoder Error so something reverted one of the DLLs to the new busted ones that aren't compatible with old recordings. Just checked the recording machine and it's similarly got a Decoder Error. Ran my DLL fixer and playback succeeded, no doubt one of technodevotee's fixes will work for others. Sorry if this is covered already but posts here don't seem to predate patch Tuesday and I'm not seeing others complain of Decoder Errors. AFAIK that's the first time we've seen normal security patches bork WMC. I have a note to myself about maybe denying the trusted installer permission to the those DLLs, guess it might be time to act on it...
I've had to roll back one or other of the DLLs a number of times. As you say, it is easy enough to do and this time, it was just msvidctl on 1909.
Thanks to Kevin's work, you are immune to that problem on 8.8.4. Proves that it works though doesn't it.
Yeah, I've noticed if you ever run SFC the DLLs revert. Have you tried stashing "our" DLLs in the WMC directory? Windows used to go to great lengths to keep versions of DLLs for different processes with the same names separate from each other, kinds a paradoxical that MS itself should be a cause of another instance of it. I was thinking perhaps having the DLL in that WMC directory would be preferentially used but I guess if the function that loads the DLL for the WMC process includes the path that probably won't work.
Discovered a typo in the script of my updated utility 'roll_back_dlls' that means the changes weren't working properly. Embarrassingly, there was also an error in 'fix_thumbnails'. Please download the utilities again. Sorry about that.
is there an easy button to get WMC working on 2004 yet? I just upgraded one of my media PCs, attempted to install 8.8.4 & v13 with no success. The install finishes, but WMC will not launch. I've had success running this in every other version of W10.
@DanPFW, You need to reinstate MSSQLLite. There is a tool to do it in V13 and you can download the tool from my website for other installers.
I've downloaded replace_dlls.zip, roll_back_dlls.zip, fix_mssqllite.zip. I thought it was included in one of the first two?
it is in roll_back_dlls now but unfortunately there was a typo in it and it didn't work so I uploaded a fixed version. fix_mssqllite should work though
Yeah, I just goosed the sacrificial laptop into installing 2004 and switched it to using 8.8.4 and sure enough it needs fix_mssqllite so my guess is Kevin's got more DLL Hell in his future...