Bug #4640
open
Duplicate handling activated, despite Autorec setting "Record all"
Added by Rob vh over 7 years ago. Updated over 7 years ago.
0%
Description
My autorecs are skipping episodes, for example, on BBC 2 I have an autorec that selects "strictly". Next week it skips s15.e09 on Thursday, whereas all other episodes are recorded. I collect my EPG from Schedules Direct. This is a 5(?) year old autorec.
I also have an autorec "coast to coast" that selects programs from Spike and Channel 5 HD, but each episode is only recorded once despite there being re-runs. Very effective, BUT, I have "Record all" specified in the autorec! I keyed in this autorec this morning.
Files
| Screenshot from 2017-09-30 20-14-48.png (189 KB) Screenshot from 2017-09-30 20-14-48.png | EPG overview and details | Rob vh, 2017-09-30 20:21 | |
| 4640-extra-debug.patch (1.26 KB) 4640-extra-debug.patch | Em Smith, 2017-10-03 02:06 | ||
| Screenshot from 2017-10-03 18-00-25.png (146 KB) Screenshot from 2017-10-03 18-00-25.png | Rob vh, 2017-10-03 18:04 | ||
| Screenshot from 2017-10-03 18-21-40.png (162 KB) Screenshot from 2017-10-03 18-21-40.png | attempt to use local: record if different episode | Rob vh, 2017-10-03 18:22 | |
| 4640-only-dup-same-start-time-with-debug.patch (1.42 KB) 4640-only-dup-same-start-time-with-debug.patch | Em Smith, 2017-10-04 01:07 |
Updated by Jaroslav Kysela over 7 years ago
Could you compare the missing autorec episode with others ? The detail in EPG window might help to determine the diferences.
If "Record all" is set, then the rerun mechanism is completely off. Do you see 'rerun' dates in the 'Rerun of' column in the upcoming recordings grid?
Updated by Rob vh over 7 years ago
The only details in the EPG window I can see show the description, start and end time. See screen copy.
There is no entry in the dvr/log for s15.e09. S15e.e08 and .e10 look "normal".
I can, however, click the (i) icon in the EPG list, select "Record program" and the show now turns up in the "Upcoming recordings." At that point a file is created in dvr/log and it contains a unique "broadcast" number.
Updated by Jaroslav Kysela over 7 years ago
If you turn off/on the autorec, is the event correctly included?
It's not easy to debug such things. It may help, if you can pack the whole settings directory (which includes the EPG database) and give me the URL to the packed file to do an analysis why autorec code ommits this event. I'm perexg on IRC, so send me a PM.
Updated by Em Smith over 7 years ago
I have SD and can't reproduce the Strictly problem, but I can reproduce the Coast to Coast issue, assuming you are talking about S01E03 on Fri 6th Oct 02:00 on Spike which is dup of Tuesday 3rd on channel 5.
@Jaroslav I think the dvr_entry_create_by_autorec is dropping the dup since episode is the same. I already had a small local patch in that area to do logging (below), but my patch also forced preferring earlier showing so is slightly different logic to master which schedules the first it found which in my case was frequently the +1 channel. Perhaps the check in master should also check start time is equal?
dvr: Autorecord "(null)": Not scheduling "Tony Robinson: Coast To Coast" on channel Channel 5 HD because identical dup start: 1507251600 and de start: 1507053600 channel: Spike
Updated by Jaroslav Kysela over 7 years ago
@Robert E: I tested things with your data and if I turn the autorec on/off then all episodes are queued correctly. Perhaps, someone deleted the upcomming DVR entry? (there should be 'delete entry' lines in log)
@Em: Yes, it seems that the condition is not perfect. Perhaps, we should add the channel check instead start time in the second part of the condition, too.
Updated by Em Smith over 7 years ago
I'm not sure. Looks like that existing check is from 2012 (103de71f).
I think that check is probably there for Astra 28.2 since UK gets ~15 regional channels called BBC1 and maybe another 15 regional channels called ITV1, and similar numbers for HD counterparts and timeshift (+1 hour) channels. So all the ITV1 show mostly the same programmes at the same times but sometimes have an extra programme in the schedule or replace some programme with "regional interest" programme or a different film.
I think even people who say "record all" don't expect every regional channel to be recorded at the same start time since it will tie up the tuners, but it's reasonable to expect it to record on a different channel at a different time.
But if a channel check is added then presumably the upcoming tab will suddenly list (say) 14 other showings at the same time and then another 14 on timeshift +1 channel and then the "max schedules" check later on.
I run with a modified version since I kept getting channel 5+1 hour scheduled instead of channel 5, but not yet submitted it:
if (e->start >= de->de_start && strcmp(dae->dae_owner...
Perhaps the check (to work for Original Poster) should be:
(de->de_bcast == e || (de->de_bcast && de->de_bcast->episode == e->episode)) && e->start == de->de_start
So we drop programmes at the same start time for the exact same episode so we only have one upcoming recording showing for (say) 9pm and only one recording showing for 10pm (+1 channel), then rely on semantic duplicate detection to cancel the 10pm showings when they start at 10pm; or for OP the 10pm showing would also be recorded since no dup detection and the showing on the other channel a week later would also be scheduled and recorded ok.
Updated by Rob vh over 7 years ago
I manually fixed the Strictly recordings by doing a "Record program" action on the Thursday episode. The Autorec for Strictly is several years old.
The "Coast to coast" schedule is as I found it last Saturday. As you can see, only one of recording is made of each episode. I created the Autorecords on Saturday, clean and new.
Updated by Em Smith over 7 years ago
@Jaroslav: I did some basic testing with e->start==de->de_start and it seems to schedule ok. This was done using OTA (not SD) since my test env hasn't got SD listings for next week and it takes a long time to d/l.
So a "record all" where DVB-T and DVB-S are separate channels (not merged) gave recordings for Spike (DVB-T) and not Spike (DVB-S) for the identical start time of Tue@02:00; which I think is the correct response for "record all" since they are the same episode at the same time; and the S01E03 is recorded once on Channel 5 and on a different day on Spike.
I haven't tested actual recording, just that it scheduled.
@Robert E are you able to patch and compile? If so, I can give you a debug line to add which may indicate why it is not scheduling that one single episode of Strictly since that's a different issue to the Coast.
Updated by Em Smith over 7 years ago
- File 4640-extra-debug.patch 4640-extra-debug.patch added
I've added a patch for the extra debug (not a bug fix) in case you can apply it and test it before Thursday's non-recording of Strictly. So, patch, disable autorec rule for Strictly, re-enable rule and if the programme still isn't scheduled then the logfile might indicate why it failed to be scheduled.
This will give entries in your log (maybe /var/log/syslog) such as:
Not scheduling "Tony Robinson: Coast to Coast " on channel "Spike" because dup on "Channel 5+1" start: 1507597200 and de start: 1507662000 (e: 2017-10-10;02:00:00(+0100) de: 2017-10-10;20:00:00(+0100)) Not scheduling "Tony Robinson: Coast to Coast" on channel "Spike" because dup on "Spike" start: 1506992400 and de start: 1506992400 (e: 2017-10-03;02:00:00(+0100) de: 2017-10-03;02:00:00(+0100))
Updated by Rob vh over 7 years ago
I applied the patch (thank you, Em!). Then I deleted the "upcoming recordings for Coast to coast."
Next I changed the Duplicate handling from "record all" to "all: record if different episode", and deleted the upcoming recordings again.
Finally: changed the Duplicate handling back to "record all" and these were the messages
Oct 3 17:50:15 sat tvheadend28399: dvr: entry 446b9927ce3f2f7d80e6d67df72726ea "Tony Robinson: Coast To Coast" on "Channel 5 HD" starting at 2017-10-03 19:54:30, scheduled for recording by "10.29.1.48"
Oct 3 17:50:24 sat tvheadend28399: dvr: entry 8210bbe6af77e27d4bf8ae0d574cadac "Tony Robinson: Coast To Coast" on "Spike" starting at 2017-10-04 02:54:30, scheduled for recording by "10.29.1.48"
Oct 3 17:50:24 sat tvheadend28399: dvr: Autorecord "": Not scheduling "Tony Robinson: Coast To Coast" on channel "Spike" because dup on "Channel 5 HD" start: 1507251600 and de start: 1507053600 (e: 2017-10-06;03:00:00(+0200) de: 2017-10-03;20:00:00(+0200))
Note: I have 2 autorecs, one for Channel 5 HD (via a channel tag) and another for Spike (specifying the channel name).
There were 9 seconds between the update of the 2 autorecs, it seems.
Both autorecs have "record all"
The "not scheduling" recording is s01.e03, the same episode that will be recorded from Channel 5 HD tonight. See attachment.
By the way, at the moment, the autorec for Channel 5 HD is above the autorec for Spike in the list of autorecs. If I move them around, episode s01.e03 would have been recorded from the later Spike date, and the Channel 5 HD would never have been recorded.
Updated by Rob vh over 7 years ago
By the way, when I changed Duplicate handling, I noticed a line in the dvr/autorec directory
"record": 1,
and it went back to "record": 0, when I selected "record all" again.
Updated by Rob vh over 7 years ago
OK... I should not have closed the first update... I read the Help on Duplicate handling and decided to select "local: record if different episode."
To my surprise, the Spike recording is still skipped, even though the "local" option should have ignored Channel 5 HD.
Oct 3 18:16:44 sat tvheadend28399: dvr: entry fa94c8113d6c29b0665576ce4171bc05 "Tony Robinson: Coast To Coast" on "Spike" starting at 2017-10-04 02:54:30, scheduled for recording by "10.29.1.48"
Oct 3 18:16:44 sat tvheadend28399: dvr: Autorecord "": Not scheduling "Tony Robinson: Coast To Coast" on channel "Spike" because dup on "Channel 5 HD" start: 1507251600 and de start: 1507053600 (e: 2017-10-06;03:00:00(+0200) de: 2017-10-03;20:00:00(+0200))
see attachment.
Updated by Em Smith over 7 years ago
Could you do the same with the Strictly rule? Thanks.
Updated by Rob vh over 7 years ago
Strictly is now being selected just great. I suspect it had a bad recording number in the SD stream on Saturday.
Deleted the old "upcoming recordings" and changed "all: record if different episode"
Oct 3 17:46:37 sat tvheadend[28399]: dvr: entry 9cdca2622d54936f5bca6c6ba215ee1c "Strictly Come Dancing: It Takes Two" on "BBC Two HD" starting at 2017-10-03 19:24:30, scheduled for recording by "10.29.1.69" Oct 3 17:46:37 sat tvheadend[28399]: dvr: entry 760e925cdc5005735ecf02e465f14b95 "Strictly Come Dancing: It Takes Two" on "BBC Two HD" starting at 2017-10-04 19:24:30, scheduled for recording by "10.29.1.69" Oct 3 17:46:37 sat tvheadend[28399]: dvr: entry d37231c3b6f56bde3a6468de4561ec7d "Strictly Come Dancing: It Takes Two" on "BBC Two HD" starting at 2017-10-05 19:24:30, scheduled for recording by "10.29.1.69" Oct 3 17:46:37 sat tvheadend[28399]: dvr: entry c7e94434e9802ae765bf1a90d47e8c47 "Strictly Come Dancing: It Takes Two" on "BBC Two HD" starting at 2017-10-06 18:54:30, scheduled for recording by "10.29.1.69" Oct 3 17:46:37 sat tvheadend[28399]: dvr: entry cdc47b5e0847e894c0c9f8c4441bd7f4 "Strictly Come Dancing: It Takes Two" on "BBC Two HD" starting at 2017-10-09 19:24:30, scheduled for recording by "10.29.1.69" Oct 3 17:46:37 sat tvheadend[28399]: dvr: entry 151b9e902c393a311a40ec20c7e787bc "Strictly Come Dancing" on "BBC One HD" starting at 2017-10-07 19:29:30, scheduled for recording by "10.29.1.69" Oct 3 17:46:37 sat tvheadend[28399]: dvr: entry 2f43963f3f45f21925896e02ae6b82f5 "Strictly Come Dancing" on "BBC One HD" starting at 2017-10-08 20:09:30, scheduled for recording by "10.29.1.69"
Updated by Rob vh over 7 years ago
This is what happened when I had a manually created recording and changed the Duplicate handling before:
Oct 3 17:44:17 sat tvheadend[28399]: dvr: entry 01799a63f038660cac5c425209a5fa52 "Strictly Come Dancing: It Takes Two" on "BBC Two HD" starting at 2017-10-03 19:24:30, scheduled for recording by "10.29.1.69" Oct 3 17:44:17 sat tvheadend[28399]: dvr: entry 241ed706a4aeecd6ec3a8371bde4d32e "Strictly Come Dancing: It Takes Two" on "BBC Two HD" starting at 2017-10-04 19:24:30, scheduled for recording by "10.29.1.69" Oct 3 17:44:17 sat tvheadend[28399]: dvr: Autorecord "": Not scheduling "Strictly Come Dancing: It Takes Two" on channel "BBC Two HD" because dup on "BBC Two HD" start: 1507224600 and de start: 1507224600 (e: 2017-10-05;19:30:00(+0200) de: 2017-10-05;19:30:00(+0200)) Oct 3 17:44:17 sat tvheadend[28399]: dvr: entry 09a2a3d5a4a49895e7c6093d1ea2cb42 "Strictly Come Dancing: It Takes Two" on "BBC Two HD" starting at 2017-10-06 18:54:30, scheduled for recording by "10.29.1.69" Oct 3 17:44:17 sat tvheadend[28399]: dvr: entry c8ea49304bdc0b9a60fa890143309ab3 "Strictly Come Dancing: It Takes Two" on "BBC Two HD" starting at 2017-10-09 19:24:30, scheduled for recording by "10.29.1.69" Oct 3 17:44:17 sat tvheadend[28399]: dvr: entry 37d7e4624ab682573812c623d670d490 "Strictly Come Dancing" on "BBC One HD" starting at 2017-10-07 19:29:30, scheduled for recording by "10.29.1.69" Oct 3 17:44:17 sat tvheadend[28399]: dvr: entry a041f4d9ced24b824fd3950a13770c2d "Strictly Come Dancing" on "BBC One HD" starting at 2017-10-08 20:09:30, scheduled for recording by "10.29.1.69"
Updated by Em Smith over 7 years ago
- File 4640-only-dup-same-start-time-with-debug.patch 4640-only-dup-same-start-time-with-debug.patch added
Strange about the Strictly suddenly starting to work. Presumably your Strictly rule is just one regex rule of "^Strictly" recording on any channel and that picks up both shows.
The "local record" suffers the same issue as the "global record" in that we currently drop duplicate events immediately without doing any recording.
I had a one line patch that implements comment 6 but accidentally overwrote it when I created the debug patch. But, I've attached a patch that implements it with the same debug you already have. You probably have to revert the current patch before applying it (assuming you've done nothing else then git reset --hard HEAD).
This implements what isn't strictly the correct logic but is what I think is the intended logic. So, if you "record all" I don't think most people expect it to record on dvb-t and dvb-s at the same time and on HD and SD too, but would expect it to schedule a record for showing that were at a later time in the week.
I may have found the problem with your Strictly rule, see below.
@Jaroslav:
When testing, there seems to be unexpected interactions between rules, for example if you say "record all 'How I Met Your Mother' if local different subtitle" (which is a show that has hundreds of repeats through the week) then it correctly marks episodes as dups, but then adding a second rule to record all with no check for subtitle matches the existing dup recording and so doesn't schedule a recording for the second rule. This is consistent with behaviour I've seen from other DVR where an earlier "no record" will mask a later "record". HOWEVER, if you then disable the first rule, the recordings in the second rule aren't enabled.
So timeline:
rule1: record all "Simpsons"
rule2: record all "Simpsons" (schedules nothing since matches dups for existing upcoming recordings in rule1).
Disable rule 1
Result: Nothing at all is marked as scheduled, rather than all entries from rule2 being scheduled.
Perhaps something similar happened to OP where another rule matched that Thursday Strictly episode, that rule then is disabled so unschedules the Thursday Strictly, but the Strictly rule isn't re-run to re-match against that episode so that single episode is left as unscheduled?