Opened 6 years ago

Closed 5 years ago

#11634 closed Bug Report - General (Unverified)

Frontend shows VERY wrong recording-length after lossless MPEG cutting+transcoding

Reported by: oli.henning@… Owned by:
Priority: minor Milestone: unknown
Component: MythTV - General Version: 0.26-fixes
Severity: medium Keywords:
Cc: Ticket locked: no


Just updated from 0.25 to 0.26-fixes.

Now, when i hit 'i' while watching a recoding, the frontend says a length somthing _longer_than_one_day. But the recording itself (after cutting/transcoding) ist just 00:20:25 (hh:mm:ss).


  • Recoding with DVB-C, MPEG2-Video (720x576@25.00fps)
  • Set two cut-points to remove everything before an after the show-of-interest.
  • Filesize after transcode is 642'795'524 Bytes (~614 MBytes)
  • RecordedSeek?-Table: 2671 Entries, going from mark=0 to mark=30'627 and offset=0 to offset=642'762'766. This is a little smaller that the filesize.
  • As the maximum mark-value is 30627 an here in europe we have 25fps. This results in 1225 seconds = 20:25 (mm:ss)
  • On pressing 'i' the bar shows a length of 26:22:08 (hh:mm:ss).

I have absolutly no idea from where the frontend has this value. Some ideas/calulations i did:

  • 26:22:08 = 94'928 seconds. The recoding is 1225 seconds. This is factor 77.5 -> no 'magic' number
  • 26:22:08 minus 24 hours = 02:22:08. And then i have a UTC-Offset of 2 hours (CET, central european summertime)--> 00:22:08. But this is still not the expectd 00:20:25...
  • I tried to recreate the seektable with "mythtranscode -b". But as i sayed, the seektable seems to be correct.

Any suggentions, how to make further analysis?

Change History (6)

comment:1 Changed 6 years ago by Kenni Lund [kenni a kelu dot dk]

Was the recording created with 0.25? If so, does the issue still exist for new recordings created with 0.26? Personally, when I upgraded from MythTV 0.25 to 0.26 I had to rebuild the seektables with mythcommflag for all of my old 0.25 recordings, in order to get the correct recording lengths back. If this is the issue you're seeing, there's already a ticket open about it somewhere in Trac (can't find it right now).

comment:2 Changed 6 years ago by oli.henning@…

No, there is no 26-hour-duration-problem with old 0.25-recordings. I didn't have to recreate the seektables for these old recordings. Everything seems to be perfect here. But all og these 025-recordings were already cutted (and lossless-transcoded) also with 0.25.

The problem occurs just with new 0.26-recordings.

I did some deeper investigations and i recognized the DB-table recordedmarkup. There should be entries with type=33 and type=34 (one for MARK_DURATION_MS and the other for MARK_TOTAL_FRAMES, see The problematic recordings did not have these entries. After running mythcommflag --rebuild these entries apperar - and the 26-hour-duration-problem disappears.

BTW: for the older 0.25-recordings, these entries are also missing but there is no 26-hour-duration-problem. Hm...

And: Running mythtranscode --buildindex ... did not solve the problem. This command should also "Repair the Seektable" (see but does obviously not the same.

Perhaps i have to mention that i never run mythcommflag neither to mark commercials nor to do anything else. This job is disabled in my MythTV installation. I just use recording, manually setting cut-points and then do a lossless-MPEG2-transcoding. Perhaps this is so 'special' so that i observe the 26-hour-duration-problem.

comment:3 Changed 6 years ago by Nicolas Pöhlmann <nicolas.poehlmann@…>

Even in 0.27/fixes RC this problem exists. Running mythtranscode again fixes the duration problem mostly. Sometimes another mythranscode run is needed to fix it. This is a regression since version 0.26 and happens in about 50% of my mythtranscode/lossless transcodings.

comment:4 Changed 6 years ago by oli.henning@…

Very interesting, as i also updated to 0.27/fixes. And it seems that the problem disappeared.

But i made just a few transcodings until now. So i will observe it an report here in a few weeks.

comment:5 Changed 5 years ago by oli.henning@…

Now as i'm usung 0.27/fixes a few weeks i confirm that the error seems to be fixed. I don't know when and how - but i never observed it any more.

So i think one can close this ticket.

comment:6 Changed 5 years ago by Kenni Lund [kenni a kelu dot dk]

Resolution: Unverified
Status: newclosed
Note: See TracTickets for help on using tickets.