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

[oli.henning@…]

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).

Details:

• 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?

[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).

[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 http://www.mythtv.org/wiki/Recordedmarkup_table). 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 http://www.mythtv.org/wiki/Repairing_the_Seektable) 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.

[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.

[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.

[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.