Rescheduling Failed Recordings

[georgewbateman]

Does NPVR automatically reschedule failed recordings ? For the recording options Record all episodes on this channel and Record all episodes on all channels, there may be additional airings that could recorded in place of the failed recording.

Thank you in advance.

[johnsonx42]

I believe as long as the recording failed in a way that the recording service *knows* it failed, then the episode unique ID will not be added to the "already got it" list. The same episode would then be scheduled again if found during the next EPG update.

[georgewbateman]

I did some further checking based on your response. ndvr.db3 contains a table RECENTLY_DELETED and Unique ID for both successful and failed programs are added. (It would be interesting to know how long entries remain in this table.) From what I can tell this table is only used when the setting Recording Avoid duplicate recordings where possible is checked. As long as the Unique ID is this table another recording can not be scheduled (except of course with Record Once).

In my judgement placing the Unique ID for failed recordings in the RECENTLY_DELETED table is an error. Doing this makes rescheduling impossible at anytime.

From what I can tell the table SCHEDULED_RECORDINGS has four kinds of information:

Scheduled recordings (As you would expect)
In process recordings
Completed recordings (The file name for the recording is then present)
Failed recordings

My assumption is that all of the entries are considered equivalent when rescheduling occurs. This would also make rescheduling failed recordings impossible.

I have used Snapstream BeyondTV and (if I am recalling correctly) rescheduling occurs at two times - after a new EPG is downloaded and when BeyondTV is started (the equivalent in NPVR is Start NPVR Service).

I would expect NPVR Service to initiate rescheduling in three situations :

As Start NPVR Service
After completing an EPG updare
When a recording has failed

[Graham]

(It would be interesting to know how long entries remain in this table.)

Config.xml has this ...

Code:

<DeletionHistoryDays>999</DeletionHistoryDays>

[sub]

I did some further checking based on your response. ndvr.db3 contains a table RECENTLY_DELETED and Unique ID for both successful and failed programs are added. (It would be interesting to know how long entries remain in this table.) From what I can tell this table is only used when the setting Recording Avoid duplicate recordings where possible is checked. As long as the Unique ID is this table another recording can not be scheduled (except of course with Record Once).

Were they shown as 'failed' in the Recordings screen? What reason did it show for the failure?

I checked the code, and it shouldn't be adding failed recordings to RECENTLY_DELETED.

[mvallevand]

To confirm what sub just wrote, I did a cleanup last night of 5+ failed recordings I was trying to reschedule or capture from on demand after I turned off the wake for events accidentally a week ago, and none of these were added to recently deleted.

Martin

[georgewbateman]

Thanks for the information on DeletionHistoryDays. There is no mention of it in wiki for config.xml. And of course not configurable with Setting dialog.

I have been somewhat frustrated about the missing information in the Recording wiki page. I am planning rewiting part of that documentation. This value and Avoid duplicate recording where possible checkbox on the Settings Recordings have a very significant effect on the result of scheduling.

[johnsonx42]

Any contributions you can make to the wiki would be appreciated. I think what tends to happen is that the long-time users just get used to how things work, and don't think to document it. A new user brings a fresh view of things, and sees what's missing from the documentation. Another problem is that there are certain users who just refuse to contribute to the wiki (johnsonx42 looks in the mirror... there he is! he's the one who won't help with the wiki! get him!)... no one knows why.

[georgewbateman]

I wrote this a couple days ago but somehow it did not get posted.

I realized after I wrote #3 that I had been looking at the wrong program. So a portion of what I write the is incorrect. I did some further testing.

I had a the same episode of scheduled to be aired as follows :

5 NOV 2130 (930 PM)
6 NOV 0000 (1200 AM)
6 NOV 0500 (530 AM)
6 NOV 2300 (300 PM)

Before the first airing the NPVR database SCHEDULED_RECORDINGS table contained a record for 5 NOV 2130 with status=0 - scheduled. I then turned off the NPVR service for the duration of the program. I then rebooted my system. SCHEDULED_RECORDINGS record then had a status=3 - program did not recorded with the reason Recording service not running at the recording time. There were not other scheduled recordings for this episode.

I next performed nextpvr -updateepg. SCHEDULED_RECORDINGS then contained two records the one as above and one for 6 NOV 0000 status=0 scheduled.

The Ready Recordings screen then contained an entry for the 5 NOV 2130 with the error information. After I deleted that entry. There was not entry in the RECENTLY_DELETED table for the episode.

All this means that when there is a recording error it is possible to get another episode scheduled for recording provided there UpdateEPG can be run.