[mythtv-users] Commercial Skip - Video freezes & Audio Fast Forwards

Jake Anderson yahoo at vapourforge.com
Thu Dec 18 10:35:30 UTC 2008

Michael T. Dean wrote:
> On 12/17/2008 02:27 PM, Stackpole, Chris wrote:
>> From: Greg Hermsen
>>> I've had mixed results with commercial skip.  The promise is shows is big enough that I haven't given up on it yet. Commercial skipping will work well for a day or two, then at some point where MythTV should skip a commercial, the video freezes and the audio goes into a high-speed, 
>>> unintelligible mode.  I'm not able to stop it.  After anywhere from 10 - 20 minutes MythTV returns to the listing of recorded shows.  I assume that when the audio reaches the ended of the recorded program is when MythTV unfreezes from commerial skip
>>> Has anybody else seen this?  Is there something I can do to fix this?
>> I had this issue sometime ago with Myth .20 something and Knoppmyth. I
>> checked the log files and found an error (don't remember which one right
>> now)
> I'll fill in the blank for you:
> Error was: Driver error was [2/145]:
> QMYSQL3: Unable to execute query
> Database error was:
> Table './mythconverg/recordedseek' is marked as crashed and should be 
> repaired
>>  and after a google search I found a lot of people had that error
>> and that it had been fixed. I switched over to Mythbuntu and MythTV .21
>> the problem went away.
> Probably because MythBuntu packagers have set up MythBuntu systems to 
> automatically run optimize_mythdb.pl.
> So, OP, you should run optimize_mythdb.pl (while mythbackend is running) 
> to fix the crashed table (and, really, it doesn't hurt to run it in a 
> cron job at least once per month--though once per day works great at 
> fixing crashed tables before you notice them).  You can find 
> optimize_mythdb.pl in the contrib directory of the source distribution, 
> but most packagers include it in the install somewhere (use locate or 
> ask someone who's using your distro for more specific info).
> Once you repair the database with optimize_mythdb.pl, you may still see 
> some recordings with the same problem.  For them, you have 2 choices:  
> 1) delete the recording (and re-record it if desired) or 2) 
> http://www.mythtv.org/wiki/index.php/Repairing_the_Seektable .  
> Basically, the seektables of /any/ recordings you made while the table 
> was crashed will be corrupt/need repairing.  The seektables of /some/ 
> recordings that were made before the table crashed /could/ be 
> corrupt/need repairing.  You'll have to run mythtranscode --buildindex 
> (for MPEG-2 recordings) or mythcommflag --rebuild (for NUV recordings, 
> including software-encoded recordings from frame grabbers or 
> lossy-transcoded recordings) on each affected recording individually.
> Mike
heh, I just made another post on this very issue lol
If you don't want the problem again convert your myth setup to the 
innodb engine rather than myisam

"If your playing about with the database anyway, think about converting 
it to innodb rather than myisam.
I've had many issues with myth and myisam, If its recording or some such 
when there's a power failure it will often corrupt the recordedseek table.
innodb is ACID compliant and seems to tolerate that kind of abuse 
better. I have done this on all the systems I "look after" and haven't 
had a problem with it. (and no more recordedseek table crashes either.)"

I use this to do the conversion
> for t in $(mysql --batch --column-names=false -e "show tables" mythconverg);
> do
> mysql -e "alter table $t type=InnoDB" mythconverg;
> done

To fix it you repair the table then rebuild the seektable.
I used this
find /var/lib/ -iname "*.mpg" -mtime +50 -print0 | xargs -0 -n1 
mythtranscode --mpeg2 --buildindex --allkeys --showprogress --infiles -0 
-n1 mythtranscode --mpeg2 --buildindex --allkeys --showprogress --infile

to find all old shows then run mythtranscode over them, mythcommflag 
would say it ran but the problem persisted.
Theres probably no harm in running that command without the -mtime +50 
argument to just do all videos. I use that find command to cover all my 
storage groups.

Anybody have thoughts on making innodb the default? You can run mysql 
without it and save yourself 6mb of ram or so, but I'm not aware of any 
distro's running like this by default, so the impact of the change 
should really be minimal (other than reducing the incidence of problems ;->)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20081218/745e8339/attachment.htm 

More information about the mythtv-users mailing list