some recordings immediately show end of recording dialog and fail seek table rebuild

[adeffs.mythtv@…]

Some recordings, mostly on HDPVR, will immediately show the end of recording dialog box when attempting playback. The screenshot on the recordings list will appear, and just before the dialog box appears a frame (maybe more than one) of video do appear, but then the dialog box appears.

I attempted to rebuild the seektable which fails, and will attach the log from this as the frontend log during playback does not appear to show anything (both with -v most).

[adeffs.mythtv@…]

rebuild seektable

[RailRodder@…]

I have the exact same problem. I can add that I can commflag and watch recording while it is still recording. After recording stops cannot play file in myth. Works in ffplay, mplayer & gnome video. If I remux to ts stream with ffmpeg (acodec copy vcodec copy) I can the rebuild index and watch.

[John Pilkington <J.Pilk@…>]

I wonder if this could be related:

​http://www.gossamer-threads.com/lists/mythtv/users/556288?search_string=mythffmpeg;#556288

Quoting the intro in a long thread: "I've just made a recording (dvb-t) that the frontend couldn't play, although vlc could. It was on cbbc (DVB_T) and overlapped the 'end of service' time on that channel."

I still see this if the schedule is like that, but I have a workaround that fits easily into my procedures.

[Timothy Pearson <kb9vqf@…>]

This hit me as well when I upgraded my old 0.24 installation to 0.27. Many (but not all) of my H264 recordings became unwatchable; the system would sit for 10 seconds at the "Please Wait" screen while spewing "Taking too long to be allowed to read" on the terminal. Needless to say the WAF dropped to zero at this point. ;-)

The workaround mentioned in the linked thread (mythfrontend -O FFMPEGTS=1) restored playback functionality. Further analysis showed the failing recordings to contain multiple resolution changes including one near the end of the file. mythffplay and ffplay think the failing files are only a second long when in fact they are nearer to 1-2 hours in length, yet both play the file perfectly. Perhaps this is a clue?

If anyone wants to investigate I think I have a reliable method for producing these unplayable files. I can try it with Big Buck Bunny or similar and post the resulting file for analysis if desired.

[blm-ubunet@…]

Can you post a sample of first 100MB (using dd) from a problem recording? I don't have any H264 samples that do not play or seek correctly.. Has been talk about files that do not play but I can't find them..

Transport stream files are allowed to have timecode discontinuities & could defeat the simple duration calculations (if that is the cause). But the error sounds like "it" is not finding a start point..

[Timothy Pearson <kb9vqf@…>]

Replying to blm-ubunet@…:

Can you post a sample of first 100MB (using dd) from a problem recording? I don't have any H264 samples that do not play or seek correctly.. Has been talk about files that do not play but I can't find them..

Transport stream files are allowed to have timecode discontinuities & could defeat the simple duration calculations (if that is the cause). But the error sounds like "it" is not finding a start point..

To make matters more complicated dd-ing up to the first 90% or so of the file and playing the truncated file instead of the original file causes the failure to disappear. It seems that Myth is choking on something in the last 10% or so of the file. Unfortunately the 0.27 upgrade also killed off the ability to record new H264 files from my HDPVR (analog RGB component input with optical sound), so until I get that fixed I won't be able to provide a complete example file illustrating the problem.

[Timothy Pearson <kb9vqf@…>]

Replying to Timothy Pearson <kb9vqf@…>:

Replying to blm-ubunet@…:

Can you post a sample of first 100MB (using dd) from a problem recording? I don't have any H264 samples that do not play or seek correctly.. Has been talk about files that do not play but I can't find them..

Transport stream files are allowed to have timecode discontinuities & could defeat the simple duration calculations (if that is the cause). But the error sounds like "it" is not finding a start point..

To make matters more complicated dd-ing up to the first 90% or so of the file and playing the truncated file instead of the original file causes the failure to disappear. It seems that Myth is choking on something in the last 10% or so of the file. Unfortunately the 0.27 upgrade also killed off the ability to record new H264 files from my HDPVR (analog RGB component input with optical sound), so until I get that fixed I won't be able to provide a complete example file illustrating the problem.

Update: Looks like the HDPVR (Myth?) cannot handle audio format changes. If an audio format change occurs (e.g. from a channel change) the recording becomes unplayable on *any* player. This is new in 0.27 (it did not happen in 0.24 on identical hardware) and I guess I will need to open a new bug report for it. I am working on getting test files together for this problem as well.

Seems that the HDPVR didn't get much testing in 0.27?

[J.Pilk@…]

These new Comments reminded me that my Comment 2 above related to SD mpeg2 recordings, not H264. cbbc is now available in HD H264 as well, with the same handover to BBC THREE HD at the same time. A new recording extending over that changeover also fails to play in 0.27-fixes, now at -178-, but does play with frontend -O FFMPEGTS=1 It plays via uPnP too, and in vlc. SL6-etc i686, ffmpeg 0.10.11, Intel 945GM. Direct HD playback is always CPU-limited on this box.

[Timothy Pearson <kb9vqf@…>]

Any chance you could post the requisite file? Since the upgrade I cannot seem to generate new recordings that exhibit this bug, which means I can't generate a FOSS test file at the moment. :-(

[J.Pilk@…]

I'm uploading a 40 MB sample including the cbbcHD end-of-schedule from UK DVB-T2, cut using dd bs=1M skip=560 count=40, so the start position is effectively unrelated to signal content. It plays in mythfrontend for me with ffmpeg active, doesn't play with mythffmpeg

​https://www.mediafire.com/?c7313g4uoabb1me

[J.Pilk@…]

dd bs=1M count=20 on that sample gives a file that plays normally with mythfrontend, and mythcommflag -rebuild creates a good seektable; I'm using the patch from Ticket #12010 for that.

Longer clips need mythfrontend -O FFMPEGTS=1, and mythcommflag -rebuild fails with

2014-03-21 18:10:44.513847 E VideoOutput?: Not compiled with any useable video output method. 2014-03-21 18:10:44.513864 E Player(0): Couldn't create VideoOutput? instance. Exiting.. 2014-03-21 18:10:44.513888 E RebuildSeekTable? unable to initialize video

[blm-ubunet@…]

Your cbbcHDend.mpg plays okay in master without using FFMPEGTS override. Bit slow to start tho.. mythcommflag --rebuild fails unless you use the override. Seeking by keyframes (cutlist editor) is fine.

Recent ffmpeg (6 months old git) outputs a completely different stream information/summary c.f. mythffmpeg. ffplay plays it fine.

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