jirim100 Posted January 2, 2023 Posted January 2, 2023 My PC sometimes crash - BSOD - during resuming from sleep mode. After BSOD automatically restart PC and then -> c:\ProgramData\CMUV\DVBViewer\Config\svctimers.xml is empty. This is very annoying as I'm not at the PC right at this time and it means that some of the scheduled recordings won't be recorded. The fact that the file svctimers.xml is empty after BSOD is probably due to the fact that the Media Server keeps it open? This is only my theory. Could MediaServer please write a copy of somewhere after every change in svctimers.xml, and every time the MediaServer service is started, would it check if there is valid data in svctimers.xml, and if not, would it copy the data from the backup into svctimers.xml? The validity of the data in svctimers.xml could be done in such a way that if a timer with a newer time was stored in the backup, this would mean using the data from the backup. This problem can probably be simulated by suddenly shutting down the PC. PC Win10 21h2, MediaServer 3.2.0.1 1 Quote
Webturtle Posted January 2, 2023 Posted January 2, 2023 Hello, I also had the same problem with timers.xml and timers.bak in DVBViewer Pro and with Epg.dat with the downloaded EPG data. Many greetings Webturtle Quote
Griga Posted January 4, 2023 Posted January 4, 2023 (edited) On 1/2/2023 at 2:58 PM, jirim100 said: My PC sometimes crash - BSOD - during resuming from sleep mode. After BSOD automatically restart PC and then -> c:\ProgramData\CMUV\DVBViewer\Config\svctimers.xml is empty. (...) Could MediaServer please write a copy of somewhere after every change in svctimers.xml, and every time the MediaServer service is started, would it check if there is valid data in svctimers.xml, and if not, would it copy the data from the backup into svctimers.xml? On 5/22/2022 at 12:58 PM, Griga said: It would be better to eliminate the reason instead of implementing a work-around for the symptoms in the DMS. Basically the same as here applies. There are always users that want an additional option for an individual problem or preference.... On 1/2/2023 at 2:58 PM, jirim100 said: The fact that the file svctimers.xml is empty after BSOD is probably due to the fact that the Media Server keeps it open? No. It can be checked easily. Try to move the file to another directory while the DMS is running. Windows won't allow it if the file is still opened by an application. The critical moment is when the file gets (re)written. Usually Windows uses a write cache, which means, the data is not transferred to disk immediately, but first to a cache in memory. This particularly applies to text files, where a lot of small data portions (text lines) are written consecutevily. Starting a disk operation for each one would be quite inefficient. However, this entails the danger of data loss. In case of a system crash the cache content gets lost, finally leaving the file incomplete. That's why Windows allows to disable disk write caching for drives. However, also applications (or components used by application) may apply caching in order to increase efficiency, so it's not only up to Windows. Let's have a look at what the DMS actually does when writing the timer list to disk: It deletes the file svctimers.bak, if present. It renames the file svctimers.xml (if present) to svctimers.bak. It creates a new file svctimers.xml, writes the timer list to it and closes the file. When does writing the svctimers.xml take place? Basically on four occasions: On DMS start right after a non-empty timer list has been loaded and the timers have been added (but maybe not all, because some may be dropped due to an end time in the past). After a change in the timer list (if timers are added / deleted / enabled / disabled, if their properties are changed...) Before the PC enters sleep mode. When the DMS gets stopped. Under the assumption that 2. works reliably, 3. and 4. are unnecessary. I suppose it has been introduced as additional measure against data loss in case 2. previously failed somehow. However, on the other side additional writing increases the danger that a crash may cause data loss. Anyway, the remarkable thing here is that the DMS does not write the svctimers.xml while the PC resumes from sleep mode, where the crash occurs. So how can the timer list get empty? Something unhealthy must already have happened before the PC has entered sleep mode. Or performing all tasks that the DMS wanted to perform took too long, after it received the PBT_APMSUSPEND notification: Quote Notifies applications that the computer is about to enter a suspended state (...) An application should process this event by completing all tasks necessary to save data. The system allows approximately two seconds for an application to handle this notification. If an application is still performing operations after its time allotment has expired, the system may interrupt the application. This could be examined by additional logging. Anyway, IMO the DMS should generally only write the svctimers.xml if it is really necessary, or with other words, if the memory content differs from the file content. There should be a flag indicating whether the current timer list content in memory has already been (successfully) saved or not. Now, on which occasions does the DMS start with an (unexpected) empty timer list? If there is no scvtimers.xml. If the file is completely empty (0 bytes), or more generally, does not contain the expected content (particularly no <Timers> root node). If the file is corrupted/damaged, which usually lets the XML parser detect a syntax error, causing abortion. If the system clock is far ahead, so that all timers with an end time before (a wrong) "now" are dropped (except timers with automatic daily/weekly repetition). This is not satisfying. The DMS should at least try to load the svctimers.bak in this case, but doesn't make use of it at all. So it's up to the user (if he happens to know about this backup file) and requires special measures. If the timer list is unexpectedly empty after the DMS has been launched, and the user stops the DMS in order to fix the issue, the timer list will be lost definitely, because the DMS will save a new svctimers.xml and thus delete svctimer.bak (see above). So the following has to be done for letting the DMS load the svctimers.bak: Rename the svctimers.bak e.g. to svctimers.tmp, so that the DMS doesn't find it anymore. Stop the DMS Delete the svctimers.xml Rename svctimers.tmp to svctimers.xml Restart the DMS Not really user-friendly I think this should be changed. However, to which extent this measure can avoid potential timer list data loss caused by BSODs is another question... Edited January 7, 2023 by Griga addition Quote
jirim100 Posted January 5, 2023 Author Posted January 5, 2023 (edited) Thanks for response. On 1/4/2023 at 12:08 PM, Griga said: Now, on which occasions does the DMS start with an (unexpected) empty timer list? If there is no scvtimers.xml. If the file is completely empty (0 bytes), or more generally, does not contain the expected content (particularly no <Timers> root node). If the file is corrupted/damaged, which usually lets the XML parser detect a syntax error, causing abortion. The file svctimers.xml was exist (after BSOD), but was empty (0 bytes or only root xml element) or after some BSOD contains ONLY regularly repeating timers 🤔. I am recording since 2012 (formelly with RS) and this has happened with svctimers.xml after BSOD to me before and not once. And only now I reported it here on the forum. Previously I used other computer with windows 7 to record - the same problem after BSOD. The "empty" timer list problem doesn't Always happen after BSOD. Hand on heart - who among the professional recorders has not had a BSOD with these devices? The drivers for these devices also contain bugs, not that they don't. On 1/4/2023 at 12:08 PM, Griga said: Rename the svctimers.bak e.g. to svctimers.tmp, so that the DMS doesn't find it anymore. Stop the DMS Delete the svctimers.xml Rename svctimers.tmp to svctimers.xml Restart the DMS It is not possible to do that. I'm not at the PC continuously all day and the PC automatically wakes up and goes to sleep. And when I go back to the PC to make a repair, some shows are irretrievably unrecorded. Some kind of repair has to be done automatically. Edited January 5, 2023 by jirim100 Quote
Griga Posted January 8, 2023 Posted January 8, 2023 On 1/5/2023 at 12:15 PM, jirim100 said: Some kind of repair has to be done automatically. Not possible. If a BSOD interrupts writing to disk (or a subsequent data transfer from the write cache to disk), what obviously happens in your case, data will be lost anyway. There is nothing left that can be repaired. Generally you can't make a deal with BSODs. However, there are two measures that can help: Avoid writing the svctimers.xml uselessly, particularly when the PC is about to enter sleep mode, but also on other occasions, in order to minimize the vulnerability for BSODs. This may already be sufficient to solve your problem. It eventually comes down to only (re-)writing the svctimers.xml immediately after changes in the timer list that could not be restored from disk, but not "just in case" anymore, as it is done now (see above: When does writing the svctimers.xml take place?). Make reasonable use of the svctimers.bak, so that in case of desaster at least the previous state of the timer list (without the latest change) is restored automatically. Particularly it must be avoided that a svctimers.xml that has been recognized as corrupted becomes the new svctimers.bak. That's what I'm currently trying to achieve... however, finally you will have to test how it works in practice. I'll post here if a test version is available. Quote
jirim100 Posted January 8, 2023 Author Posted January 8, 2023 2 hours ago, Griga said: That's what I'm currently trying to achieve... however, finally you will have to test how it works in practice. I'll post here if a test version is available. Thanks. At least "Avoid writing the svctimers.xml uselessly - particularly when the PC is about to enter sleep mode" would be great. Quote
jirim100 Posted January 12, 2023 Author Posted January 12, 2023 Today happened BSOD during wake up PC again and svctimers.xml had exactly 0 bytes. Quote
Griga Posted January 16, 2023 Posted January 16, 2023 On 1/12/2023 at 6:50 AM, jirim100 said: Today happened BSOD during wake up PC again and svctimers.xml had exactly 0 bytes. I've provided a Media Server test version for you. Please check your PMs. These are the changes: Change: Recorder: Different handling of loading/saving the timer list from/to the file svctimers.xml: The timer list is not saved anymore right after loading the svctimers.xml on Media Server start (needless though obsolete list entries may be dropped on loading). The timer list is not saved anymore right before the PC enters sleep mode / hibernate (needless if all timer list changes have been saved before, which should usually be the case). Please note that the list is still saved on a Media Server stop, though also needless. It is done “just in case” to make sure that the current state of the timer list is identical with the version on disk. Usually, if all changes have already been saved before, this measure will yield identical svctimers.xml and svctimers.bak files. If the file svctimers.xml is detected as corrupted on loading (not empty, but XML syntax errors), it is renamed to svctimers[yyyymmddhhnnss].bak, where [yyyymmddhhnnss] is the current date and time, yielding something like svctimers20230105100634.bak. This measure ensures that the corrupted file cannot become svctimers.bak. The renamed file can be used for manual repair attempts. This event is now logged in the file svcdebug.log. If the file svctimers.xml is detected as invalid on loading (0 bytes or no “Timers” root node), it is deleted, so it cannot become svctimers.bak. This event is now logged in the file svcdebug.log. If the file svctimers.xml can not be loaded, because it is corrupted or empty/invalid, the file svctimers.bak (which contains the previous timer list state before the latest change was saved) is renamed to svctimers.xml and loaded. This event is now logged in the file svcdebug.log. I'm not sure if the saving on a Media Server stop is appropriate. Another option would be to not rename the previous svctimers.xml to svctimers.bak (which includes deleting the previous svctimers.bak), if the current timer list is empty. Anyway, please try first how the measures enumerated above work in your case... Quote
jirim100 Posted January 16, 2023 Author Posted January 16, 2023 Very thanks!! I will try it. It may take a long time for the next BSOD event to occur. But at least I will try the transitions to/from sleep mode and turning the MS on and off. 7 hours ago, Griga said: Another option would be to not rename the previous svctimers.xml to svctimers.bak (which includes deleting the previous svctimers.bak), if the current timer list is empty. Isn't this note redundant? You already solve this problem above: 8 hours ago, Griga said: If the file svctimers.xml can not be loaded, because it is corrupted or empty/invalid, the file svctimers.bak (which contains the previous timer list state before the latest change was saved) is renamed to svctimers.xml and loaded. This event is now logged in the file svcdebug.log. Quote
Griga Posted January 16, 2023 Posted January 16, 2023 33 minutes ago, jirim100 said: Isn't this note redundant? No. An empty timer list doesn't mean an empty file. Usually it is stored like this: <?xml version="1.0" encoding="utf-8"?> <Timers> <NextID>39</NextID> </Timers> Quote
jirim100 Posted January 26, 2023 Author Posted January 26, 2023 Today happened BSOD and all seems ok: Spoiler 26.01.23 00:30:02.406 SendUpdate DVBVUPDATE TMR 26.01.23 00:30:02.409 SendUpdate DVBVUPDATE RST -22042 26.01.23 00:31:35.118 SendUpdate DVBVUPDATE REC 26.01.23 00:31:36.394 TProcessTimer NeedsEnding VPS_PDC finished 26.01.23 00:31:36.394 ReleaseStandbyblock TVCR 26.01.23 00:31:36.394 TServiceMain ReleaseReference TVCR: 0 26.01.23 00:31:36.396 SetStandbyBlock EvaluateShutdown 26.01.23 00:31:36.396 SendUpdate DVBVUPDATE PWR DESKTOP-B7NHU71 26.01.23 00:32:51.467 TServiceMain DoShutDown Enter 26.01.23 00:32:51.467 TServiceMain Setting next recording: 26.01.2023 1:03:00 26.01.23 00:32:51.467 ThdProc Enter 26.01.23 00:32:51.468 TUPnPDevice Stopped 26.01.23 00:32:51.541 TSynHttpServer ServerLoop terminated 26.01.23 00:32:51.557 TSrvDataModule Freed 26.01.23 00:32:51.609 ReleaseStandbyblock DoShutDown 26.01.23 00:32:51.609 TServiceMain DoShutDown sdHilbernate 26.01.23 01:05:38.708 Start App ------------------------------------------------------------ 26.01.23 01:05:38.723 DVBViewer Media Server 3.2.3.1 26.01.23 01:05:38.723 TServiceMain Execute Start 26.01.23 01:05:38.723 TServiceMain StartService start timer 26.01.23 01:05:38.723 TServiceMain StartService Create plugin list 26.01.23 01:05:38.723 TServiceMain StartService found 0 plugins 26.01.23 01:05:38.723 TServiceMain channellist loaded 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings TT-connect CT2_4650 DVB-C Tuner (2), status 1 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings TT-connect CT2_4650 DVB-C Tuner (14), status 1 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings Digital Devices DVB-T2 Tuner 4 (12), status 1 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings Digital Devices DVB-T2 Tuner 2 (11), status 1 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings Digital Devices DVB-T2 Tuner 3 (10), status 1 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings Digital Devices DVB-T2 Tuner 1 (9), status 1 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings Cinergy T2 Stick DVBC BDA Filter (3), status 1 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings Cinergy T2 Stick DVBC BDA Filter (15), status 1 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings PCTV 292e/461e BDA 28179 TVTuner C (6), status 1 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings Cinergy T2 Stick BDA Filter (4), status 1 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings Cinergy T2 Stick BDA Filter (16), status 1 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings PCTV 292e/461e BDA 28179 TVTuner (5), status 1 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings Professional DVB Digital TV DVB-T2 (17), status 1 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings AF9015 BDA Filter (7), status 1 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings AF9015 BDA Filter 2 (8), status 1 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings Professional DVB Digital TV DVB-C (18), status 0 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings TT-connect CT2_4650 DVB-T/T2 Tuner (13), status 0 26.01.23 01:05:38.723 TDVBDeviceList LoadSettings TT-connect CT2_4650 DVB-T/T2 Tuner (1), status 0 26.01.23 01:05:38.739 TDVBDeviceList CheckDevicesPresent AF9015 BDA Filter (7) not available 26.01.23 01:05:38.739 TDVBDeviceList CheckDevicesPresent AF9015 BDA Filter 2 (8) not available 26.01.23 01:05:38.817 TServiceMain Start Searches load 26.01.23 01:05:38.817 TTaskList LoadDoc config\tasks.xml loaded 26.01.23 01:05:38.817 TTaskList LoadDoc default\config\tasks.xml loaded 26.01.23 01:05:38.833 SendMulticastUpdate No buffer space available (#10055 in TryToSend failed) 26.01.23 01:05:38.833 SendUpdate DVBVUPDATE TMR 26.01.23 01:05:38.833 TServiceMain Start VCR load 26.01.23 01:05:38.927 TServiceMain Start EPG load 26.01.23 01:05:38.973 TServiceMain LoadSetup end 26.01.23 01:05:38.973 TServiceMain StartService setup loaded 26.01.23 01:05:38.973 TServiceMain Service Enabled 26.01.23 01:05:38.973 SendMulticastUpdate No buffer space available (#10055 in TryToSend failed) 26.01.23 01:05:38.973 SendUpdate DVBVUPDATE REC 26.01.23 01:05:38.989 SendMulticastUpdate No buffer space available (#10055 in TryToSend failed) 26.01.23 01:05:38.989 SendUpdate DVBVUPDATE TMR 26.01.23 01:05:38.989 SetStandbyBlock TVCR 26.01.23 01:05:38.989 TServiceMain AddReference TVCR: 1 26.01.23 01:15:03.704 TBDAEMPIA OpenDevice bvEMPIA 26.01.23 01:15:03.704 TRecording AllocateHardware Cinergy T2 Stick BDA Filter (4) 26.01.23 01:15:03.704 TRecording StartRecord Cinergy T2 Stick BDA Filter (4) 26.01.23 01:15:03.704 TBDAEMPIA SetTuner TType: 2, Freq: 474000, Symrate: 0, LOF: 0, Tone: 0, Pol: 2, DiseqC: 0, FEC: 0, APID: 1103, VPID: 1101, PMT: 110, SID: 11001, TID: 1001, NID: 0, SatMod: 0, DiseqCVal: 0, Flags: 24, Group: 0 26.01.23 01:15:05.632 TRecording StartRecording: CT 1 What means "SendMulticastUpdate No buffer space available (#10055 in TryToSend failed)" in log? Quote
Griga Posted January 26, 2023 Posted January 26, 2023 6 hours ago, jirim100 said: What means "SendMulticastUpdate No buffer space available (#10055 in TryToSend failed) The Media Server tries to prompt all DVBViewer clients in the network to re-fetch the timer and recording list by sending a multicast message. Doing so fails with WinSock error 10055. Please read more about it here. Most likely it is caused by connections that have not been closed properly before due to the crash. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.