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
then it shouldn't be a problem.
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 is due to the broken Qt that is being distributed by Suse. To work
around this, edit libs/libavcodec/Makefile
and remove any
"-fPIC" you find there and then recompile.
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
and then restart the compile,
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.
Edit the settings.pro file. Make sure that the top of the file looks like this:
$ cat settings.pro
CONFIG += debug
#CONFIG += release
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 clean distclean
$ ./configure
$ make
$ su
# make install
# exit
At this point, you now have debug-enabled software ready. Let's assume that
the problem you're having is in the setup
program.
$ cd setup
$ gdb ./setup
GNU gdb 5.3-1mdk (Mandrake Linux)
Copyright 2002 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 "i586-mandrake-linux-gnu"...
(gdb) handle SIGPIPE nostop
Signal Stop Print Pass to program Description
SIGPIPE No Yes Yes Broken pipe
gdb has a number of options, read the man
page for more
information.
Once at the (gdb)
prompt, type run
to start program
execution. When the program segfaults or appears to lock-up (press CTRL-C),
type
(gdb) thread apply all bt full
All of the output from gdb should be posted to the mythtv-dev mailing list, along with the steps you followed to get the program to crash.
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.
This error can happen for the following reasons:
$ cat
/proc/cpuinfo
and looking for "sse" in the processor flags section.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.
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. 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
file, and look for:
Section "ServerFlags"
#DontZap # disable <Crtl><Alt><BS> (server abort)
#DontZoom # disable <Crtl><Alt><KP_+>/<KP_-> (resolution switching)
AllowMouseOpenFail # allows the server to start up even if the mouse doesn't work
EndSection
Add Option "NoPM" "true"
and Option "BlankTime" "0"
to the
ServerFlags section.
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
You may also combine the command to turn off DPMS and the screensaver:
$ 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?
will tell you the DMA status for your hard drives. If you run
hdparm with the -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 Mandrake 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 seektable. Run mythcommflag --rebuild
/dev/dsp
. See
this in the PVR-250
section for more information.
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. 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:
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
hasn't already been
grabbed by another process, like esd or artsd. If
/dev/dsp
isn't available, then MythTV won't work.
settings.pro
file in the mythtv directory then perform a make
distclean; make
, and re-run make install
as root to add this
support. Otherwise, check your window manager documentation for
instructions on disabling the sound manager.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 Hauppauge PVR-250 as your recording source, and 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.
See message http://www.mythtv.org/pipermail/mythtv-users/2003-April/002527.html
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,
ie, 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.
The most likely issue is that you have incompatible versions of the lirc_i2c and lirc_dev modules and the various lircd programs. See the section called Hauppauge PVR-250 remote and MythTV's native LIRC support. for examples on finding and removing old versions of lirc.
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