Jump to content

Svctimers.xml after BSOD empty.


jirim100

Recommended Posts

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

 

 

  • Sad 1
Link to comment

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

Link to comment
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:

  1. It deletes the file svctimers.bak, if present.
  2. It renames the file svctimers.xml (if present) to svctimers.bak.
  3. 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:

  1. 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).
  2. After a change in the timer list (if timers are added / deleted / enabled / disabled, if their properties are changed...)
  3. Before the PC enters sleep mode.
  4. 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?

  1. If there is no scvtimers.xml.
  2. If the file is completely empty (0 bytes), or more generally, does not contain the expected content (particularly no <Timers> root node).
  3. If the file is corrupted/damaged, which usually lets the XML parser detect a syntax error, causing abortion.
  4. 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:

  1. Rename the svctimers.bak e.g. to svctimers.tmp, so that the DMS doesn't find it anymore.
  2. Stop the DMS
  3. Delete the svctimers.xml
  4. Rename svctimers.tmp to svctimers.xml
  5. 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 by Griga
addition
Link to comment

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?

  1. If there is no scvtimers.xml.
  2. If the file is completely empty (0 bytes), or more generally, does not contain the expected content (particularly no <Timers> root node).
  3. 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 by jirim100
Link to comment
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.

 

Link to comment
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.

Link to comment
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...

 

Link to comment

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.

 

Link to comment
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>

 

Link to comment
  • 2 weeks later...

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?

Link to comment
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.

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...