Can't seek on serial IPTV recordings

[mythwiki@…]

When two shows are recorded one after another on the same channel with an IPTV recorder (I am using the TBS2603), the tuner isn't stopped and restarted, instead the ongoing stream is written to a new file. Something in this second file prevents MythTV from seeking. You cannot jump forward or back, and cannot use the cutlist editor.

Using mythcommflag --rebuild does not fix the problem.

I am attaching several lines of output of

ffmpeg -nostats -i <FILENAME> -vf showinfo -f null -

for the first (working) and second (broken) recordings, in case that helps.

There isn't much to see in those files, except that it looks like the recording is transitioned exactly on a keyframe, which is good. The first recording doesn't start on a keyframe, so there is, in this case, 0.87 seconds of unusable data at the beginning of the file. That's not a big problem, my keyframe distance is 1 second. The other thing that's interesting is that the broken file has pts that starts at 0, while the working on starts at a larger pts. However, if you allow for approximately 3003 pts counts per frame, then the missing frames at the beginning of the working recording should start at zero also. Are there any other statistics I can provide to help?

[mythwiki@…]

I've looked in the recordedseek table for a non-working recording. The records of type=33 have frame numbers that look right, but the offset is zero for all entries. In the working recording, 'offset' is the position in the file of the keyframe.

[mythwiki@…]

I'm still walking through this code. Right now, I've gone far enough up to see that, on avformatdecoder.cpp:3546, pkt->duration is zero. This is why the database is getting filled with zeroes, the duration counter isn't being incremented. That has me looking around av_read_frame() now.

[mythwiki@…]

For now, I can fix this within SQL:

$ mythconverg mysql mysql> update recordedseek set offset=(mark / 30) * 1001 where chanid=<NUM> and starttime=<WHEN> and type=33 and mark > 0 and offset=0;

This works at least on fresh recordings, where no cutlists have yet been added. It assumes 29.97 frames per second. The multiplier would be different on PAL recordings.

[dekarl@…]

The two supported ways of repairing the seektable are documented at ​https://www.mythtv.org/wiki/Repairing_the_Seektable

[mythwiki@…]

Replying to dekarl@…:

The two supported ways of repairing the seektable are documented at ​https://www.mythtv.org/wiki/Repairing_the_Seektable

Neither of these techniques fixes the problem I'm reporting. In fact, both of them, if used on a working recording, introduce the corruption into the seek table. I believe this is due to the ffmpeg libraries returning 0 as the duration of packets in this type of stream.

The stream is h.264 high profile video in an mpegts container, with 48kHz AAC stereo audio.

[Stuart Auchterlonie]

Closing all old tickets in trac.

If your issue still persists, please open an issue in Github ​https://github.com/MythTV/mythtv/issues

and reference the existing trac ticket.