Difference between revisions of "User Manual:Diagnosing Problems"

From MythTV Official Wiki
Jump to: navigation, search
m
 
(37 intermediate revisions by 17 users not shown)
Line 1: Line 1:
{{Navigate|User Manual:Accessory Modules|User Manual:Index|User Manual:Regression Testing}}
+
{{User Manual TOC}}
  
It can be frustrating when things don't work.  Please remember two things about MythTV when you run into problems like this: 1) it's in early, early beta (0.15 is a *very* low version number -- on purpose) even if it's working ok for you, and 2) it was free.  :-)
+
This page is up-to-date to MythTV version 0.20, the current release is {{CurrentRelease}}
 +
 
 +
 
 +
It can be frustrating when things don't work.  Please remember two things about MythTV when you run into problems like this: 1) it's in early, early beta (0.20 is still a *very* low version number -- on purpose) even if it's working ok for you, and 2) it was free.  :-)
  
 
== Asking Good Questions ==
 
== Asking Good Questions ==
  
As with all open source projects, while you don't pay someone *cash* for the software, it's not entirely 'free', either. The investment you make, sometimes, is diagnosing problems (sometimes on your own, sometimes with the help of the mailing list), and *reporting them back to the list*.  This way, the solution (and if you do this, please try to put [solved] in the subject line so people will be able to spot the solution -- and we wouldn't object to you posting an question and answer here too. :-)
+
As with all open source projects, it's not entirely "free": sometimes you invest time in diagnosing problems (sometimes on your own, sometimes with the help of the mailing list), and ''reporting them back to the list''.  This way, the solution (and if you do this, please try to put [solved] in the subject line so people will be able to spot the solution -- and we wouldn't object to you posting a question and answer here, too.) is available to everyone.
  
And you're much more likely to get an answer if you've done some legwork on your own, first: an excellent reference for the sort of legwork you might want to *do* is Eric Raymond and Rick Moen's [http://www.catb.org/~esr/faqs/smart-questions.html "Asking Questions The Smart Way"].
+
You're more likely to get an answer if you've done some legwork on your own... first. An excellent reference for the sort of legwork you should attempt is Eric Raymond and Rick Moen's [http://www.catb.org/~esr/faqs/smart-questions.html "Asking Questions The Smart Way"].
  
In this section, my approach will be to put a whole bunch of questions and answers on each page, rather than one per page, because the latter approach always frustrates *me* when I'm trying to fix something.  I've found that seeing the other questions and answers as you go by can be useful as well.
+
In this section I'll put a bunch of questions and answers on each page, rather than one per page,--seeing other questions and answers as you go by can be useful as well.
  
 
== What They'll Need To Know ==
 
== What They'll Need To Know ==
Line 65: Line 68:
 
So, now that you know what to ask, and what information people will need to help you diagnose your problem, and you've done some of your own legwork to figure out the most likely causes, you need to know where to go to ask your question.
 
So, now that you know what to ask, and what information people will need to help you diagnose your problem, and you've done some of your own legwork to figure out the most likely causes, you need to know where to go to ask your question.
  
There are three places, in ascending order of immediacy, that you can go to ask questions.  Each has advantages and disadvantages, both for you and for other people.
+
There are several places where you can go to ask questions.  Each has advantages and disadvantages, both for you and for other people, you can learn about them at the [[Community | '''Community page.''']]
  
== IRC ==
 
  
If you have an IRC client program, and know how to use it (that's beyond the scope of this document [I've *always* wanted to say that :-)]), you can visit the MythTV users IRC channel
+
==Diagnosing==
  
irc://irc.freenode.net/#mythtv-users
+
===Tools===
 +
You may find it helpful to read the [[StatusMonitoringHowTo]]
  
(Note that there's another channel for developers, which has a name that does not end in -users; it's topic typically reminds you that it is not a user support venue.)
 
  
=== Advantages ===
+
Use top to see what is happening with your system
  
It's faster: if there's someone around who knows what is causing your problem, you might be able to get an answer instantly.
+
$top
  
=== Disadvantages ===
+
[[Image:top.png]]
  
There may *not* be someone around who knows were your problem is coming from.  If you *do* get an answer, there's no record of it -- as there would be if you'd asked on a mailing list -- so others can't benefit from it.
+
Press u followed by mythtv to show all mythtv user processes.
  
=== Best For ===
+
$lsof -p 6035
  
Lightweight questions, especially those about installation and compiling.
+
Using the process id from the top command above, this will list all the files open by mythfrontend
  
=== Not So Much ===
+
===Logfiles===
 +
One of the most useful places to look for information about problems is the log files of the various component programs. Which programs have logfiles and where they log to will depend on how you have installed mythtv (e.g. from scratch or using pre-built packages from a linux distribution). A good place to start on Linux systems is the /var/log/ directory.
  
Long involved questions that are dependent on your installation and it's parameters.
+
A useful trick to watch what is going on as you interact with mythtv is to use the 'tail' program to monitor the logfiles, e.g.
 +
<pre>
 +
% tail -f /var/log/mythtv/mythfrontend.log
 +
</pre>
  
