Opened 3 years ago

Closed 7 weeks ago

#13038 closed Bug Report - General (Unverified)

Can't seek on serial IPTV recordings

Reported by: mythwiki@… Owned by: JYA
Priority: minor Milestone: unknown
Component: MythTV - Recording Version: 0.28.1
Severity: medium Keywords:
Cc: Ticket locked: no


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?

Attachments (2)

working.txt (7.5 KB) - added by mythwiki@… 3 years ago.
broken.txt (7.6 KB) - added by mythwiki@… 3 years ago.

Download all attachments as: .zip

Change History (8)

Changed 3 years ago by mythwiki@…

Attachment: working.txt added

Changed 3 years ago by mythwiki@…

Attachment: broken.txt added

comment:1 Changed 3 years ago by 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.

comment:2 Changed 3 years ago by 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.

comment:3 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by dekarl@…

The two supported ways of repairing the seektable are documented at

comment:5 in reply to:  4 Changed 3 years ago by mythwiki@…

Replying to dekarl@…:

The two supported ways of repairing the seektable are documented at

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.

comment:6 Changed 7 weeks ago by Stuart Auchterlonie

Resolution: Unverified
Status: newclosed

Closing all old tickets in trac.

If your issue still persists, please open an issue in Github

and reference the existing trac ticket.

Note: See TracTickets for help on using tickets.