Project

General

Profile

Bug #1444

Feature #1087: DVR Improvements

Missed recording with git yesterday

Added by Eric Valette almost 7 years ago. Updated over 6 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
Category:
PVR / DVR
Target version:
Start date:
2012-12-04
Due date:
% Done:

100%

Estimated time:
Found in version:
5d2197c30fe4774f25ba9404287436d51a215578
Affected Versions:

Description

At around 7 PM yesterday I added a recording for ARTE HD : MISSOURI BREAKS 8:50PM duration 2h05. Launched an XBMC for testing a new version on another device later and did not see the recording flags when looking at TV channels list. Looked at the HTML interface => recording was gone, not failed. As it was still playing I tried to start it and it started immediately (but lost around 1hour so deleted it).

This is an old bug that was already present in 2.x code base and that is apparently still there. I moved the entire setup to 3.4-git sunday 02/12. It seems to happen when EIT and XMLV input disagree about the time of something. In france, from the EIT you only have current and next, so when starting one hour before, you may not have yet received the EIT for the program you want to record. If time is slightly different than the one in XMLTV, it may remove the event and somehow delete the programmed the recording silently. I checked the syslog and have only the trace when creating the recording, no error whatever after that.


Files

log (203 KB) log Eric Valette, 2012-12-05 17:48

Associated revisions

Revision a0a7539a (diff)
Added by Adam Sutton over 6 years ago

Fix #1444 - dvr: ensure that DVR entries are not removed when EPG is updated

previously an overlapping (replacement) event could result in the DVR
entry being completely removed. This will now ensure that the original
entry is left in place (with just info and times).

It will also try and re-match with an EPG entry as and when it can.

Revision 3e4389b5 (diff)
Added by Adam Sutton over 6 years ago

Fix #1444 - dvr: ensure that DVR entries are not removed when EPG is updated

previously an overlapping (replacement) event could result in the DVR
entry being completely removed. This will now ensure that the original
entry is left in place (with just info and times).

It will also try and re-match with an EPG entry as and when it can.
(cherry picked from commit a0a7539a731c6e84b8e0a3a95b1c1655a12515c7)

History

#1

Updated by Eric Valette almost 7 years ago

Tried agaion same recording at 1 AM

START: HTS Tvheadend version started, running as PID:2924 UID:113 GID:44, settings located in '/home/hts/.hts/tvheadend'
Dec 4 10:02:55 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: grab took 30 seconds
Dec 4 10:02:55 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: parse took 0 seconds
Dec 4 10:02:55 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: channels tot= 18 new= 0 mod= 0
Dec 4 10:02:55 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: brands tot= 0 new= 0 mod= 0
Dec 4 10:02:55 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: seasons tot= 0 new= 0 mod= 0
Dec 4 10:02:55 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: episodes tot= 1884 new= 1177 mod= 1181
Dec 4 10:02:55 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: broadcasts tot= 1884 new= 1306 mod= 1306
Dec 4 10:03:07 STB-atom-ion-3 tvheadend2924: dvr: "MISSOURI BREAKS (VM) (HD)" on "ARTE HD" starting at 2012-12-05 01:50:44, scheduled for recording by "10.194.58.94"
Dec 4 22:02:25 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: grab /usr/bin/tv_grab_fr_kazer.sav
Dec 4 22:02:51 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: grab took 27 seconds
Dec 4 22:02:52 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: parse took 0 seconds
Dec 4 22:02:52 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: channels tot= 18 new= 0 mod= 0
Dec 4 22:02:52 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: brands tot= 0 new= 0 mod= 0
Dec 4 22:02:52 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: seasons tot= 0 new= 0 mod= 0
Dec 4 22:02:52 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: episodes tot= 1748 new= 221 mod= 234
Dec 4 22:02:52 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: broadcasts tot= 1748 new= 366 mod= 366
[email protected]:/var/log# grep tvheadend syslog
Dec 5 10:02:25 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: grab /usr/bin/tv_grab_fr_kazer.sav
Dec 5 10:02:54 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: grab took 30 seconds
Dec 5 10:02:54 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: parse took 0 seconds
Dec 5 10:02:54 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: channels tot= 18 new= 0 mod= 0
Dec 5 10:02:54 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: brands tot= 0 new= 0 mod= 0
Dec 5 10:02:54 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: seasons tot= 0 new= 0 mod= 0
Dec 5 10:02:54 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: episodes tot= 1872 new= 439 mod= 458
Dec 5 10:02:54 STB-atom-ion-3 tvheadend2924: /usr/bin/tv_grab_fr_kazer: broadcasts tot= 1872 new= 590 mod= 590

Recording was not done, no error no message....

#2

Updated by Eric Valette almost 7 years ago

Third missed recording in a raw. This time it disappeared even before the timing chnage in the EIT was acessible. So its probably due to a change in the XMLTV itself.

Attached is a debug log session that started just after setting the recording and ended when I saw it was gone (but I was not looking after it so it may have disappeared much before the end).

#3

Updated by Eric Valette almost 7 years ago

Reading the code I'm a bit puzzled. I schedule a recording via the epg. The epg table for the channel get updated, and if dvr_entry_find_by_event_fuzzy does not find the entry using only slot time, the recording is deleted. It would be safer to consider in this case the previous start time<-> end time has been created manually for the channel and readd it.

#4

Updated by Adam Sutton almost 7 years ago

  • Status changed from New to Accepted
  • Target version set to 3.4
  • Parent task set to #1087
  • Affected Versions 3.2, 3.4 added

This doesn't entirely surprise me, it's well documented that mixing XMLTV/EIT etc. can cause problems. I've done my best to improve this from the point of view of teh actual schedule management. But the DVR code itself is indeed in need of revamping.

I'll note this against my general "update the DVR" issue. Just need to find time to do something about it.

Adam

#5

Updated by Eric Valette almost 7 years ago

Adam Sutton wrote:

This doesn't entirely surprise me, it's well documented that mixing XMLTV/EIT etc. can cause problems. I've done my best to improve this from the point of view of teh actual schedule management. But the DVR code itself is indeed in need of revamping.

I'll note this against my general "update the DVR" issue. Just need to find time to do something about it.

Adam

I think a quick workaround is that the recording time slots shall be recreated as if it was entered manually keeping the info that had been set via epg event. Here the recording is deleted simply without any notification. And I haven't figured out why it does not find a event near. I bet its beacuseeit has only next and current and does not comme in addition to XMLTV epg... I think is OK to record something else because program changed that noting at all. In addition, the eit use UPPER case and the channel name ARTE HD but for the epg ARTE HD vs arte has no meaning so channel name changed fromp ARTE HD to ARTE when setting the xmltv:kazer ARTE info in the channel

#6

Updated by Eric Valette almost 7 years ago

Forgot to say that comment 3 renders difficult to blame eit/XMLTV as there was nothing in the EIT for the time slot.

#7

Updated by Adam Sutton over 6 years ago

  • Status changed from Accepted to Fixed
  • % Done changed from 0 to 100

Also available in: Atom PDF