How to report bugs
Good bug reports are a very valuable contribution to the development of any
software project. But just like writing good software, good problem reports
involve some work. Please realize that most developers are extremely busy and
receive obscene amounts of email. So while your feedback is crucial in improving
MPlayer and very much appreciated, please understand
that you have to provide all of the information
we request and follow the instructions in this document closely.
How to fix bugs
If you feel have the necessary skills you are invited to have a go at fixing the
bug yourself. Or maybe you already did that? Please read
this short document to find out how to
get your code included in MPlayer. The people on the
mplayer-dev-eng
mailing list will assist you if you have questions.
How to report bugs
First of all please try the latest CVS version of MPlayer
as your bug might already be fixed there. Development moves extremely fast,
most problems in official releases are reported within days or even hours, so
please use only CVS to report bugs. This
includes binary packages of MPlayer. CVS
instructions can be found at the bottom of
this page or in
the README. If this did not help please refer to the list of
known bugs and the rest of the documentation. If your
problem is not known or not solvable by our instructions, then please report the bug.
Please do not send bug reports privately to individual developers. This is
community work and thus there might be several people interested in it. Sometimes
other users already experienced your troubles and know how to circumvent a problem
even if it is a bug in MPlayer code.
Please describe your problem in as much detail as possible. Do a little detective
work to narrow down the circumstances under which the problem occurs. Does the bug
only show up in certain situations? Is it specific to certain files or file types?
Does it occur with only one codec or is it codec independent? Can you reproduce it
with all output drivers? The more information you provide the better are our
chances at fixing your problem. Please do not forget to also include the valuable
information requested below, we will be unable to properly diagnose your problem
otherwise.
An excellent and well written guide to asking questions in public forums is
How To Ask
Questions The Smart Way by Eric S. Raymond.
There is another called
How to Report
Bugs Effectively by Simon Tatham.
If you follow these guidelines you should be able to get help. But please
understand that we all follow the mailing lists voluntarily in our free time. We
are very busy and cannot guarantee that you will get a solution for your problem
or even an answer.
Where to report bugs
Subscribe to the mplayer-users mailing list:
and send your bug report to
where you can discuss it.
If you prefer, you can instead use our brand new BugZilla at
.
Developers are using the BugZilla.
The language of this list is English. Please follow the standard
Netiquette Guidelines and
do not send HTML mail to any of our mailing lists. You will only get ignored or
banned. If you do not know what HTML mail is or why it is evil, read this
fine document. It explains all
the details and has instructions for turning HTML off. Also note that we will not
individually CC (carbon-copy) people so it is a good idea to subscribe to actually
receive your answer.
What to report
You may need to include log, configuration or sample files in your bug report.
If some of them are quite big then it is better to upload them to our
FTP server in a
compressed format (gzip and bzip2 preferred) and include only the path and file
name in your bug report. Our mailing lists have a message size limit of 80k, if
you have something bigger you have to compress or upload it.
System Information
Your Linux distribution or operating system and version e.g.:
Red Hat 7.1Slackware 7.0 + devel packs from 7.1 ...
kernel version:
uname -a
libc version:
ls -l /lib/libc[.-]*
gcc and ld versions:
gcc -v
ld -v
binutils version:
as --version
If you have problems with fullscreen mode:
Window manager type and version
If you have problems with XVIDIX:
X colour depth:
xdpyinfo | grep "depth of root"
If only the GUI is buggy:
GTK versionGLIB versionlibpng versionGUI situation in which the bug occursHardware and drivers
CPU info (this works on Linux only):
cat /proc/cpuinfo
Video card manufacturer and model, e.g.:
ASUS V3800U chip: nVidia TNT2 Ultra pro 32MB SDRAMMatrox G400 DH 32MB SGRAM
Video driver type & version, e.g.:
X built-in drivernVidia 0.9.623Utah-GLX CVS 2001-02-17DRI from X 4.0.3
Sound card type & driver, e.g.:
Creative SBLive! Gold with OSS driver from oss.creative.comCreative SB16 with kernel OSS driversGUS PnP with ALSA OSS emulation
If in doubt include lspci -vv output on Linux systems.
Configure problems
If you get errors while running ./configure, or autodetection
of something fails, read configure.log. You may find the
answer there, for example multiple versions of the same library mixed on your
system, or you forgot to install the development package (those with the -dev
suffix). If you think there is a bug, include configure.log
in your bug report.
Compilation problems
Please include these files:
config.hconfig.mak
Only if compilation fails below one of these directories, include these files:
Gui/config.maklibvo/config.maklibao2/config.makPlayback problems
Please include the output of MPlayer at verbosity level
1, but remember to not truncate the output when
you paste it into your mail. The developers need all of the messages to properly
diagnose a problem. You can direct the output into a file like this:
mplayer -v optionsfilename > mplayer.log 2>&1
If your problem is specific to one or more files, then please upload the offender(s) to:
Also upload a small text file having the same base name as your file with a .txt
extension. Describe the problem you are having with the particular file there and
include your email address as well as the output of MPlayer
at verbosity level 1. Usually the first 1-5 MB of a file are enough to reproduce
the problem, but to be sure we ask you to:
dd if=yourfile of=smallfile bs=1024k count=5
It will take the first five megabytes of 'your-file'
and write it to 'small-file'. Then try again on
this small file and if the bug still shows up your sample is sufficient for us.
Please do not ever send such files via mail!
Upload it, and send only the path/filename of the file on the FTP-server. If the
file is accessible on the net, then sending the exact
URL is sufficient.
Crashes
You have to run MPlayer inside gdb
and send us the complete output or if you have a core dump of
the crash you can extract useful information from the Core file. Here's how:
How to conserve information about a reproducible crash
Recompile MPlayer with debugging code enabled:
./configure --enable-debug=3
make
and then run MPlayer within gdb using:
gdb ./mplayer
You are now within gdb. Type:
run -v options-to-mplayerfilename
and reproduce your crash. As soon as you did it, gdb will return you to the command
line prompt where you have to enter
bt
disass $pc-32 $pc+32
info all-registers
How to extract meaningful information from a core dump
Create the following command file:
bt
disass $pc-32 $pc+32
info all-registers
Then simply execute this command:
gdb mplayer --core=core -batch --command=command_file > mplayer.bugI know what I am doing...
If you created a proper bug report following the steps above and you are confident
it is a bug in MPlayer, not a compiler problem or broken
file, you have already read the documentation and you could not find a solution,
your sound drivers are OK, then you might want to subscribe to the mplayer-advusers
list and send your bug report there to get a better and faster answer.
Please be advised that if you post newbie questions or questions answered in the
manual there, you will be ignored or flamed instead of getting an appropriate answer.
So do not flame us and subscribe to -advusers only if you really know what you are
doing and feel like being an advanced MPlayer user or
developer. If you meet these criteria it should not be difficult to find out how to subscribe...