Some compile errors are worse than others. If you get an error that doesn't abort the compilation, and says something like:
cc1plus: warning: changing search order for system directory
"/usr/local/include"
cc1plus: warning: as it has already been specified as a non-system
directory
If you get an error like /usr/bin/ld: cannot find -lXext, the
compiler is telling you that you don't have XFree86-devel installed, or that
your distribution hasn't set it up correctly. This needs to be fixed before
MythTV will compile.
This error happens when there's a missing link in the
/usr/lib/qt3/mkspecs directory. There are two ways to fix this
error:
1. Create the link manually:
$ su
# cd /usr/lib/qt3/mkspecs
# ln -sf linux-g++ default
or
2. Run qmake mythtv.pro in the mythtv directory. Rerunning qmake will create a new Makefile for you, however this still doesn't fix the root cause of the issue, which is that your distribution didn't create the symlink for you when the qt3 package was installed. The first choice is the better solution.
You didn't set your QTDIR. Re-read the section on
Setting up paths.
This is most likely to be caused by an overheating processor rather than an actual programming fault within gcc.
Without details, the developers will not be able to determine if you have discovered a genuine code-bug, or if the problem is with your system. In order to determine what's going on, you must recompile MythTV with debugging support and run MythTV within gdb, the GNU debugger. Note that, on OS X, some data is provided without going through these steps. See /Library/Logs/CrashReporter/MythFrontend.crash.log
Re-run the configure script and add --compile-type=debug
to any previous configuration options you may have used. Check the
config.log file if you have forgotten.
Now, you need to clear out the old versions of the software to ensure that you're running with the debugging code, then compile and install.
$ make distclean
$ ./configure --compile-type=debug
$ make
$ su
# make install
# exit
At this point, you now have debug-enabled software ready. To make sure that
you don't forget to type a command required for debugging, it's best to
setup a gdbcommands file. This will be read by gdb when it's
started.
Put the following into gdbcommands in your home directory:
handle SIGPIPE nostop noprint
handle SIG33 nostop noprint
set logging on
set pagination off
set args -l myth.log -v record,channel,siparser
run
thread apply all bt full
set logging off
Let's assume that the problem you're having is in mythbackend.
$ gdb mythbackend -x gdbcommands
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux".Using host libthread_db library "/lib/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
gdb will automatically read the commands that you've placed in the
gdbcommands file and begin running the program you specified on the
command line.
If the program appears to be locked up, press CTRL-C to create the backtrace file.
All of the output from gdb.txt should be posted to the mythtv-dev
mailing list, along with the steps you followed to get the program to crash.
NOTE: If you're trimming the gdb.txt file to remove
extraneous information from the beginning of the file, make sure you include
at least 10 lines prior to the point where the backtrace actually
begins. This ensures that there is some context to the backtrace, and so
that it's possible to see what exactly caused the segfault.
gdb has a number of options, read the man page for more
information.
Using the gdbcommands file in conjunction with a while loop
will ensure that gdb creates a trace file and then restarts:
$ while true; do date >> gdb.txt; gdb mythbackend -x gdbcommands; done;
NOTE: To exit this loop you will need to kill the while loop.
If you're trying to troubleshoot and you can't get back to the gdb window for some reason, it may be easier to use two systems or to start mythfrontend from the text console.
If you're going to troubleshoot from a remote system, connect to the machine
that you're going to test using ssh or telnet. Next, type
$ export DISPLAY=localhost:0.0. This will allow the graphics to be
displayed on the X console (usually ALT-F6 or ALT-F7) and still give you
output and control of mythfrontend, either from the ssh
session, or by switching back to the text console by pressing CTRL-ALT-F1.
You can now continue troubleshooting using gdb as detailed in the
instructions.
When run as a non-privileged user, MythTV can not crash your system. If your system is crashing when you run MythTV, then you have some issue with the drivers for your capture card or other hardware, or the CPU fan has fallen off/broken and your system is overheating when asked to perform a CPU intensive task like encoding video.
If you are running as root, which is strongly discouraged, it is possible that your system may crash due to the real-time thread using all available CPU. You will not be able to interrupt the process, so for all intents and purposes your computer will have crashed.
You didn't add /usr/local/lib to /etc/ld.so.conf. See the
section on modifying
/etc/ld.so.conf.
This situation occurs most often with a system that acts as a frontend
and a slave backend. MythTV supports system-global and user-specific
configuration files, with user-configuration files taking precedence. 99%
of the configuration for MythTV is in the MySQL database, but MythTV still
needs to know where the MySQL server is running. This information is in the
mysql.txt file. By default, it will be installed to
/usr/local/share/mythtv, but a copy placed into ~/.mythtv
will over-ride the global configuration.
You must ensure that there aren't multiple, conflicting versions of this file on your system!
$ locate mysql.txt
/usr/local/share/mythtv/mysql.txt
/home/mythtv/.mythtv/mysql.txt
$
As you can see, in this example there are two mysql.txt files. If
they are not identical, then there may be unintended consequences.
You may also see this error if you completely fill the /var
partition. The most likely mythtv-related reason for this is an
overly large mythbackend or mythfrontend log file in /var/log. If
you have logging enabled for the backend, and myth runs for weeks at a time,
this may creep up and surprise you. Note that many system processes also
write to /var and the system may not boot if it is unable to write
to /var due to a full partition.
Your MySQL installation may have networking turned off.
Check that /etc/mysql/my.cnf does not contain
skip-networking. If it does, remove it. Also verify that
bind-address is set to your IP address instead of
127.0.0.1. If you change either of these items, restart
MySQL.
If you have reason to believe that your MySQL database is corrupt, execute the following commands to attempt to repair it.
NOTE: Ensure that there are no programs accessing the database while you attempt to repair it. Make sure that all backend and frontend programs have exited.
mysqlcheck -r -umythtv -p<password> mythconverg
This is a different problem than the one discussed in the previous section. Currently, the ivtv driver or firmware appear to have some issues if the vertical capture resolution is not the full screen height. If you are having a jitter problem then ensure that you are capturing either 480 lines (for NTSC) or 576 lines (for PAL). The default capture profiles may need to be edited for your setup. Go to Settings->TV Settings->Recording Profiles and adjust the Default and Live TV options to 480 or 576 from their defaults.
This is due to DPMS, the Display Power Management System, which is used to save power by turning off your monitor when the system decides that it's not being used or due to a screensaver that has defaulted to a blank screen. MythTV now has DPMS support built-in, and should intelligently handle the screen. Continue reading if you wish to override DPMS and force it off.
Since it's likely that watching TV will not generate keyboard or mouse events for a time, you need to turn off DPMS and the screensaver. There are a few ways to do this. You may also need to check your BIOS for power saving modes and disable screen blanking there as well.
Edit your /etc/X11/XF86Config-4 or /etc/X11/xorg.conf
file, and look for:
Section "ServerFlags"
#DontZap # disable <Ctrl><Alt><BS> (server abort)
#DontZoom # disable <Ctrl><Alt><KP_+>/<KP_-> (resolution switching)
AllowMouseOpenFail # allows the server to start up even if the mouse doesn't work
Option "blank time" "0"
Option "standby time" "0"
Option "suspend time" "0"
Option "off time" "0"
Option "NoPM" "1"
EndSection
Also, look for:
Section "Device"
Identifier "device1"
VendorName "nVidia Corporation"
BoardName "NVIDIA GeForce 256 (generic)"
Driver "nv"
Option "DPMS"
EndSection
In this case, you would need to either delete the Option "DPMS"
line, or change it to # Option "DPMS" to comment it out. The next
time you start XFree this change will take effect.
Finally, check:
Section "Monitor"
Identifier "monitor1"
VendorName "Plug'n Play"
HorizSync 30-85
VertRefresh 50-160
# Sony Vaio C1(X,XS,VE,VN)?
# 1024x480 @ 85.6 Hz, 48 kHz hsync
ModeLine "1024x480" 65.00 1024 1032 1176 1344 480 488 494 563 -hsync -vsync
# TV fullscreen mode or DVD fullscreen output.
# 768x576 @ 79 Hz, 50 kHz hsync
ModeLine "768x576" 50.00 768 832 846 1000 576 590 595 630
# 768x576 @ 100 Hz, 61.6 kHz hsync
ModeLine "768x576" 63.07 768 800 960 1024 576 578 590 616
EndSection
Ensure that there isn't an Option "DPMS" in the Monitor
configuration.
You can also turn off DPMS from the Command Line, but this will not survive a reboot.
$ xset -dpms
Using xset +dpms will turn it back on.
Another technique to try, which will turn off the screensaver:
$ xset s off
$ xset -dpms s off
Finally, depending on your distribution, you may be able to turn it off from within the control panel.
If mythfilldatabase suddenly appears to be failing, there are at least two things to check.
First, if you are in North America, ensure that your DataDirect subscription is still valid, otherwise, check to see what version of XMLTV you're running and that it's the latest version.
First, you should check that your kernel has been enabled for DMA:
[mythtv@pvr mythtv]$ dmesg |grep DMA
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio
hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=9729/255/63, UDMA(33)
hdb: 80043264 sectors (40982 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(33)
From the listing above, you can see that hda, hdb and hdc are set for DMA, and hdd is set for pio. If your kernel is not reporting DMA being enabled, you may need to recompile your kernel. Check your motherboard's chipset (look in the "ATA/IDE/MFM/RLL support" section in "make menuconfig") for more information.
Next, check that the hard drive has DMA enabled. Use the hdparm program to check and enable DMA.
# hdparm -d /dev/hd?
-d1 parameter, it will turn DMA on.
You may also setup your PC to do this at boot time, either by adding the
command to your /etc/rc.local file, or by adding files to
/etc/sysconfig.
On Mandriva and other distributions, if you install hdparm from an RPM you
will most likely get a /etc/sysconfig/harddisks file installed.
This file will be parsed by the /etc/rc.sysinit script. If you use
the default harddisks file, your changes will affect all IDE devices
(including CD ROMs). If you wish to use different parameters for various
devices, rename and/or copy the file to harddiskhda,
harddiskhdb, etc. Edit the file to your liking and on the next
reboot your setting will be preserved.
This may occur when MythTV doesn't have an accurate seek table. Run mythcommflag --rebuild
/dev/dsp.
Audio appears to be one of the bigger issues that users run into on the mailing list. If the audio isn't configured correctly, then MythTV will often appear to hang, when in fact it is trying to manipulate the audio subsystem and failing. You may or may not receive error messages indicating that the source of the error is the audio subsystem.
You can not use xawtv to determine if your audio is working correctly, since xawtv is simply using the analog sound patched through line-in to line-out. It doesn't need to digitize the sound unless you are using the recording function.
A better test to verify that sound will work for MythTV (and recording with
xawtv for that matter) is to startup xawtv, mute the
line-in then run aplay /dev/dsp. You should hear the recorded audio
slightly delayed behind the real-time video. You should see messages about
"underrun". These can be ignored but they do confirm that the driver is
loaded and there is an active device. Once this test succeeds, MythTV
should work correctly because it writes to and read from /dev/dsp in
the same way that aplay does.
To record audio along with video the audio signal must be digitized by a DSP so that the audio data can be stored in a file. On playback, the audio data is written to /dev/dsp and converted back to an analog signal. This analog signal should then be sent to your speakers. Here is what is needed in alsamixer. If you are using an ALSA version after 1.0.6, use alsamixer -V all:
CAPTUR source - the analog source to be sent to the DSP. This should be set to the input source from the tuner card to the sound card. In most cases this is Line but this could also be Aux, CD, Mic, etc., depending on how you connect the input cable. This source should be muted to prevent patching through the analog sound. The volume of this source will not affect the record level.
Capture mixer - this sets the level for the analog to digital recording. While a volume of 100% is recommended for testing, distortion may occur. Lowering this level to 75% to 85% may result in better audio quality. "Capture" should be marked as the CAPTUR destination.
PCM mixer - this sets the level for the digital to analog playback. While a volume of 100% is recommended for testing, distortion may occur. Lowering this level to 75% to 85% may result in better audio quality.
Master mixer - sets the level for the analog signal sent to line-out or the speakers.
You may also want to ensure that /dev/dsp , or whatever device file
is being used, hasn't already been grabbed by another process, like
esd or artsd. If the device file isn't available, then
MythTV won't work. You may wish to run configure and enable
support for these.
If you wish to see what application is grabbing a resource, you can use the
fuser command:
# fuser -v /dev/dsp
To disable aRts in KDE, go to KDE->Control Center->Sound->Sound System and
uncheck the "Start aRts soundserver on KDE startup" box. Run # killall
artsd from the command line to stop the artsd program.
If you're using multiple sound cards and multiple tuners, use alsamixer
-c 1 to work with the second sound card. The first card is #0, the
second card is #1, etc.
mythbackend does a check to see if your sound device is capable of full duplex operation. If it's not, it's most likely that you're going to run into issues when you try to record and play sound at the same time. If your backend is a separate machine than your frontend, then there's no problem, since you're only going to be doing one thing at a time with the card. Likewise, if you're running the frontend and backend on the same machine, but you're using btaudio or a hardware encoder card such as the Hauppauge PVR-250, DVB cards or HDTV capture cards as your recording source and you're only using the playback function of your sound card, then you also shouldn't have an issue, since the sound card isn't being asked to perform two functions at once.
If you can't get your sound card to go full-duplex and need it to, then check your distribution for updated sound drivers. If your sound card is not capable of full-duplex operation, either because the drivers don't support it, or it has been designed that way, then you're pretty much out of luck and will either need to purchase a new sound card, or will need to get btaudio operational.
This can be due to a number of factors. The simplest case is the "ghost" keypresses. For me, it was due to compact fluorescent lights in the same room as the IR receiver, which the receiver was picking up as keypresses. Once the lights were switched to incandescent bulbs, the ghost went away.
You may have an issue with lirc misinterpreting IR commands from a different remote. I also have an issue where the TiVo "Peanut" remote will eventually cause lircd to stop responding; even though lircd is configured for the Pinnacle Systems remote, the TiVo remote IR patterns are being seen by the IR receiver.
If your remote has been properly configured, and irw and irxevent are working correctly, then it's highly likely that your window manager is not giving focus correctly to the various Myth programs as they run. The following window managers are known to work correctly:
NOTE: You do not need to use irxevent if you are using MythTV's native LIRC support, so the window manager focus issue does not apply in that case.
There is no such thing as "Canada Cable"; Canada uses the same
frequencies as the United States. "Canada Cable" was a hack that some
people used when they would discover that their channels were off-by-one,
i.e. when tuning to channel 42, they might get channel 41 or 43. This is
actually due to the tuner on the video capture device being mis-detected.
You must manually specify the tuner type in your /etc/modules.conf.
See the video4linux mailing list (
https://listman.redhat.com/mailman/listinfo/video4linux-list) for
more information.
Find your php.ini file. Make sure you've got a line in it like this:
extension=mysql.so
Restart apache for it to take effect.
This is the intended behavior. The MythTV interface is meant for use with a remote control or a keyboard.
Nothing, really. It's just lame (the mp3 encoder) complaining for some obscure reason. This seems to be fixed in more recent versions of the libmp3lame library.
Something's wrong with your program database. Did mythfilldatabase run with no major errors? Or, MythTV may not have permissions to the appropriate video4linux devices. See the section titled Device Permissions for an example.
MythTV prints error and status messages to the shell that was used to start the application. If nothing seems to be happening when you try to view a program, try switching back to the shell and look for error messages there, or, if you're running from a startup script, check the log file.
XvMC is a NVidia driver feature which is supposed to help with decoding video. Users have reported that rather than speeding up their video it appears to be doing the opposite. You may want to check that your color depth is set for 24bpp.
You need to disable any sort of auto-running media player in your environment, otherwise MythDVD or MythMusic will not be able to work properly.
In KDE, you may want to perform the following:
$ rm ~/.kde/Autostart/Autorun.desktop