==Diagnosing==
+
===Performance Issues===
you may find it helpful to read the [[StatusMonitoringHowTo]]
+
 
 +
You may find it helpful to read the section on [[Optimizing Performance]]
 +
 
 +
MythTV can make quite a demand on your system, especially with High Definition video. On the MythTV discussion forums there are many questions related to peformance issues that often have a simple fix. Performance issues often manifest themselves as video or audio stutter during live TV, or slow transcoding of recordings. Of course it might just be a a bug in the release of software that you are using.
 +
 
 +
What follows are some strategies and checks to try in isolating performance issues.
 +
 
 +
===Disk performance trouble shooting===
 +
A Modern Mythbox will either be using hard drives that make use of Utra ATA 100(renamed as Parallel ATA) or Serial ATA interfaces.
 +
 
 +
Many video stutter problems are a result of not setting up Linux/hardware hardrive parameters correctly. Ultra ATA drives can operate at 33/66/100 modes. Some checks to make:
 +
 
 +
1. Make sure that you have the correct cable to allow your drive to operate at its maximum speed. A faulty cable or the incorrect cable can cause the BIOS in your system to select the wrong speed.
 +
 
 +
 
 +
2. Check that your BIOS has set the hardrive to the right mode,"auto" may not detect the right speed.
 +
 
 +
 
 +
3. Check that your distro has detected the optimum capability of your drive. In SUSE you can check this using YaST
 +
 
 +
 
 +
4. Use the hdparm command to optimise the performance of your drive subsystem. There is a very good article Here http://www.linuxdevcenter.com/pub/a/linux/2000/06/29/hdparm.html
 +
 
 +
5. Use [[dmesg]] to check for filesystem errors which may indicate a hardware problem. If you see filesystem related errors us fsck to do hard drive check, of reiserfsck if you use the reiser files system (default for SUSE). You can use the appropriate option to fix any soft errors.
 +
 
 +
 
 +
MythTV should only be writing to your disk every 3 to 5 seconds.Your hard drive LED should blink accordingly. Of course it might not be MythTV that is causing the drive access, so you may need to isolate other processes may also be using the hardrive.
 +
 +
 
 +
'''What processess are likely to be writing to disk'''
 +
 
 +
 
 +
1. Mysql :Note that some distros have mysql logging turned on.If you want to turn off the mysql loging, comment out the line in /etc/mysql/my.cnf containing '/var/log/mysql/mysql.log'.
 +
 
 +
 
 +
2. Mythbackend logging. The log lives at /var/log/mythtv/mythbackend.log
 +
 
 +
 
 +
3. Mythfrontend logging. The log lives at /var/log/mythtv/mythfrontend.log 
 +
 
 +
 
 +
4. Mythbackend recording
 +
 
 +
 
 +
5. Linux Virtual Memory paging
 +
 
 +
 
 +
6. Linux buffer cache flush
 +
 
 +
 
 +
7. Commercial Flagging
 +
 
 +
 
 +
8. Transcoding
 +
 
 +
 
 +
If you experience a high amount of disk activity there are a few things you can check.
 +
 
 +
You can track which process is reading/writing the disk by doing as root:
 +
 
 +
#echo 1 > /proc/sys/vm/block_dump
 +
 
 +
Then use 'dmesg' to tell you which process is using the disk. Turn off
 +
tracking again with
 +
 
 +
#echo 0 > /proc/sys/vm/block_dump
 +
 
 +
===Processor performance trouble shooting===

Latest revision as of 01:22, 18 October 2010

This page is up-to-date to MythTV version 0.20, the current release is 0.27


It can be frustrating when things don't work. Please remember two things about MythTV when you run into problems like this: 1) it's in early, early beta (0.20 is still a *very* low version number -- on purpose) even if it's working ok for you, and 2) it was free.  :-)

Asking Good Questions

As with all open source projects, it's not entirely "free": sometimes you invest time in diagnosing problems (sometimes on your own, sometimes with the help of the mailing list), and reporting them back to the list. This way, the solution (and if you do this, please try to put [solved] in the subject line so people will be able to spot the solution -- and we wouldn't object to you posting a question and answer here, too.) is available to everyone.

You're more likely to get an answer if you've done some legwork on your own... first. An excellent reference for the sort of legwork you should attempt is Eric Raymond and Rick Moen's "Asking Questions The Smart Way".

In this section I'll put a bunch of questions and answers on each page, rather than one per page,--seeing other questions and answers as you go by can be useful as well.

What They'll Need To Know

