[mythtv-users] Repairing corrupt recordings with dd

[John Pilkington]

On 26/06/2020 16:20, DaveD wrote:
> On 6/25/20 7:29 PM, Leo Butler wrote:
>> DaveD <mythtv at guiplot.com> writes:
>>
>>> On 6/23/20 3:09 PM, John Pilkington wrote:
>>>> On 23/06/2020 15:21, DaveD wrote:
>>>>> A while back (few weeks?) someone posted info about a technique to
>>>>> strip the first few megabytes from the beginning of a recording
>>>>> using dd.  It involved a discussion about the new video rendering
>>>>> system crashing the frontend (or casing decoder errors) on
>>>>> recordings where the format changes soon after the recording
>>>>> starts.  I swear I saved that message somewhere because I have a
>>>>> lot of those (thanks to Comcast and my firewire recordings) but
>>>>> I'll be dipped if I can find it. I've searched the archives, too,
>>>>> with no luck.  I could probably figure it our from the dd man page,
>>>>> but thought I'd ask for a re-post of that info since it's a tried
>>>>> and tested method. Thanks,
>>>>>
>>>>> Dave D.
>>>>>
>>>> I think you might be remembering this:
>>>>
>>>> https://code.mythtv.org/trac/ticket/13557#comment:13
>>>>
>>>> which looked for an appropriate skip value. applied it, and then
>>>> rebuilt the seektable.  The output file doesn't start at a keyframe,
>>>> but that doesn't seem to matter.
>>>>
>>>> John P
>>> That's it!  No wonder I couldn't find it in my old emails.  It was in
>>> my bookmarks.  Thanks you!
>> FWIW, I would recommend using mythffmpeg or ffmpeg rather than dd. The
>> former tools present no significant risk to your system.
>>
>> ffmpeg -ss 00:00:30 -i input.ts -codec copy -map 0 output.ts
>>
>> will seek (-ss) to the 30 second point in input.ts and copy each stream
>> in the input to the output. The copy codec is very fast and the safety
>> is worth the few extra seconds.
>>
>> I will guess that files with a mangled stream structure will cause
>> ffmpeg to error out, but I don't have a sample to check that guess on.
>> In either event, you can increase the seek time to try to find the
>> beginning of a stable stream structure.
> 
> Unfortunately I ran your command without looking up what -map 0 does and 
> it left me with only the audio.  Next time I'll try it without the -map 
> option (and leave a backup! duh!).  When it ran, it gave the same raft 
> of errors at first, just like ffprobe shows (not surprising), then it 
> created a nice, audio-only file.  Good to know if I want to extract the 
> audio from a recording some time.  :)
> 
> Dave D.

Some time ago I spent longer than was reasonable trying to get ffmpeg to 
cut h264 recordings; eventually it worked fairly well but only with a 
pre-run to reject all but 1 video and 1 audio stream - and playback 
needs to be working to establish the cutpoints.

I also have a small python script that does byte-accurate cuts of 'any' 
file.  I've just updated the posted version of that to python3.  There 
are probably more elegant ways of coding it, but it works.  Usually I 
use Project-X for cutting mpeg2 video content, but this is a calling 
script created as routine during a recent run:

{{{
#!/bin/bash
  mv  '/mnt/dat2/RSG3/10005_20200625195800.ts' 
'/mnt/dat2/RSG3/10005_20200625195800.ts.old'
  ionice -c3 ~/pycut.py '/mnt/dat2/RSG3/10005_20200625195800.ts.old' 
'/mnt/dat2/RSG3/10005_20200625195800.ts' 75221244 76677116 80142144 
218640804 282500644 541396008 612756860 797066044 862314640 1054189132 
1121304756 1364012756 1431629588 1568680460
}}}

All here:  https://www.mythtv.org/wiki/MythDVBcut

Mostly pycut.py gets used now to cut DVB radio recordings before 
extracting the audio.

John P