[mythtv-users] Recovering from transcode/bad seektable
Ross Boylan
rossboylan at stanfordalumni.org
Sat Sep 26 19:33:06 UTC 2020
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
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 (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, 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200926/1dac3eb7/attachment.htm>
More information about the mythtv-users
mailing list