* Move -m and -n command line options into the config file
* Restructure configuration file:
- Group into "server", "stream", "media", "metadata", "decoders", and
"encoders"
- Untangle decoder and encoder:
o Decoders match on file extensions and convert to a canonical "internal"
format
o Encoders create one of the supported stream formats, potentially using
different parameters (like bitrate)
- Consistently specify stream format
- Enable reencoding by selecting an encoder
* Architecturally separate configuration file storage from parsing
- Allows for different configuration back-ends in the future, like
YAML, SQL, REST API, ...
* Support roll-back in case of error on (re)load
* Anticipate HTTPS support
The libxalloc was reincarnated long ago in a separate utility library.
It did a good job help make ezstream have robust memory management years ago,
but now it's time to move on and get back to basics.
The replacement introduces reallocarray(), which is an overflow-checking
alternative to both malloc (NULL ptr) and realloc().
This makes ezstream log via syslog and stderr. The "real-time status
line" remains unaffected.
While here, make the output more concise and consistent.
This has been reported by Alexandre Rebert in February 2013(!).
The time to fix is terrible; luckily, the affected user base is likely to be
very small.
Add new <metadata_refreshinterval/> feature and configuration option. Based on
a patch by Matthew Adams (thanks!), with minor changes and documentation
additions by me.
(cherry picked from commit 4176545211)
file was to prevent a very verbose infinite loop (e.g. when accidentially
playing an outdated playlist.) Bring that back by aborting after 100 subsequent
errors.
git-svn-id: https://svn.xiph.org/trunk/ezstream@16527 0101bb08-14d6-0310-b084-bc0e0c8e3800
an empty line, and not receiving any output should not be a fatal error.
Consider the latter to be "end-of-playlist", too.
git-svn-id: https://svn.xiph.org/trunk/ezstream@16526 0101bb08-14d6-0310-b084-bc0e0c8e3800
code. Luckily, I had the proper copyright statement in there already, so moving
it fixes things.
git-svn-id: https://svn.xiph.org/trunk/ezstream@15781 0101bb08-14d6-0310-b084-bc0e0c8e3800
whenever possible, and otherwise uses a stripped down, single options only,
BSD getopt() (which is smaller and doesn't come with ifdef-stuff-in-features.h.)
git-svn-id: https://svn.xiph.org/trunk/ezstream@15779 0101bb08-14d6-0310-b084-bc0e0c8e3800
way to prevent NULL dereferences after the recent character conversion changes
in other parts of ezstream.
git-svn-id: https://svn.xiph.org/trunk/ezstream@15778 0101bb08-14d6-0310-b084-bc0e0c8e3800
There are a few benefits to this, but the main reason is consistency and me
completely understanding what's going on. Regressions are not expected, but
wouldn't surprise either ... this needs lots of testing.
git-svn-id: https://svn.xiph.org/trunk/ezstream@15776 0101bb08-14d6-0310-b084-bc0e0c8e3800
of files with non-ASCII filenames, as well as some more cases related to
metadata.
From Roman Donchenko <DXDragon at yandex dot ru>, with some minor fixes by
myself.
git-svn-id: https://svn.xiph.org/trunk/ezstream@15770 0101bb08-14d6-0310-b084-bc0e0c8e3800
crash when streaming standard input without also using a metadata program
(d'oh.)
git-svn-id: https://svn.xiph.org/trunk/ezstream@13996 0101bb08-14d6-0310-b084-bc0e0c8e3800
* Add 'charset=UTF-8' to the metadata update query arguments. The current
release of Icecast will ignore it, and the next one will know how to handle
it (karl@ is still working on it at this point, but previous diffs worked
as advertised.)
* If no metadata format string is available and we have both an artist and
a title, use the artist/title way of updating instead of the generic "song"
interface.
git-svn-id: https://svn.xiph.org/trunk/ezstream@13658 0101bb08-14d6-0310-b084-bc0e0c8e3800
disagree with the new ISO-8859-1 assumption for non-Ogg streams, because
(for example) with ID3 tags, a codeset is simply not part of the specification
and a better assumption would be that they are in the user's locale.
Therefore, it would make more sense, IMO, to clearly specify that ANY metadata
sent to Icecast should be UTF-8 and let the source client figure out the rest.
This would also answer the question what codeset an /admin user should use if
the content type of a mountpoint isn't known (although that can be figured out
with an unclean read of the mountpoint's stats beforehand.)
git-svn-id: https://svn.xiph.org/trunk/ezstream@13622 0101bb08-14d6-0310-b084-bc0e0c8e3800
No new code is actually used, yet, as there's still more work to be done.
This adds the whole iconv-related build stuff and moves most auto* files
into build-aux/.
git-svn-id: https://svn.xiph.org/trunk/ezstream@13607 0101bb08-14d6-0310-b084-bc0e0c8e3800
out that there is still a problem with MP3 streams that are being reencoded.
This allows me to try out more solutions.
git-svn-id: https://svn.xiph.org/trunk/ezstream@13592 0101bb08-14d6-0310-b084-bc0e0c8e3800
for normalizing metadata strings, which -- I assume -- is due to strange
(MP3) encoders that do weird things. Well, why not. It's not too intrusive,
and disabled by default. Enable string normalization with the new -n command
line parameter.
git-svn-id: https://svn.xiph.org/trunk/ezstream@13544 0101bb08-14d6-0310-b084-bc0e0c8e3800
for streaming MP3 files without reencoding, which was lost during the many
changes in 0.3.0 and subsequently forgotten. Sorry for the inconvenience,
and thanks for the report.
git-svn-id: https://svn.xiph.org/trunk/ezstream@13542 0101bb08-14d6-0310-b084-bc0e0c8e3800
pointers to NULL if we lateron expect them to be NULL (no longer rely on
xalloc to do this for us.)
git-svn-id: https://svn.xiph.org/trunk/ezstream@13436 0101bb08-14d6-0310-b084-bc0e0c8e3800
took care of it partially. Diagnosed with the help from someone, who wishes
to stay anonymous. Thanks!
git-svn-id: https://svn.xiph.org/trunk/ezstream@13296 0101bb08-14d6-0310-b084-bc0e0c8e3800
found in the Icecast mailing list archive, in a mail by Geoff Shang, via
Google. Let's hope that the bug tracker prevents this kind of bug hunting
in the future ...
git-svn-id: https://svn.xiph.org/trunk/ezstream@13272 0101bb08-14d6-0310-b084-bc0e0c8e3800
has not been checked for changes to previous behavior and isn't complete, yet.
More to come.
git-svn-id: https://svn.xiph.org/trunk/ezstream@12701 0101bb08-14d6-0310-b084-bc0e0c8e3800
program/script to get metadata from. Also include SIGUSR2 handling that triggers
metadata updates from the external program mid-stream.
git-svn-id: https://svn.xiph.org/trunk/ezstream@12693 0101bb08-14d6-0310-b084-bc0e0c8e3800
was to set ptr to NULL, but the function only set the copy of ptr to NULL.
Spotted by Karl Heyes, thanks a lot!
git-svn-id: https://svn.xiph.org/trunk/ezstream@12677 0101bb08-14d6-0310-b084-bc0e0c8e3800
ezstream.c. Use a basename() function for Windows that behaves identical to
a modern Unix' basename().
git-svn-id: https://svn.xiph.org/trunk/ezstream@12673 0101bb08-14d6-0310-b084-bc0e0c8e3800
is different. The shifting severely screwed up its randomness. Just leave it
away and systems that only have a bad version of rand() will have to just deal
with it.
git-svn-id: https://svn.xiph.org/trunk/ezstream@12629 0101bb08-14d6-0310-b084-bc0e0c8e3800
file parsing. Ezstream now prints each error it can find and then bails out,
instead of bailing out on the first error. Tweak URL parsing as well, and do
some cosmetic changes to the error messages.
git-svn-id: https://svn.xiph.org/trunk/ezstream@12603 0101bb08-14d6-0310-b084-bc0e0c8e3800
how reconnections are handled in general: A recovered connection always skips
to the next tune as well, as it seems that at least for Ogg Vorbis, libshout
wants to see an Ogg header after a shout_open(). The new code makes this
behavior consistent among all formats.
git-svn-id: https://svn.xiph.org/trunk/ezstream@12599 0101bb08-14d6-0310-b084-bc0e0c8e3800
file is group or world writeable. This is actually what the warning about root
was all about.
git-svn-id: https://svn.xiph.org/trunk/ezstream@12590 0101bb08-14d6-0310-b084-bc0e0c8e3800
a flurry of simultaneous SIGHUP and SIGUSR1 signals. From what I can tell,
signal handling is now quite solid now. Achieve this by moving most of
streamFile() into a new sendStream() function, which is called within a new
do-while loop inside streamFile(). There, proper behavior is ensured and
a race condition resolved in favor of SIGHUP.
git-svn-id: https://svn.xiph.org/trunk/ezstream@12564 0101bb08-14d6-0310-b084-bc0e0c8e3800
