[mythtv-users] Recovering from transcode/bad seektable
Peter Bennett
pb.mythtv at gmail.com
Sat Sep 26 19:51:53 UTC 2020
On 9/26/20 3:33 PM, Ross Boylan wrote:
> I had a US OTA TV recording that was working fine. Somehow a
> transcode was triggered, the seek table became corrupt and now it's
> not watchable. I have repaired the seek table in the database
> (MariaDB) and regenerated the seek table for the recording. But it
> still isn't usable, and my effort to convert it back failed.
>
>
> Any suggestions?
>
> DETAILS
> My effort to convert back (it's unclear to me if mythtranscode can
> ever produce something in the original format,
> which was MPEG transport stream data):
> mythtv at barley:~$ date; time mythtranscode -i $VID -o ${VID}.1 --mpeg2
> --ostream ts
> Sat 26 Sep 2020 11:23:07 AM PDT
> 2020-09-26 11:23:07.365745 C mythtranscode version: rb02
> [v30.0-82-g541f52c2e4-dirty] www.mythtv.org <http://www.mythtv.org>
> 2020-09-26 11:23:07.365755 C Qt version: compile: 5.11.3, runtime: 5.11.3
> .....
> 2020-09-26 11:23:08.082933 N Transcoding from
> /srv/media10/media10-barley/22002_20200215205800.ts to
> /srv/media10/media10-barley/22002_20200215205800.ts.1
> 2020-09-26 11:23:08.083343 I Opening
> /srv/media10/media10-barley/22002_20200215205800.ts
> 2020-09-26 11:23:08.100018 I Estimating duration from bitrate, this
> may be inaccurate
> 2020-09-26 11:23:08.100080 I Input #0, nuv, from
> '/srv/media10/media10-barley/22002_20200215205800.ts':
> 2020-09-26 11:23:08.100091 I Duration: 06:50:25.63, start:
> 86612.405000, bitrate: 1411 kb/s
> 2020-09-26 11:23:08.100155 I Stream #0:0: Video: nuv (RJPG /
> 0x47504A52), yuv420p, 704x480, SAR 40:33 DAR 16:9, 59.94 fps, 59.94
> tbr, 1k tbn, 1k tbc
> 2020-09-26 11:23:08.100186 I Stream #0:1: Audio: mp3 (LAME /
> 0x454D414C), 48000 Hz, stereo, fltp, 1411 kb/s
> 2020-09-26 11:23:08.100246 W Warning: partial frame found!
> 2020-09-26 11:23:08.100420 W Warning: partial frame found!
> ... many more of those
> 2020-09-26 11:23:08.306255 W Warning: partial frame found!
> Handling Floating point exception
> Floating point exception
>
>
> The output file had 0 bytes.
>
> The original recording was around 2.5 hours; it now shows as 52
> minutes when I go to view it and the conversion program above
> estimates the length to be almost 7 hours.
>
> Aside from the misestimated length of time the main problem now is the
> audio, which is mostly a loud hiss with the voices very slow behind
> that. But the video appears regular speed. Before rebuilding the skip
> list, the video jumped from one still frame to another. The audio
> problem may be from https://code.mythtv.org/trac/ticket/13459 (my code
> may not have the fixes), which was one reason I was trying to convert
> out of nuv format.
>
> HISTORY
>
> 1. Transcoding
>
> The original transcode was triggered inadvertently, I assume, It did
> report some problems, likely from poor quality of the original signal.
> ------------------------------------- transcode logs (excerpts)
> ---------------------------------
> 2020-09-22 20:18:04.687235 N [31505/31505] CoreContext main.cpp:556
> (main) - Transcoding from
> /srv/media10/media10-barley/22002_20200215205800.ts to
> /srv/media10/media10-barley/22002_20200215205800.ts.tmp
> 2020-09-22 20:18:04.824896 I [31505/31505] CoreContext
> avformatdecoder.cpp:2222 (ScanStreams) - AFD: codec AC3 has 2 channels
> 2020-09-22 20:18:04.824994 I [31505/31505] CoreContext
> avformatdecoder.cpp:2771 (OpenAVCodec) - AFD: Opened codec
> 0x563d893cd1c0, id(AC3) type(Audio)
> 2020-09-22 20:18:04.833747 I [31505/31505] CoreContext
> avformatdecoder.cpp:2669 (ScanStreams) - AFD: Using ffmpeg for video
> decoding
> 2020-09-22 20:18:04.833802 I [31505/31505] CoreContext
> avformatdecoder.cpp:2771 (OpenAVCodec) - AFD: Opened codec
> 0x563d89384e80, id(MPEG2VIDEO) type(Video)
> 2020-09-22 20:18:04.833828 N [31505/31505] CoreContext
> audioplayer.cpp:166 (ReinitAudio) - AudioPlayer: Enabling Audio
> 2020-09-22 20:18:04.866934 N [31505/31505] CoreContext
> transcode.cpp:120 (GetProfile) - Transcode: Looking for autodetect
> profile: Autodetect from 480p
> 2020-09-22 20:18:04.951912 I [31505/31511] SendMessage
> mythcorecontext.cpp:451 (ConnectCommandSocket) -
> MythCoreContext::ConnectCommandSocket(): Connecting to backend server:
> 192.168.1.10:6543 <http://192.168.1.10:6543> (try 1 of 1)
> 2020-09-22 20:18:04.953804 I [31505/31511] SendMessage
> mythcorecontext.cpp:1677 (CheckProtoVersion) -
> MythCoreContext::CheckProtoVersion(): Using protocol version 91 BuzzOff
> 2020-09-22 20:18:05.049724 N [31505/31505] CoreContext
> transcode.cpp:145 (GetProfile) - Transcode: Using autodetect profile:
> MPEG2
> 2020-09-22 20:18:05.079692 N [31505/31505] CoreContext
> transcode.cpp:817 (TranscodeFile) - Forcing Recorder option
> 'videocodec' to ''
> 2020-09-22 20:18:05.079716 E [31505/31505] CoreContext
> recorders/recorderbase.cpp:211 (SetOption) - RecBase[NULL]():
> SetOption(): Unknown int option: videocodec: 0
> 2020-09-22 20:18:05.136841 I [31505/31505] CoreContext
> transcode.cpp:1084 (TranscodeFile) - Copying Audio while transcoding Video
> 2020-09-22 20:18:05.144283 I [31505/31511] VideoDecodeBuffer
> mythcodeccontext.cpp:322 (InitDeinterlaceFilter) - MythCodecContext:
> Disabled hardware decoder based deinterlacer.
> 2020-09-22 20:18:05.145705 E [31505/31505] CoreContext
> mythsystemevent.cpp:345 (SendMythSystemRecEvent) -
> MythSystemEventHandler: SendMythSystemRecEvent() called with empty
> RecordingInfo
> 2020-09-22 20:19:37.784950 E [31505/31511] VideoDecodeBuffer
> avformatdecoder.cpp:5116 (ProcessAudioPacket) - AFD: Unknown audio
> decoding error
> 2020-09-22 20:21:03.982880 E [31505/31511] VideoDecodeBuffer
> avformatdecoder.cpp:5116 (ProcessAudioPacket) - AFD: Unknown audio
> decoding error
> 2020-09-22 20:22:10.782730 E [31505/31511] VideoDecodeBuffer
> avformatdecoder.cpp:5312 (GetFrame) - decoding error End of file
> (-541478725)
> ------------------------- end transcode logs
> --------------------------------------------
> After waiting for the recording not to be in use, the old version was
> replaced by the new one.
>
> 2. Seek table and database
>
> Problems viewing the transcoded recording led to the discovery there
> was no seek table for it.
> Ran optimize_mythdb.pl <http://optimize_mythdb.pl>, but it hung up
> when it got to the recordedseek table.
>
> This led to the discovery the recordedseek table was corrupt--i.e.,
> the whole table, not just the info for that show.
> I think the ultimate cause was that the root partition, which was
> being used for /tmp by mariadb, couldn't hold the
> working files mariadb put there. I grew the partition.
>
> ----------------------------------------------------------- SQL
> ------------------------------------------------------------------------------
> check table recordedseek;
> MariaDB [mythconverg]>
> +--------------------------+-------+----------+-------------------------------------------------------------+
> | Table | Op | Msg_type | Msg_text
> |
> +--------------------------+-------+----------+-------------------------------------------------------------+
> | mythconverg.recordedseek | check | warning | Table is marked as
> crashed and last repair failed |
> | mythconverg.recordedseek | check | warning | Size of indexfile is:
> 1201630208 Should be: 1024 |
> | mythconverg.recordedseek | check | error | Found key at page -1
> that points to record outside datafile |
> | mythconverg.recordedseek | check | error | Corrupt
> |
> +--------------------------+-------+----------+-------------------------------------------------------------+
>
> repair table recordedseek;
> +--------------------------+--------+----------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
> | Table | Op | Msg_type | Msg_text
> |
> +--------------------------+--------+----------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
> | mythconverg.recordedseek | repair | Warning | Disk is full writing
> '/tmp/ST08wgwF' (Errcode: 28 "No space left on device"). Waiting for
> someone to free space... (Expect up to 60 secs delay for server to
> continue after freeing disk space) |
> | mythconverg.recordedseek | repair | Warning | Retry in 60 secs.
> Message reprinted in 600 secs
> |
> | mythconverg.recordedseek | repair | Warning | Retry in 60 secs.
> Message reprinted in 600 secs
> |
> | mythconverg.recordedseek | repair | Warning | Retry in 60 secs.
> Message reprinted in 600 secs
> |
> | mythconverg.recordedseek | repair | Warning | Retry in 60 secs.
> Message reprinted in 600 secs
> |
> | mythconverg.recordedseek | repair | status | OK
> |
> +--------------------------+--------+----------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
> 6 rows in set (35 min 0.632 sec)
> -- I realized the /tmp partition was the problem and expanded it
>
> +---------------------+
> | now() |
> +---------------------+
> | 2020-09-24 00:30:53 |
> +---------------------+
> 1 row in set (0.001 sec)
>
> check table recordedseek;
> MariaDB [mythconverg]>
> +--------------------------+-------+----------+----------+
> | Table | Op | Msg_type | Msg_text |
> +--------------------------+-------+----------+----------+
> | mythconverg.recordedseek | check | status | OK |
> +--------------------------+-------+----------+----------+
>
> ---------------------------------------------------------- end
> SQL------------------------------------------
>
> The recordedseek table is extremely large on disk, a bit over 1TB each
> for .MYD and .MYI files.
> I gather it's expected to be large; I have about 10TB of recordings.
> But the warning about the
> expected size of the index file (namely ~1K) makes me wonder if
> something has gone wrong.
>
> The rebuild of the seek table used
> mythcommflag --file
> /srv/media10/media10-barley/22002_20200215205800.ts --rebuild
> and reported success.
>
>
My recommendation would be:
1. Clear the seektable for the recording -
mythutil --clearseektable --chanid "$chanid" --starttime "$starttime"
2. repair the recording file with
mkvmerge -o outputfile.mkv originalfile.ts
3. replace the file with the repaired file
cp outputfile.mkv originalfile.ts
(keep a copy of the original file in case this makes things worse)
If it still will not play, try playing the file with vlc. The recording
itself may be corrupt.
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200926/4004a236/attachment-0001.htm>
More information about the mythtv-users
mailing list