Support
Reporting Problems
In case of problems with ezstream, please make sure to re-read the
documentation first and double-check your configuration.
A lot of effort has been put into the ezstream(1) manual, and it
should -- at least in theory -- answer all questions.
Of course, ezstream isn't immune to bugs.
After
checking whether your bug is already known,
or a newer ezstream release fixes your problem, it is much appreciated that you
file your complete bug report
(see below) with the Xiph.org bug tracker.
If you encounter one of the following issues, you most definitely found a
genuine bug:
-
Ezstream crashes with a segmentation fault (SIGSEGV).
-
Ezstream aborts with an "Internal error".
-
A long-lived ezstream process keeps requiring more and more resources until
they run out.
-
A newer version of ezstream behaves surprisingly different, compared to an
earlier release, even though the configuration hasn't changed.
Such a behavioral change would have to be clearly intended and noted in the
NEWS file,
or it is considered a bug.
-
A part of the documentation is missing, unclear, or plain wrong.
Of course, sensible feature requests are also welcome.
Please select enhancement in the "Type:" drop-down menu for
those reports.
The Good Bug Report
Since it's hard to read someone else's mind, especially over the Internet,
a bug report needs to be "good".
A good bug report is never too short, and contains all the necessary
information to allow the developer to research, reproduce, understand and fix
the problem.
Unless you are able to provide a fix (unified diff with explanation) to your
problem, please follow this guide as closely as possible:
-
Be precise.
Vague phrases like "It doesn't work", "It crashes" or
"There is a strange problem" are not helpful without a verbose
explanation.
Do not be afraid of bug reports that seem too lengthy; it's a fact of life.
-
What are you using?
Include information about the ezstream version, your operating system name,
version and architecture.
-
What did you do?
Include the exact sequence of steps and events necessary to reproduce the
problem.
This includes, at the very least:
-
Any command line options passed to ezstream.
-
The ezstream configuration file, in full. (Please censor passwords and
host names, but keep it intact otherwise.)
-
What happened?
Describe the problem that you're having, including all error and log
messages that you might be seeing.
In case of a crash or an "Internal error", if you're up to it,
include a gdb backtrace:
-
Rebuild ezstream with debugging symbols.
This can be achieved by building with "
DEBUG=-g"
in the environment.
-
Reproduce the issue and get a fresh core dump.
On some systems, core dumps need to be enabled with
"
ulimit -c unlimited".
-
Run
gdb(1) with the core dump.
The name of the file containing the dump is either
ezstream.core or just core (adjust the following
command, if necessary):
"gdb ezstream ezstream.core"
-
Get the backtrace, by typing "
bt full" at the
(gdb) prompt.
-
Include the complete backtrace in your problem report.
Note that coredump files are only meaningful on the system where ezstream
crashed, and are useless elsewhere - do not include the core dump itself
in your report.
-
Do not diagnose the problem.
Or, well, do not do so without including the other information as well.
A diagnosis won't lead to a fix unless it can be verified by analyzing all
of the symptoms.
The only acceptable shortcut is a working patch in the report! :-)
Good problem reports help make ezstream better, and your efforts are very
much appreciated!
Contact
The current maintainer of ezstream is Moritz Grimm (mdgrimm at gmx dot net).
About |
Download |
More ... |
Release Notes |
Support
