Project

General

Profile

Bug #4299

Autorec fails with "file missing" or wrong program being recorded.with bad EPG data

Added by Joe User over 4 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
PVR / DVR
Target version:
-
Start date:
2017-03-29
Due date:
% Done:

0%

Estimated time:
Found in version:
4.1 (but may have been around for a long time...)
Affected Versions:

Description

I have a unique situation which has revealed a problem with autorec. In Europe, I watch/record content from a US provider. Daylight Saving TIme changes at different times in the US and Europe which usually causes at least a few days of EPG data being one hour off (plus or minus) on some channels until it gets adjusted. So this problem occurs four times a year. I understand this is a problem with the EPG data, but my attempts to manually override do not work.

Two weeks ago when the EPG data was one hour early, I got recordings with the wrong content, which was to be expected. But, when the EPG data was corrected and received, I got two recordings from each autorec. One with the correct program being recorded with the correct title and a second recording being made one hour offset from the "good" recording with the program title and content of whatever was scheduled at the time. So, it appears that while the new corrected EPG data was found and used by autorec to correctly record the programs, the recordings which were already scheduled were not only not removed, they still recorded AND used the new corrected EPG data to change the title to the content which was recorded. This is not so terrible, but it is related to what is described below. (During this time, the following record profile settings were: EPG update window: 24hrs and Use EPG running state: (unchecked))

I had not scheduled programs set for Sunday after the time change, but Sunday night I saw that the recordings scheduled for Monday morning were going to all be one hour late. (No new corrected EPG data had been received yet.) So, I manually changed 6 recordings and change their start/end times to be one hour ahead of when they were originally scheduled by autrec. Monday morning I looked at the terminal with the Tvheadend running and the trace information seemed to indicate a program was being recorded and "Upcomming/Current Recordings" showed the program was being recorded. But when I checked the "Finished Recordings" there were no entries for programs which should have been recorded earlier Monday morning and I found the entries for three earlier scheduled recordings in the "Removed recordings" tab with the status of "File missing", and indeed there were no recordings on the disk. Then I looked at the "status->subscriptions" tab and saw that there was a subscription for the program which should currently be recording, but while the "Input (kb/s" showed data was coming in, the "Output(kb/s)" was 0. At this point I verified the recording profile settings thinking the "Use EPG running state" might be set, it was not. So, I do not know why it was not being recorded. I went to the EPG tab and selected the currently running (mis-titled) program and selected record and it started recording ok. So, there is no problem with recording (plenty of disk space...) Is the file not being recorded because the EPG data title does not match the title of the scheduled recording??? So, I stopped Tvheadend (ctrl-c) and restarted. No recording (or even subscription) started after restarting, so I looked at "Upcomming/Current Recordings" and noticed all the manual time changes I made to the remaining 3 recordings for today were reset back to match the EPG data. So, on startup, autorec automatically adjusted the sceduled recordings. So, I went back the the recording profile and set "EPG update window: Update disabled" and again manually changed the remaining recordings one hour ahead again. But again when the time came for the next recording to start, the subscription started, but no "Output(kb/s" were indicated and no file was even created. When the scheduled recording time finish came, the "recording" again showed up in "Removed Recordings" with the status of "File missing". I also tried changing the "EIT time offset" for the network to adjust for the EPG data error. And while the times in the EPG tab were now in sync with the content being broadcast, recordings still did not work. Same result - subscription starts, but never actually creates and writes to the file. So, I am guessing the problem is with the EPG running state, even though the option is not selected.

So, there are two issues here.

1. After EPG data changes (shifts time) autorec uses the new data to create new (correct) recordings, but the old scheduled recordings are not deleted, instead they have their title changed to whatever the new EPG data says will run at that time. This problem can be recreated by creating some autorec for an upcoming program, then changing the "EIT time offset" for the network, then restart tvheadend.  
2. Whether or not the "Use EPG running state" option is selected, Tvheadend still uses it. Once a recording is scheduled, a user should be able to manually edit it to adjust start/stop time no matter what the EPG data says.

The first issue is a low priority, but for the esecond issue, I looked at the code and made a small change which enabled the recordings to work with the bad EPG data, but should also work when one wants to use different start/stop times than what the EPG running state says (if "Use EPG running state" is not selected.) This may break something else, so it needs to be looked at more by someone more familiar with the code, but it is working for me..

diff --git a/src/dvr/dvr_rec.c b/src/dvr/dvr_rec.c
index 24d70c3..75f2cab 100644
--- a/src/dvr/dvr_rec.c
+++ b/src/dvr/dvr_rec.c
@@ -1287,7 +1287,9 @@ dvr_thread(void *aux)
     streaming_queue_remove(sq, sm);

     if (running_disabled) {
-      epg_running = real_start <= gclk();
+      if ( real_start < gclk()){
+        epg_running = 1;
+      } else epg_running = 2;
     } else if (sm->sm_type == SMT_PACKET || sm->sm_type == SMT_MPEGTS) {
       running_start = atomic_get_time_t(&de->de_running_start);
       running_stop  = atomic_get_time_t(&de->de_running_stop);

Associated revisions

Revision 113dfd6b (diff)
Added by Em Smith almost 3 years ago

dvr: Autorec rules must still match event after update. (#4760).

We now check the autorec rule matches an event following an
update and on startup.

When using xmltv grabbers you can have an autorec rule that
matches "title: A". When a future xmltv run replaces the
event with "title: B" then the dvr event is updated to reflect
the new details (and will log updated title), but the autorec
rule was not checked to see if it still matched the event.
This meant we would record "title: B" even though the autorec
was to only record "title A".

Also, previously if you delete the epgdb between runs then the
timers spawned by autorec rules remained. This could cause problems
if the epgdb had been removed due to incorrect setup such as invalid
xmltv files.

This meant that you then had to manually disable and re-enable the
autorec rules to remove these incorrect timers.

Now we remove any record events created by an autorec rules if that
event no longer matches the schedule.

This does mean that if the user does not persist the epgdb at all
then, on startup, they no longer have autorecs timers matching until
the epg is populated at startup, which is a change in behaviour (since
previously autorec timers would remain) but could also be considered
"expected" behaviour (no epgdb means no autorec timers).

Issue: #4299.

Also available in: Atom PDF