[mythtv-users] Repairing corrupt recordings with dd

[Leo Butler]

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.

Leo