The specific examples, at the moment, are those of my machine, and note that *all* characters are significant -- and that many of these things don't change frequently; creating a file with your setup in it for mailing list postings can be useful. I'm going to make this into a Wiki Template, so you can easily create a subpage here from your Home Page, for quick reference.

  • Hardware
    • Motherboard (MSI-6712)
      • Processor (AMD Athlon XP 2500+ 'Barton')
      • Chipset (VIA KT400A)
      • Number of PCI slots (6)
      • Amount and speed of RAM (512MB PC2700 Kingston)
    • Hard Disk
      • Interface (IDE-80)
      • Size (200GB)
      • Manufacturer (Seagate Barracuda)
      • Exact model # (ST3200822A)
    • Tuner Cards
      • Quantity (2)
        • Manufacturer (all Hauppauge)
        • Model (PVR-250)
        • Revision (48432/I110, 32032/B182)
        • Encoder/Decode Firmware (02040011,02020023)
  • Software
    • Operating System
      • Kernel version (Linux potato 2.6.5-7.104-default #1 Wed Jul 28 16:42:13 UTC 2004 i686 athlon i386 GNU/Linux)
        • Source-built/RPM? (RPM/YOU)
      • Distribution & version (SuSE 9.1 Pro)
        • Version numbers of strategic support packages
          • MySQL (mysql-4.0.18-32, qt3-mysql-3.3.1-32, php4-mysql-4.3.4-43.11)
          • KDE/Qt (qt3-3.3.1-36.16)
          • ...
    • Tuner Card driver
      • Complete version number (0.1.10pre2-ck100z)
      • Source (chriskennedy.kicks-ass.net)
      • Source-built/RPM? (tarball)
    • Applications
      • MythTV
        • Version number or CVS build date (20040528-1 CVS)
        • Installed options
      • Other capture apps
        • Version numbers
          • Do *they* work?

Once you have assembled all the necessary information, which may include the contents of several log files (the frontend, backend, and pertinent parts of the system logs), you need to know where to go to ask questions.

Before or After?

The important thing to know about a problem when you're trying to help someone fix it is: was the system (mostly) working and the problem is new, or have you not gotten the system working yet.

Where to Ask

So, now that you know what to ask, and what information people will need to help you diagnose your problem, and you've done some of your own legwork to figure out the most likely causes, you need to know where to go to ask your question.

There are several places where you can go to ask questions. Each has advantages and disadvantages, both for you and for other people, you can learn about them at the Community page.


Diagnosing

Tools

You may find it helpful to read the StatusMonitoringHowTo


Use top to see what is happening with your system

$top

Top.png

Press u followed by mythtv to show all mythtv user processes.

$lsof -p 6035 

Using the process id from the top command above, this will list all the files open by mythfrontend

Logfiles

One of the most useful places to look for information about problems is the log files of the various component programs. Which programs have logfiles and where they log to will depend on how you have installed mythtv (e.g. from scratch or using pre-built packages from a linux distribution). A good place to start on Linux systems is the /var/log/ directory.

A useful trick to watch what is going on as you interact with mythtv is to use the 'tail' program to monitor the logfiles, e.g.

% tail -f /var/log/mythtv/mythfrontend.log

Performance Issues

You may find it helpful to read the section on Optimizing Performance

MythTV can make quite a demand on your system, especially with High Definition video. On the MythTV discussion forums there are many questions related to peformance issues that often have a simple fix. Performance issues often manifest themselves as video or audio stutter during live TV, or slow transcoding of recordings. Of course it might just be a a bug in the release of software that you are using.

What follows are some strategies and checks to try in isolating performance issues.

Disk performance trouble shooting

A Modern Mythbox will either be using hard drives that make use of Utra ATA 100(renamed as Parallel ATA) or Serial ATA interfaces.

Many video stutter problems are a result of not setting up Linux/hardware hardrive parameters correctly. Ultra ATA drives can operate at 33/66/100 modes. Some checks to make:

1. Make sure that you have the correct cable to allow your drive to operate at its maximum speed. A faulty cable or the incorrect cable can cause the BIOS in your system to select the wrong speed.


2. Check that your BIOS has set the hardrive to the right mode,"auto" may not detect the right speed.


3. Check that your distro has detected the optimum capability of your drive. In SUSE you can check this using YaST


4. Use the hdparm command to optimise the performance of your drive subsystem. There is a very good article Here http://www.linuxdevcenter.com/pub/a/linux/2000/06/29/hdparm.html

5. Use dmesg to check for filesystem errors which may indicate a hardware problem. If you see filesystem related errors us fsck to do hard drive check, of reiserfsck if you use the reiser files system (default for SUSE). You can use the appropriate option to fix any soft errors.


MythTV should only be writing to your disk every 3 to 5 seconds.Your hard drive LED should blink accordingly. Of course it might not be MythTV that is causing the drive access, so you may need to isolate other processes may also be using the hardrive.


What processess are likely to be writing to disk


1. Mysql :Note that some distros have mysql logging turned on.If you want to turn off the mysql loging, comment out the line in /etc/mysql/my.cnf containing '/var/log/mysql/mysql.log'.


2. Mythbackend logging. The log lives at /var/log/mythtv/mythbackend.log


3. Mythfrontend logging. The log lives at /var/log/mythtv/mythfrontend.log


4. Mythbackend recording


5. Linux Virtual Memory paging


6. Linux buffer cache flush


7. Commercial Flagging


8. Transcoding


If you experience a high amount of disk activity there are a few things you can check.

You can track which process is reading/writing the disk by doing as root:

#echo 1 > /proc/sys/vm/block_dump

Then use 'dmesg' to tell you which process is using the disk. Turn off tracking again with

#echo 0 > /proc/sys/vm/block_dump

Processor performance trouble shooting