[mythtv-users] Curious fast forward problem

[Michael T. Dean]

On 01/06/2021 04:36 PM, Michael T. Dean wrote:
> On 01/06/2021 03:54 PM, Peter Bennett wrote:
>>
>> On 1/5/21 11:56 AM, mythtv wrote:
>>> We've been experiencing this weird fast forward behaviour for 
>>> several versions now. I assume it must just be something we're doing 
>>> wrong because it's never changed since at least v0.28 and no one 
>>> else seems to be talking about it.
>>>
>>> What happens is this: We have auto-skip commercials turned off. When 
>>> watching live tv, if we're delayed for more than a few minutes, then 
>>> hit fast-forward to manually skip thru some commercials, 9 out of 10 
>>> times, we can skip  thru a few commercials but sometimes it will 
>>> just jump forward to almost live again (a few seconds behind live).  
>>> I hope I explained that correctly.  Its not "consistent" but it 
>>> happens frequently enough to be a real nuisance, especially when our 
>>> remote doesn't have numbers allowing us to just jump back a certain 
>>> number of minutes. And also, the amount jumped is not a consistent 
>>> amount of time, it always just jumps to near live again.  I believe 
>>> the backend is marking commercial breaks, and maybe there is some 
>>> weirdness in trying to jump forward without a correct number of 
>>> commercial breaks recorded, or some other setting about the length 
>>> of commercials, etc. I don't quite understand all of those settings, 
>>> and I don' think I've changed any from the defaults, other than to 
>>> disable commercial auto-skip.
>>>
>> I have noticed this when watching a program that is still recording. 
>> As you mention, it has been around for a long time. The biggest 
>> problem with fixing it is that it is so intermittent. In my 
>> experience it only happens maybe one time out of every 10 programs 
>> watched while recording. It seems to happen occasionally when I am 
>> around 15 minutes before the end, on a single skip forward it jumps 
>> to the end instead of jumping 1 minute. It is not related to marking 
>> commercial breaks. I believe it is something wrong with the way the 
>> system keeps track of the increasing program size and the amount 
>> remaining. If you can identify how to reproduce it, maybe we can 
>> solve it.
>
> Are you sure that the frontend just hasn't gotten an update to the 
> currently-detected commercial skiplist and, perhaps, the last update 
> it received was one with a commercial start but without its 
> accompanying commercial end?  Basically it received an update while 
> the commercial detection was inside a commercial break (so the last 
> mark was a MARK_COMM_START ) and the backend hasn't sent out an update 
> that includes the MARK_COMM_END ?
>
> IIRC, I think the COMMFLAG_UPDATE event tends to be sent (to any 
> frontends that requested updates for that program with a 
> COMMFLAG_REQUEST event) every 500 frames or so of commercial 
> detection, so that would be around 8m 20s of actual program time for a 
> 60fps show, but depending on how busy/powerful the system running the 
> commercial detection is and depending on how far it's trying to stay 
> away from the "now" of the recording, I could see how it could be 
> 10+min behind now.  For interlaced video, I'm not sure if it's 
> actually frames or fields, but if it's still 500 frames, an update 
> would be sent after processing about 16m 40s of recording in a 1080i60 
> show, for example.
>
> It's possible that when the flagger recomputes the commercial skip 
> list, it ensures it never ends with a MARK_COMM_START, in which case 
> this shouldn't be the problem, but I haven't looked.
>
> Anyway, just a thought.  If nothing else, something like this could 
> explain the intermittency of the issue.  Feel free to ignore me if my 
> guess is way off, though.  :)

Jeremy's last message that he's had real-time commflag disabled seems to 
indicate it's not the commercial skip list, so ignore.  I don't know how 
the player/recorder handle seek table updates, but I'd assume they're 
not nearly so infrequent as COMMFLAG_UPDATEs.

Mike