LinHES Forums
http://forums.linhes.org/

FF/RW Issues - Searching.....
http://forums.linhes.org/viewtopic.php?f=25&t=22088
Page 1 of 1

Author:  Martian [ Tue Apr 12, 2011 8:01 pm ]
Post subject:  FF/RW Issues - Searching.....

For about a week I've been having problems when I attempt to FF or RW on my combined Frontend/backend box. Often the box simply states "Searching....." when attempting to FF/RW.

The box is fully updated and running 6.04. Actually it appears to lag anytime you start, stop, pause, FF, RW a recording or live TV. In many cases the frontend appear to "lock-up" however I can SSH to the box and the frontend still appears to be running. "top" shows minimal (<10% typically) CPU usage and I don't think I've ever seen the Swap used (2 GB RAM). Nothing stands out as an issues in "top".

When I see the "Searching...." typically there appears to be heavy hard drive usage (in some cases the HDD light appears almost solid on). "hdparm" doesn't indicate any HDD issues. Speeds are where they should be for a SATA drive.

I'm thinking my problems may be database related but really don't know how to even begin looking into that.

WAF has taken a severe beating this week! I'm in need of the LinHES hivemind's help.

Thanks,

Martian

Author:  tjc [ Tue Apr 12, 2011 10:58 pm ]
Post subject: 

Most likely cause is loosing the seek table, which records the offsets to the keyframes, somehow. I just went through this with one of my machines, and ended up writing a little one-line bash script to loop through the problem recordings and rebuild it. One set of the problem recordings were from chanid 1861 from spring and summer last year. The following loop fixed them up in quick order.
Code:
for f in /myth/tv/1861_20100*.mpg ; do mythcommflag --hogcpu --rebuild -f "$f" ; done

You can use multiple patterns to generate the list that the for loop iterates over. For example we could add chanid 1501 from March of this year like this.
Code:
for f in /myth/tv/1861_20100*.mpg /myth/tv/1501_201103*.mpg ; do mythcommflag --hogcpu --rebuild -f "$f" ; done

Determining which recordings are problematic just requires a bit of SQL:
Code:
select * from recorded r where not exists (select * from recordedseek rs where r.chanid = rs.chanid and r.starttime = rs.starttime);

That looks for all recordings that don't have any entries in the seek table.

Author:  Martian [ Wed Apr 13, 2011 7:12 am ]
Post subject: 

I think we have a winner!

Running:
Code:
select * from recorded r where not exists (select * from recordedseek rs where r.chanid = rs.chanid and r.starttime = rs.starttime);


Resulted in:
Code:
ERROR 145 (HY000): Table './mythconverg/recordedseek' is marked as crashed and should be repaired


I'll search around for information on how to repair it but wouldn't turn down any suggestions.

Thanks so much for your help tjc!!!

Martian

EDIT:

I followed the instructions in this post for repairing the database:

http://mysettopbox.tv/phpBB2/viewtopic. ... sc&start=0

There were probably 20+ tables that were marked as corrupted but usable in addition to the "recordedseek" table which had crashed. It appears I have been able to repair all of the damaged tables but won't know for sure until I get some "testing" time. I also went ahead and did a "mythcommflag --rebuild --all" as I'm pretty sure it was needed.

Author:  christ [ Wed Apr 13, 2011 9:46 pm ]
Post subject: 

Martian wrote:
I followed the instructions in this post for repairing the database:

The following is more standard now and should work:
Code:
optimize_mythdb.py

Also LinHes runs a daily database optimize/repair using:
Code:
myth_mtc.py

which is invoked by cron.daily.

You may want to check that the above is running. Mine works fine.

Author:  Martian [ Wed Apr 13, 2011 10:47 pm ]
Post subject: 

Thanks for the reply christ!

I actually found the optimize_mythdb.py script after I finished doing everything manually. (my wife always says I like to do things the hard way!)

I ran optimize_mythdb.py and it seemed to complete with no issues (as one would expect after fixing everything manually).


Upon review of cron.daily I found a script titled " myth_mtc.sh" which calls "myth_mtc.py". A quick review of "myth_mtc.py" shows that it writes a log to "/var/log/mythtv/myth_mtc.log" which shows the following:
Code:
/usr/LH/bin/myth_mtc.py:4: DeprecationWarning: The popen2 module is deprecated.  Use the subprocess module.
  import sys,popen2
Traceback (most recent call last):
  File "/usr/LH/bin/myth_mtc.py", line 128, in <module>
    ctin=run_stuff()
  File "/usr/LH/bin/myth_mtc.py", line 110, in run_stuff
    if idle_check():
  File "/usr/LH/bin/myth_mtc.py", line 101, in idle_check
    if  (   upcoming_check() and schemalock_check() and job_check()  and in_use() and  mfd_check()  ):
  File "/usr/LH/bin/myth_mtc.py", line 35, in upcoming_check
    upcoming = mythtv.getUpcomingRecordings()
AttributeError: 'NoneType' object has no attribute 'getUpcomingRecordings'
Time Exceede 2011-04-14


I'm not a rocket scientist, but this doesn't look like the log file of a script that's running the way it should be. (Attempting to run myth_mtc.py at the command line yields the same output)

Martian

Author:  christ [ Mon Apr 18, 2011 7:35 pm ]
Post subject: 

Martian wrote:
I'm not a rocket scientist, but this doesn't look like the log file of a script that's running the way it should be.

It is not rocket science, it is merely brain surgery.

You are right that this does not look good. I suspect it is a side effect of 6.04. I'm running 6.03 without this issue.

You should open a bug in the bug tracker so it can be tracked. It may be relevant to 7.x as well.

Author:  opel70 [ Thu Dec 15, 2011 9:14 pm ]
Post subject: 

So, I just noticed that I am getting this same error with a clean LinHES 7.1 install. Is this something that other people have run into? Martain, did you ever get this fixed?

Author:  Martian [ Fri Dec 16, 2011 7:14 am ]
Post subject: 

I just went through a somewhat similar issue on 7.1 (Root partition filled up) and the scripts seemed to work for me (after making some room on the drive).

Martian

Author:  opel70 [ Fri Dec 16, 2011 7:30 am ]
Post subject: 

Thanks,

I took a look and still have several GB available on all drives. I looked at the myth_mtc.py and took out the secion that checked mythfilldatabase as that was the only section using the popen2 module. Doing that got rid of the:
Code:
/usr/LH/bin/myth_mtc.py:4: DeprecationWarning: The popen2 module is deprecated.  Use the subprocess module.
  import sys,popen2

but I am still getting the
Code:
Traceback (most recent call last):
  File "/usr/LH/bin/myth_mtc.py", line 128, in <module>
    ctin=run_stuff()
  File "/usr/LH/bin/myth_mtc.py", line 110, in run_stuff
    if idle_check():
  File "/usr/LH/bin/myth_mtc.py", line 101, in idle_check
    if  (   upcoming_check() and schemalock_check() and job_check()  and in_use() and  mfd_check()  ):
  File "/usr/LH/bin/myth_mtc.py", line 35, in upcoming_check
    upcoming = mythtv.getUpcomingRecordings()
AttributeError: 'NoneType' object has no attribute 'getUpcomingRecordings'

AttributeError message. Maybe I'll just change to scheduling a basic backup without all this checking.

Page 1 of 1 All times are UTC - 6 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/