<div dir="ltr"><div></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 27, 2020 at 3:35 AM John Pilkington <<a href="mailto:johnpilk222@gmail.com">johnpilk222@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Your other replies may not have allowed for this file being in nuv/mp3 <br>
format.  It's many years since I saw a file like that and I don't know <br>
the state of MythTV's support for it now.  Maybe vlc could play it.<br>
<br>
And IIRC playback isn't usually dependent on the seektable - it's mainly <br>
used to help seeking.<br></blockquote><div><br></div><div>The nuv format file was produced by the default behavior of myth's transcode. <br></div><div>Why do you say you are unsure of myth's support for it?</div><div><br></div><div>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.</div><div><br></div><div>@Steven<br></div><div>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.</div><div><br></div><div>Thanks for the script.</div><div><br></div><div>Ross<br></div></div></div></div>