Mailing List Archive

Recovering from transcode/bad seektable
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@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.
Re: Recovering from transcode/bad seektable [ In reply to ]
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@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
Re: Recovering from transcode/bad seektable [ In reply to ]
Thanks for your very concrete suggestions. Unfortunately, I still can't
view the video.
Some details below, and a question: should I regenerate the seek table in
myth?

On Sat, Sep 26, 2020 at 12:52 PM Peter Bennett <pb.mythtv@gmail.com> wrote:

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

> My recommendation would be:
>
> 1. Clear the seektable for the recording -
>
> mythutil --clearseektable --chanid "$chanid" --starttime "$starttime"
>
done

> 2. repair the recording file with
>
> mkvmerge -o outputfile.mkv originalfile.ts
>
$ mkvmerge -o ${VID}.mkv $VID
mkvmerge v35.0.0 ('All The Love In The World') 64-bit
'/srv/media10/media10-barley/22002_20200215205800.ts': Using the
demultiplexer for the format 'MPEG-1/2 video elementary stream'.
'/srv/media10/media10-barley/22002_20200215205800.ts' track 0: Using the
output module for the format 'MPEG-1/2 video'.
The file '/srv/media10/media10-barley/22002_20200215205800.ts.mkv' has been
opened for writing.
Warning: Found at least one B frame without second reference in a non
closed GOP.
Progress: 100%
The cue entries (the index) are being written...
Multiplexing took 37 seconds.

But mkv does not report an audio track on the original. I don't know if
that's normal for nuv;
it's not what I see for the original streams:

mythtv@barley:~$ mkvmerge -i $VID
File '/srv/media10/media10-barley/22002_20200215205800.ts': container:
MPEG-1/2 video elementary stream
Track ID 0: video (MPEG-1/2)
mythtv@barley:~$ mkvmerge -i
/srv/media10/media10-barley/22002_20200923192800.ts
File '/srv/media10/media10-barley/22002_20200923192800.ts': container: MPEG
transport stream
Track ID 0: video (MPEG-1/2)
Track ID 1: audio (AC-3)

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
>
Done. myth says "video decode error". Should myth 30 understand the
format?

vlc can open it, and even shows the correct recording length.
But there is neither sound nor video when it plays. I verified that I can
view non-mangled, non-nuv
recordings in vlc.

Should I rebuild the seek table for the recording before trying in myth?

Ross

P.S. The message that the recording was 7 hours long based on the bitrate
suggests the audio
bitrate was originally much higher, and has been erroneously labelled with
the wrong bitrate.
So if played at "normal" speed to the low bitrate, that will be like
playing the original really slowly.
Which is what I heard, apart from the static.
Re: Recovering from transcode/bad seektable [ In reply to ]
On Sat, 26 Sep 2020 14:04:22 -0700, you wrote:

>Thanks for your very concrete suggestions. Unfortunately, I still can't
>view the video.
>Some details below, and a question: should I regenerate the seek table in
>myth?

If your root partition has been out of space for a while, the
recordedseek table has probably been corrupt for a while too. Without
enough space the daily or weekly optimize_mythdb will not have fixed
the recordedseek table, and any recordings that were made after it
became corrupt probably have either no or invalid entries in
recordedseek. So you should do mythcommflag --rebuild on all the
recordings since the recordedseek table became corrupt. If you are
lucky you will have complaints from mythbackend about the bad
recordedseek table in the mythbackend.log files to tell you when it
first happened. But if it was too long ago your older logs will have
already been deleted. If you also do commercial flagging, then after
you do mythcommflag --rebuild for a recording, you will also need to
rerun the commercial flagging. You will need to work out what
settings you use for commercial flagging to put on the command line.

I have a small systemd job that checks for sufficient free space for a
second copy of my recordedseek table when it is being checked and
repaired and tells me if my root partition is too low on space, to
avoid getting this problem. It emails me when there is a problem, and
checks every hour:

root@mypvr:/etc/systemd/system# sc cat check-free-space.service
# /etc/systemd/system/check-free-space.service
[Unit]
Description=Check free space on /
After=time-sync.target
OnFailure=notify-failure@%n.service

[Service]
ExecStart=/bin/bash -c "/usr/local/bin/check-free-space.sh"

[Install]
WantedBy=multi-user.target

root@mypvr:/etc/systemd/system# sc cat check-free-space.timer
# /etc/systemd/system/check-free-space.timer
[Unit]
Description=Hourly root free space check.

[Timer]
OnCalendar=hourly
Persistent=true

[Install]
WantedBy=timers.target

root@mypvr:/etc/systemd/system# cat /usr/local/bin/check-free-space.sh
#!/bin/bash

DEFAULT_MIN=16106127360

if [ -z "$1" ]; then
min_required=$DEFAULT_MIN
else
REGEX="^[[:digit:]]*$"
if ! [[ $1 =~ $REGEX ]] ; then
min_required=$DEFAULT_MIN
elif [[ $1 -eq 0 ]]; then
min_required=$DEFAULT_MIN
else
min_required=$1
fi
fi

root_free_space=$(($(stat -f --format="%a*%S" /)))
echo "Free space on root is $root_free_space"

if [ $root_free_space -lt $min_required ]; then
# Free space too low for /etc/cron.daily/optimize_db to run safely
on
# mythconverg.recordedseek table.
echo "Free space too low (< $min_required)"
exit 1
fi

