[mythtv-users] Script to repair recordings with dd

[John Pilkington]

On 22/07/2020 05:00, DaveD wrote:
> I have two sources; OTA via an antenna and dual tuner and two cable STBs 
> via firewire on a master backend and a slave backend. By looking at the 
> recordings with ffprobe, I have determined that the latter (cable) is 
> h264 while the former all seems to be mpeg2video and a much higher 
> quality and larger file sizes.
> 
> I have had this setup for years and, until V.31, all worked well.  Now, 
> the cable recordings (which are becoming fewer all the time as I improve 
> my antenna system) have trouble.  Occasionally, some attempts at 
> playback cause the frontend to fail with "Decoder Error" and, less 
> often, even crash the frontend.  Also, mythcommflag hangs at times on 
> the h264 recordings and rarely finds commercials accurately.  The OTA 
> recordings (mpeg2video) never have trouble with playback or commercial 
> flagging.  These problems are discussed in this bug report/discussion: 
> https://code.mythtv.org/trac/ticket/13557#comment:13
> 
> Unfortunately, I also switched from Nvidia/VDPAU to Intel/VAAPI at the 
> same time I upgraded to V.31, so I'm not sure how much of my problems 
> are specific to VAAPI, but the commflag problems are unrelated to 
> playback, so I suspect it is the highly compressed h264 recordings not 
> fitting into the new playback mechanism.
> 
> Anyway, the above-mentioned thread gives instructions on how to use dd 
> to removed the beginning of the recording, which renders a recording 
> that formerly crashed the frontend playable.  I have repaired three 
> recordings, so far, and it has worked perfectly each time.  I have 
> incorporated the technique into a script and included it, below.  I 
> found that ffprobe was giving me durations that were MUCH higher that 
> they should be (one 2-hour show reported an 11 hour duration) so, since 
> I didn't know what else to look for in ffprobe's output, I used that 
> duration and compared it with what should have been, based on a database 
> query.  If the duration is more than .2 hours longer than the database 
> time, I run dd, strip off the beginning of the file, then rebuild the 
> seektable with mythcommflag (per the above-mentioned bug report).
> 
> Speaking of ffprobe's output:  the h264 recordings all start with a 
> series of error messages:
> 
> [h264 @ 0x557c4ec5aa40] SPS unavailable in decode_picture_timing
> [h264 @ 0x557c4ec5aa40] non-existing PPS 0 referenced
> [h264 @ 0x557c4ec5aa40] SPS unavailable in decode_picture_timing
> [h264 @ 0x557c4ec5aa40] non-existing PPS 0 referenced
> [h264 @ 0x557c4ec5aa40] decode_slice_header error
> [h264 @ 0x557c4ec5aa40] no frame!
> 
> This repeats over and over (sent to stderr) anywhere from 20 to 80 (or 
> more?) times before it finally gives normal (although sometimes 
> inaccurate) clip information.  I'm not sure what to make of it and 
> didn't really feel like studying ffprobe to figure it out.
> 
> Here's that script.  I run it with cron every AM at 3:30.  I assume 
> there will be no more "Decoder Error" messages/crashes.
> 
> Dave D.
> 

I was interested to see your script, and I'm glad it works for you;  but 
the test based on apparent recording duration may not apply generally.

I suspect that the difference you see between v31 and earlier versions 
arises because the player is now doing its stream analysis at an earlier 
point in the recording file, and that may be before the structure has 
settled.

John P