Bug #179
Rescheduled shows lead to duplicate dvr entries
100%
Description
My autorecorded shows are sometimes ending up with many dvr entries for the same timeslot after a few days. Each entry has a slightly different start time and/or duration. This seems to happen when a show has been rescheduled and the OTA EPG updated to reflect this. Tvheadend then creates a dvr entry for the new time but is not removing the old entry.
Files
History
Updated by Chris Dekter - over 14 years ago
svn r4364... you might want to refer to my screenshot in ticket 180 as well for more info - I think the two issues are related
Updated by aeon - over 14 years ago
I've got the same problem. Some recordings result in 3 or even more recordings, because of small changes in the epg. This not only leads to incomplete recordings (because of the wrongly detected epg infos) but also to a lot of recorded junk and ambiguous recordings. I think this error was introduced with the latest (2.11) version. I don't remember that this was the case beforehand.
Please fix this asap! The features of prioritized and scheduled auto recordings were really worth the wait for 2.11. I don't want to go back to 2.10
Updated by Andreas Smas almost 14 years ago
- Category changed from General to PVR / DVR
- Status changed from New to Accepted
Updated by Nathan McAullay almost 14 years ago
Hi there, I am in Australia and have similar duplicate entries in the EIT provided EPG. If you need any information, or a tester, please let me know, and I hopefully can help this issue get resolved.
Updated by Nathan McAullay over 13 years ago
Hi there, im using git c365f23, and have this problem. I thought by upgrading that some of the recent commits might have sorted this bug out. The EPG is begin updated OTA, but the DVR is retaining the old entry, and adding the updated one, which results in two (or more) recordings of the same show, with slightly different start/end times. Quite annoying to have to check frequently in the WebGUI to remove old EPG entries from the auto recording screen. Thoughts that this fix could make it into 2.13? If this was .net i could probably help, but my C++ is almost non-existant, and i'd do more damage than good. Cheers, Nathan
Updated by Tai Lee over 13 years ago
Same problem here (also in Australia). Using 2.12.99~git20110521.8281379~odk2~lucid
.
I think that every time EPG data is updated, tvheadend should match existing scheduled recordings against the entire EPG data and remove any stale records, and then add new scheduled recordings for new matches.
Currently, I think this bug will not only result in duplicate recordings of the same show at the same time (sometimes with a few minutes different start/end times), but will also record (and incorrectly tag with metadata) completely different shows, if the show you want to record is moved to another day or time-slot or cancelled entirely.
Is this a difficult fix, and that is why it is slated for 3.0? Can it not be fixed in a minor release? Almost every day I have a duplicate recording here
Updated by Martin Mrvka over 13 years ago
Same problem here. Although I'm using tvheadend for a while now I didn't noticed it because it is not happening on all channels/services. For example when scheduling on the german channels ProSieben and Sat1 it doesn't happen (had a autorecording for running for half a year for a couple of shows) but for the austrian channel ORF1 it is happening for every for every show.
Updated by George Mejia over 13 years ago
I have the same problem, I thought it might be caused because I am running a Hauppauge Twin tuner USB dongle and the automatic recording is creating a copy from each of the tuners.
Updated by carlos acedo over 13 years ago
Same problem with Spain OTA EPG, sometimes reschedules happen 4 o 5 times for a tv show. Also using two tunners, but I don't think this is the problem
Updated by Chris Dekter - about 13 years ago
- File issue179.patch issue179.patch added
I'm attaching a patch for this issue. It works for me (been testing it for a few days now). It's pretty simple - when updating the EPG, and going through all autorecs to see if any updated events match an autorec, I check to see if the event being updated matches any existing DVR entry. This is done by matching on the event name and start/end time being within 10 minutes of the DVR entry. So far it is working perfectly.
Updated by Chris Dekter - about 13 years ago
I should add that my patch uses fairly naive logic and won't handle the case where a show is rescheduled to a totally different timeslot. I did a lot of investigating but tvheadend doesn't seem to have a strong link between and epg-entry and a dvr-entry - only the event start time is used (as far as I can see). Perhaps linking the two using the DVB event ID would allow more sophisticated rescheduling.
Updated by Andreas Smas about 13 years ago
- Status changed from Accepted to Fixed
- % Done changed from 0 to 100
Applied in changeset commit:0c1c1cfbd9881449f799a4ce5e1a3b8a141e77d1.
Updated by Andreas Smas about 13 years ago
- Found in version set to all
Thanks :-)
I have looked into using DVB EIT ID a long time ago. But it seems some channels reuse these IDs a lot so it needs to be done carefully.
Updated by Chris Dekter - about 13 years ago
I thought I had this problem fixed but there was far more to it. The changes in my pull request have been tested on my production system for about a week now and there are zero duplicates, and no missed recordings. The problem is caused by a habit Australian TV networks have of giving new DVB IDs to events when they just update the event start/end time.
Updated by Jamie Carl over 12 years ago
I just wanted to add that I'm also having this problem and it is quite annoying. I have at times had 5 recordings for a single show. Any word on if/when this will be fixed?
Updated by Hein Rigolo over 12 years ago
this bug was closed 6 months ago ... are you sure you are using a recent version of tvheadend from git?
Hein
Updated by Tomas Matejicek over 12 years ago
I can confirm the problem persists. Rescheduled EPG data lead to duplicate recordings, and in the worst case (in my case) to 80 duplicite files with the same program and tvheadend crash. I do not know if/how the TV provider sends the EPG data, but what I can see are many duplicite files in .hts/tvheadend/dvr/log/*
Updated by Wes C. over 12 years ago
Having this problem as well, using the amd64 binary deb for 2.12
Updated by Wes C. over 12 years ago
Actually, scratch that, just noticed the 2.12 binary debs on the main page are 2 years old..
I've moved to git version.
Wes C. wrote:
Having this problem as well, using the amd64 binary deb for 2.12
Updated by Sébastien Aubry almost 12 years ago
I believe that I also have this bug using 3.2.34
Attached are:
- An XBMC screenshot showing that the scheduled recordings are duplicated
- My syslog file showing that the same show is sometimes recorded twice using the same tuner. For instance:
Feb 16 20:23:33 pchc tvheadend[1804]: dvr: /pchc_f/Recorded TV/L'écho-des-lois/La-Chaîne-parlementaire-L'écho-des-lois.2013-02-16.20-30.mkv from adapter: "DiBcom 3000MC/P #2", network: "F", mux: "F: 746,000 kHz", provider: "GR1 A", service: "LCP" Feb 16 20:23:33 pchc tvheadend[1804]: dvr: # type lang resolution samplerate channels Feb 16 20:23:33 pchc tvheadend[1804]: dvr: 1 MPEG2VIDEO 720 x 576 Feb 16 20:23:33 pchc tvheadend[1804]: dvr: 2 MPEG2AUDIO fre 48000 2 Feb 16 20:23:33 pchc tvheadend[1804]: dvr: 3 DVBSUB fre Feb 16 20:23:33 pchc tvheadend[1804]: dvr: /pchc_f/Recorded TV/L'écho-des-lois/La-Chaîne-parlementaire-L'écho-des-lois.2013-02-16.20-30-1.mkv from adapter: "DiBcom 3000MC/P #2", network: "F", mux: "F: 746,000 kHz", provider: "GR1 A", service: "LCP" Feb 16 20:23:33 pchc tvheadend[1804]: dvr: # type lang resolution samplerate channels Feb 16 20:23:33 pchc tvheadend[1804]: dvr: 1 MPEG2VIDEO 720 x 576 Feb 16 20:23:33 pchc tvheadend[1804]: dvr: 2 MPEG2AUDIO fre 48000 2 Feb 16 20:23:33 pchc tvheadend[1804]: dvr: 3 DVBSUB fre
I am using the xmltv grabber tv_grab_fr_telerama
Updated by Wild Penguin over 5 years ago
I'm having this issue with 4.3-1752~g797af7c78-dirty . I know, a bit dated, now upgrading. Will report if also happens with current GIT.
This is probably quite dependent on the broadcast type, I think most often this happens with live sport broadcasts, which are more likely to be rescheduled for one reason or another.