Bug #4739
EITp/f: may cause recordings to continue forever
0%
Description
Rather weird bug I caused myself. If you disable a tuner during a recording the event will continue to record after switching to another tuner, awesome!
However, if you have EITp/f enabled and the new tuner uses a different source (went from DVB-T to DVB-S) with non-matching EITp/f data/or none at all, the recording will never end!
I'd recorded about 8 hours of a single channel because of it.
@Em Smith - Sorry to add you in here, but could you test this out please? Thanks.
History
Updated by Em Smith about 7 years ago
Updated by I've certainly had that problem a few times in the past (and glad I restart it every day), but I don't recall if it was due to switching inputs such as a higher priority recording.
I should be able to give it a test later.
Updated by Mark Clarkstone about 7 years ago
Updated by Em Smith wrote:
I've certainly had that problem a few times in the past (and glad I restart it every day), but I don't recall if it was due to switching inputs such as a higher priority recording.
I should be able to give it a test later.
I'm honestly not sure, but I remember disabling a tuner (due to a buggy driver causing errors in the stream), 8 hours later the recording was still going!
I've also had it when I've recorded programmes on a channel where the transmission stops afterwards.
Do you think there should be a eitp/f timeout option? By that I mean if no flag is received after a certain time (user-configurable) it should stop?
Updated by Em Smith about 7 years ago
That seems like a good idea since I doubt most people want a programme recording for more than (say) an hour after it's meant to finish.
I haven't really looked in to the p/f code, but perhaps the post-record-pad could be used as a maximum timeout for the case where eit is enabled.
Updated by Em Smith about 7 years ago
It seems to work for me. I tried recording in the middle of the programme and then failing my sat>ip so it went to DVB-T and it finished ok.
I also tried recording an entire programme just in case p/f didn't work on partial recordings and did multiple failovers between sat>ip tuners and to DVB-T and that finished too even though it was on DVB-S to start and DVB-T at the end.
However on both occasions, even with use epg state, it seemed to stop at exactly the post-recording padding which seems an amazing coincidence. Although it just occurred to me that I don't have any OTA enabled. Is that necessary?
Anyway, the recording state for 00:30 went to PENDING->EPGWAIT (30s)->RUNNING (at exactly 00:30)->WAIT->RUNNING (at exactly 00:30, the start time)->ERROR->RUNNING->WAIT->RUNNING->ERROR->RUNNING->WAIT->RUNNING->FINISHED (at exactly stop+padding).
Updated by Mark Clarkstone about 7 years ago
Em Smith wrote:
It seems to work for me. I tried recording in the middle of the programme and then failing my sat>ip so it went to DVB-T and it finished ok.
I also tried recording an entire programme just in case p/f didn't work on partial recordings and did multiple failovers between sat>ip tuners and to DVB-T and that finished too even though it was on DVB-S to start and DVB-T at the end.
However on both occasions, even with use epg state, it seemed to stop at exactly the post-recording padding which seems an amazing coincidence. Although it just occurred to me that I don't have any OTA enabled. Is that necessary?
Anyway, the recording state for 00:30 went to PENDING->EPGWAIT (30s)->RUNNING (at exactly 00:30)->WAIT->RUNNING (at exactly 00:30, the start time)->ERROR->RUNNING->WAIT->RUNNING->ERROR->RUNNING->WAIT->RUNNING->FINISHED (at exactly stop+padding).
It's weird. the tuner bugged out -> I got a message telling me of excessive errors (custom py script), disabled the tuner, it switched to DVB-S. Even the errors from the buggy tuner remained!