[mythtv-users] Repairing corrupt recordings with dd

[Leo Butler]

Leo Butler <leo.butler81 at googlemail.com> writes:

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

A second thought: have you actually run ffplay/ffprobe on the file you
created? Are you sure that it contains only an audio stream?

Console output would be helpful.

Here is another way to probe into the original file:

ffprobe -i input.ts -read_intervals '60%+#1' -show_frames

That seeks to 60 seconds and shows the frame info for 1 packet.

https://ffmpeg.org/ffprobe-all.html#toc-Main-options

Leo