# Free space is sufficient.
echo "Free space is sufficient (>= $min_required)"
exit 0

root@mypvr:/etc/systemd/system# cat notify-failure@.service
#notify-failure@.service:

[Unit]
Description=OnFailure for %i

[Service]
Type=oneshot
ExecStart=/usr/local/bin/onfailure.sh %i

root@mypvr:/etc/systemd/system# cat /usr/local/bin/onfailure.sh
#!/bin/bash

#
# Author: Kyle Manna <kyle@kylemanna.com>
#
# Simple systemd script used to be called via something like:
#
# Example Unit section of a service file:
#
# [Unit]
# ...
# Onfailure=failure-email@%i.service
#
#
# failure-email@.service:
#
# [Unit]
# Description=OnFailure for %i
#
# [Service]
# Type=oneshot
# ExecStart=/path/to/onfailure.sh %i
#

svc=${1-unknown}
email="root xxxxxx@xxxxxxxxx xxxx@xxxxx"

cat <<EOF | sendmail -i "$email"
Subject: [$HOSTNAME] OnFailure Email for $svc
# Status
$(systemctl status -l -n 1000 "$svc")
EOF
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recovering from transcode/bad seektable [ In reply to ]
On 26/09/2020 20:33, 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?

Your other replies may not have allowed for this file being in nuv/mp3
format. It's many years since I saw a file like that and I don't know
the state of MythTV's support for it now. Maybe vlc could play it.

And IIRC playback isn't usually dependent on the seektable - it's mainly
used to help seeking.
>

> /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
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recovering from transcode/bad seektable [ In reply to ]
On Sun, Sep 27, 2020 at 3:35 AM John Pilkington <johnpilk222@gmail.com>
wrote:

>
> Your other replies may not have allowed for this file being in nuv/mp3
> format. It's many years since I saw a file like that and I don't know
> the state of MythTV's support for it now. Maybe vlc could play it.
>
> And IIRC playback isn't usually dependent on the seektable - it's mainly
> used to help seeking.
>

The nuv format file was produced by the default behavior of myth's
transcode.
Why do you say you are unsure of myth's support for it?

Some of the jumping around behavior I saw when trying to watch without a
seek table suggested it was important for basic viewing, but it may have
been other things that caused the trouble. Certainly regenerating the seek
table (in the double sense of repairing recordedseek at the database level
and regenerating the entries for this particular recording) has not cured
all my problems.

@Steven
As far as I can tell from the mythbackend logs, the first database level
error with the seek table arose a day after the transcoding. This may have
been triggered by my attempt to run an optimize job. I shut mythbackend
down shortly after that until it was repaired. I've only noticed problems
with the one recording.

Thanks for the script.

Ross
Re: Recovering from transcode/bad seektable [ In reply to ]
On 27/09/2020 21:46, Ross Boylan wrote:
> On Sun, Sep 27, 2020 at 3:35 AM John Pilkington <johnpilk222@gmail.com
> <mailto:johnpilk222@gmail.com>> wrote:
>
>
> Your other replies may not have allowed for this file being in nuv/mp3
> format.  It's many years since I saw a file like that and I don't know
> the state of MythTV's support for it now.  Maybe vlc could play it.
>
> And IIRC playback isn't usually dependent on the seektable - it's
> mainly
> used to help seeking.
>
>
> The nuv format file was produced by the default behavior of myth's
> transcode.
> Why do you say you are unsure of myth's support for it?

Let's just say that its maintenance is not a high priority. Get the
flavour here:

https://lists.archive.carbon60.com/mythtv/dev/627879#627879

>
> Some of the jumping around behavior I saw when trying to watch without a
> seek table suggested it was important for basic viewing, but it may have
> been other things that caused the trouble.  Certainly regenerating the
> seek table (in the double sense of repairing recordedseek at the
> database level and regenerating the entries for this particular
> recording) has not cured all my problems.
>
> @Steven
> As far as I can tell from the mythbackend logs, the first database level
> error with the seek table arose a day after the transcoding.  This may
> have been triggered by my attempt to run an optimize job.  I shut
> mythbackend down shortly after that until it was repaired.  I've only
> noticed problems with the one recording.
>
> Thanks for the script.
>
> Ross
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recovering from transcode/bad seektable [ In reply to ]
On 27/09/2020 22:54, John Pilkington wrote:
> On 27/09/2020 21:46, Ross Boylan wrote:
>> On Sun, Sep 27, 2020 at 3:35 AM John Pilkington <johnpilk222@gmail.com
>> <mailto:johnpilk222@gmail.com>> wrote:
>>
>>
>>     Your other replies may not have allowed for this file being in
>> nuv/mp3
>>     format.  It's many years since I saw a file like that and I don't
>> know
>>     the state of MythTV's support for it now.  Maybe vlc could play it.
>>
>>     And IIRC playback isn't usually dependent on the seektable - it's
>>     mainly
>>     used to help seeking.
>>
>>
>> The nuv format file was produced by the default behavior of myth's
>> transcode.
>> Why do you say you are unsure of myth's support for it?
>
> Let's just say that its maintenance is not a high priority.  Get the
> flavour here:
>
> https://lists.archive.carbon60.com/mythtv/dev/627879#627879

It sounds as if you don't normally use mythtranscode, so I suppose it
may still have its default settings; IIRC they would rename the input
file from xxx.ts to xxx.ts.old, and not delete it. You have probably
looked for that, but...
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org