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.
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.
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. 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. If you follow these guidelines you should be safe. 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.
Subscribe to the mplayer-users mailing list:
http://mplayerhq.hu/mailman/listinfo/mplayer-users
and send your bug report to:
mplayer-users@mplayerhq.hu
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.
uname -als -l /lib/libc[.-]*X -versiongcc -v
ld -vas --versioncat /proc/cpuinfolspci -vv output on Linux systems.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 [options] [filename] &> mplayer.log
If your problem is specific to one or more files, then please upload the offender(s) to:
ftp://mplayerhq.hu/MPlayer/incoming/
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.
If you have a core dump of the crash continue reading the next paragraph, otherwise skip it.
Please create the following command file:
disass $eip-32 $eip+32
printf "eax=%08lX\n",$eax
printf "ebx=%08lX\n",$ebx
printf "ecx=%08lX\n",$ecx
printf "edx=%08lX\n",$edx
printf "esp=%08lX\n",$esp
printf "ebp=%08lX\n",$ebp
printf "edi=%08lX\n",$edi
printf "esi=%08lX\n",$esi
Then simply execute the following on your command line:
gdb mplayer --core=core -batch --command=command_file > mplayer.bug
./configure --enable-debug=3
make
gdb ./mplayer
run -v [options-to-mplayer] filename
bt
disass $eip-32 $eip+32
If something is quite big (logs for instance) then it is better to upload it to the FTP server in a compressed format (gzip and bzip2 preferred) and include only the path and filename 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.
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...