Thanks for getting back to me. I've done a little bit more research and I think I was partially wrong earlier. The bug isn't reversed. It now appears to occur either way, but with slightly different characteristics.
1. If RequestAllRecordings=True, then the bug appears after a reboot until you do a library update at least once. If you do at least one library update anytime after rebooting, you're fine going forward. All new recordings will play just fine as long as the show up AFTER one library update. Note: It may be necessary to do the library update AFTER the bug manifests itself, i.e. a recording fails. I haven't tested this precisely yet.
2. If RequestAllRecordings=False, then the bug appears everytime a new recording shows up. A library update, or playing an older recording, appears to cure the bug for new recordings that are actually there at the time you do the library update, but newly added recordings will continue to have the problem. With this setting, you have to continually library update when new recordings appear.
#1 is an easy fix, since doing just one library update after a reboot is an easy work-around. That is probably why I haven't encountered the issue before. Yesterday, I turned on a new machine for use just as an PVR box only and never did a single library update. I encountered the bug. My guess is that it was always there, but on my other machines, I've always done a library update at least once before watching live TV and so I never encountered it.
I'm going to do some more experimentation on this and will report back.
(2014-09-28, 18:48)krustyreturns Wrote: If the active files are showing up in the recordings list and you have RemuxActiveRecordings set to false, you should be able to play there files without remux. Also I think the skip timers work fine for active recordings (so long as the remux has time to get ahead in the file).
As to why the bug is working in reverse, scarecrow did make some server/client notification changes, so he may know.