[mythtv-users] Repairing corrupt recordings with dd

[DaveD]

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.