[mythtv-users] Repairing corrupt recordings with dd

[Leo Butler]

DaveD <mythtv at guiplot.com> writes:

> 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.  :)

Re: -map 0

see: https://ffmpeg.org/ffmpeg-all.html#toc-Manual-stream-selection

That selects all streams in input 0 to be mapped to the output,
regardless of ffmpeg's defaults. You will be deceived if you try it to
extract audio only (you would use -vn -map 0:a for that).

Your result indicates ffmpeg couldn't find a stable stream other than
audio. My suggestion was to increase the seek time to find a stable
video stream. Then the command above will work fine.

You can also use substitute ffplay in place of ffmpeg, viz.

ffplay -ss 00:00:30 -i input.ts

This will output info similar to ffmpeg and try to play the file, too.

Could you put a sample of such a file somewhere? It should be long enough
to include all the instability at the beginning and then a 1-2 stretch
with a stable stream structure.

Thanks,
Leo