moonbase59 / ices0 Goto Github PK

View Code? Open in Web Editor NEW

24.0 7.0 9.0 540 KB

Enhanced source client for broadcasting to an Icecast/Shoutcast server in MP3 format.

License: GNU General Public License v2.0

Makefile 0.71% Shell 0.08% M4 6.75% C 92.45%

broadcasting ices icecast shoutcast mp3 flac ogg mp4 replaygain

ices0's Introduction

ices0

If you like what you got, please consider to . Thank you! ❤️

Ices0 is a source client for broadcasting in MP3 format to an Icecast/Shoutcast server.

This is a fork of the Icecast ices0 utility, and has been carefully enhanced to be compatible with CentovaCast, Airtime, AzuraCast, kPlaylist and others, as well as standalone.

New features (over v0.4)

This version 0.4.11 features the following enhancements:

Script module for easy shell scripting (i.e., for kPlaylist).
Support for MP3 Unicode id3v2 tags (aka the infamous "garbage in song titles" bug). MP3 stream metadata will always be UTF-8-encoded.
Note: Newer Icecast servers assume ISO-8859-1 for MP3 mounts, so you might need <charset>UTF8</charset> as a mount param in your icecast.xml file!
FLAC/OGG/MP4/MP3 transcoding support, including correct metadata from tags.
CrossMix option to crossmix tracks at 100% volume (instead of fading) by Daniel Pettersson and Rolf Johansson.
MinCrossfade setting to specify a minimum track length for which to enable the crossfader (for jingles etc.).
Works with new and old FLAC APIs (now works with libflac 1.3.2/1.3.0 instead of requiring the older 1.1.2 to compile).
Support for M3U/M3U8 playlist files (ignore lines starting with #).
Note: M3U/M3U8 files should be saved WITHOUT a BOM.
ReplayGain support throughout:
- MP3: reads RVA2 and TXXX:replaygain_track_gain frames, case-insensitive.
  Note: TXXX frames "win" over RVA2, this is intended.
- FLAC: reads REPLAYGAIN_TRACK_GAIN VorbisComment, case-insensitive.
- Ogg Vorbis: reads REPLAYGAIN_TRACK_GAIN VorbisComment, case-insensitive.
- MP4: reads ----:com.apple.iTunes;replaygain_track_gain, case-insensitive.
Fixed MP4/AAC support to work with libmp4v2.
Check for playing regular files (in case a device or directory was accidentally specified).
Cue file writing is disabled per default but can be enabled using -Q on the commandline or using <CueFile>1</CueFile> in ices.conf, Execution section. Note: This can wear out discs and especially SD cards real quick, use with care (or in a RAM disc).
Allow username different from "source" for stream connections: -U user on the commandline or <Username>user</Username> in ices.conf, Stream/Server section.
Can be installed using Homebrew, for instance on a MacOS X system.

What ices0 cannot do (and probably never will)

Accept anything other than MP3, Ogg Vorbis, FLAC and MP4/M4A AAC files for input.
Stream anything else than MP3 streams to a server. Ogg, FLAC and AAC are transcoded to MP3; this is why enabling Reencode is a good idea. Ices needs liblame for that.
Play broken MP3 files correctly (there are more than you would believe). You might try MP3 Diags to repair.
Apply ReplayGain if reencoding isn’t enabled. (Enabling reencoding is generally a good idea.)
Use https for streaming to an Icecast/Shoutcast server. Most stream providers don’t offer this anyway, and it doesn’t mean the server’s web pages can’t use https.

That said, ices0 is still a rock-solid tool and often used as an "Auto DJ", even in large systems like Airtime, CentovaCast, AzuraCast and many others. I have seen it running on servers over months without a single glitch.

Dependencies

libxml2
libogg
libvorbis
libshout
liblame
libflac
libfaad
libmp4v2

On Ubuntu 18.04/Linux Mint 19.1, these can usually be installed with:

sudo apt-get install libxml2-dev libogg-dev libvorbis-dev libshout3-dev
sudo apt-get install libmp3lame-dev libflac-dev
sudo apt-get install libfaad-dev libmp4v2-dev

For the Python and Perl scripting engines, additional libraries are needed:

sudo apt-get install libpython-dev libperl-dev

Building

Building with Homebrew (MacOS X)

Open a terminal and simply enter:

brew install Moonbase59/tap/ices0

If you don’t have current versions of Python2 and/or Perl on your system and wish to use ices0’s scripting features, you can pull the latest versions in using a command like:

brew install --with-python2 --with-perl Moonbase59/tap/ices0

Building manually

You need git and a working automake build environment.

git clone https://github.com/Moonbase59/ices0.git
cd ices0
aclocal
autoreconf -fi
automake --add-missing
./configure

Check configure's ouput. Ideally, it should end like this:

Features:
  XML     : yes
  Python  : yes
  Perl    : yes
  LAME    : yes
  Vorbis  : yes
  MP4     : yes
  FLAC    : yes

(This is a full build with all features.)

make
sudo make install

You can also create a distribution .tar.gz file:

make dist

Before making a pull request, please clean up using

make maintainer-clean

so you won't be pushing unneccessary temp files to GitHub.

ices0's People

Contributors

Stargazers

Watchers

Forkers

nightgryphon vassilisw sebalbert forkxx tb1402 joelliusczar essboyer daveamato fmfreak040

ices0's Issues

ices0 - Alsa

Hi, Its more of info request, does this client support ALSA input, i am unable to locate any guides on how to setup alsa input, documentation doesnt mention. i have tried different syntax adding in the config but doesnt work. any sample config on how to mention a device would be great
thanks

`libmp4v2-dev` no longer exists in Ubuntu / Mint

On Mint 20 (i.e. Ubuntu 20), seems that libmp4v2-dev is deprecated...

Please remove mp4v2, it's dead upstream and better alternatives
exist. The last remaining use case in the archive has been
fixed to no longer use it.

So, we have to download it separately from somewhere like here.

mp3 tags charset other than ISO-8859-1

I'd like to have an option to tell ices0 which charset to use when decoding tags. In my case I have files with tags id3v1 and id3v2 in cp1251 and id3v2_convert_iso8859_1 makes garbage on display.

How to set static metadata

Hi,
Is there a way to set metadata to a static string, (or even signalling to update like ices2), instead of showing the current song title?

I've noticed that you're wondering in your code notes:
usr1 signal is useful for debugging scripts, test our scripts behaviour when changing song or playlist ends, etc., So, yeah, keep it!

Ices0 crashes when specifying folders instead of files in playlists

First of all, thank you for having updated Ices0 with a ton of useful features.

I installed it on Arch ARM from the AUR: I modified the PKGBUILD to point the source to this repo and by changing its checksums.
On my small server I've got 5 streams of 320kbps mp3 (original bitrate of the files, no re-encoding when streaming) pointing to my icecast2 server. The CPU usage is almost non-existent, it doesn't even reach 4% with evertything running.
Unfortunately I see that periodically one or two of the streams crashes. Some survives indefinitely, the configuration files are almost the same, except for the playlist files, the mountpoints and the descriptions. I get notified by systemd with the following (the stream has been online for a few minutes in this case, but the last time I checked it went offline just 2 seconds after being launched):

Sep 11 20:59:34 Jack-P2 audit[26445]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 pid=26445 comm="ices0" exe="/usr/bin/ices0" sig=11 res=1
Sep 11 20:59:34 Jack-P2 kernel: audit: type=1701 audit(1568228374.855:429): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=26445 comm="ices0" exe="/usr/bin/ices0" sig=11 res=1
Sep 11 20:59:35 Jack-P2 systemd[1]: Started Process Core Dump (PID 29051/UID 0).
-- Subject: A start job for unit [email protected] has finished successfully
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- A start job for unit [email protected] has finished successfully.
-- 
-- The job identifier is 11833.
Sep 11 20:59:35 Jack-P2 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@5-29051-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 11 20:59:35 Jack-P2 kernel: audit: type=1130 audit(1568228375.215:430): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@5-29051-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 11 20:59:35 Jack-P2 systemd-coredump[29055]: Removed old coredump core.ices0.0.ed399ee4cf084132a928a4e059cd749f.258.1567975660000000.lz4.
Sep 11 20:59:35 Jack-P2 systemd-coredump[29055]: Removed old coredump core.ices0.0.ed399ee4cf084132a928a4e059cd749f.11924.1567992468000000.lz4.
Sep 11 20:59:35 Jack-P2 systemd-coredump[29055]: Removed old coredump core.systemd-journal.0.ed399ee4cf084132a928a4e059cd749f.162.1568013171000000000000.lz4.
Sep 11 20:59:36 Jack-P2 systemd-coredump[29055]: Removed old coredump core.ices0.0.ed399ee4cf084132a928a4e059cd749f.16297.1568017802000000000000.lz4.
Sep 11 20:59:36 Jack-P2 systemd-coredump[29055]: Removed old coredump core.ices0.0.6f1890eab56b4e32a0cfa31166b2b923.235.1568071953000000000000.lz4.
Sep 11 20:59:36 Jack-P2 systemd-coredump[29055]: Removed old coredump core.ices0.0.6f1890eab56b4e32a0cfa31166b2b923.14796.1568133915000000000000.lz4.
Sep 11 20:59:36 Jack-P2 systemd-coredump[29055]: Removed old coredump core.ices0.0.6f1890eab56b4e32a0cfa31166b2b923.17222.1568142003000000000000.lz4.
Sep 11 20:59:36 Jack-P2 systemd-coredump[29055]: Removed old coredump core.ices0.0.6f1890eab56b4e32a0cfa31166b2b923.17772.1568146503000000000000.lz4.
Sep 11 20:59:36 Jack-P2 systemd-coredump[29055]: Removed old coredump core.ices0.0.6f1890eab56b4e32a0cfa31166b2b923.19952.1568165405000000000000.lz4.
Sep 11 20:59:43 Jack-P2 systemd-coredump[29055]: Process 26445 (ices0) of user 0 dumped core.
                                                 
                                                 Stack trace of thread 26445:
                                                 #0  0x000000007688f938 memcpy (libc.so.6)
                                                 #1  0x0000000000475204 n/a (ices0)
-- Subject: Process 26445 (ices0) dumped core
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: man:core(5)
-- 
-- Process 26445 (ices0) crashed and dumped core.
-- 
-- This usually indicates a programming error in the crashing program and
-- should be reported to its vendor as a bug.
Sep 11 20:59:43 Jack-P2 systemd[1]: [email protected]: Succeeded.
-- Subject: Unit succeeded
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- The unit [email protected] has successfully entered the 'dead' state.
Sep 11 20:59:43 Jack-P2 kernel: audit: type=1131 audit(1568228383.745:431): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@5-29051-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 11 20:59:43 Jack-P2 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@5-29051-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

What other logs can I provide to find the culprit?

I've also noticed a few other bugs:

Ices0 sometimes plays songs slower than the normal playback speed. I solve this issue by refreshing the page or the stream from the listening client
Ices0 often skips to the next track before the song ends. I have checked the files and I can't understand why it doesn't play the whole song until the end

How to install on azuracast

How to install on azuracast????

ices 0.4.6 doesn't read FLAC tags when using FLAC API v8 or newer

When introducing the "universal" FLAC API handling, I introduced a small bug: When using the FLAC API v8 or newer, ices 0.4.6 would not read the Vorbis tags from FLAC files anymore (Artist, Title and replaygain_track_gain).

I accidentally tried to set a metadata callback after initializing the FLAC decoder. "Set" type operations must be done before init.

Fixing this in version 0.4.7.

Ices0 at some point starts using more and more RAM

I'm running on my Raspberry Pi 2 eight ices0 streams of 320kbps mp3 without reecoding the files on the fly (they have all been reencoded in this format . With this setup all the streams together use only 43MB of RAM and 2% of CPU.

As soon as I realized that the set of ices0 streams sometimes increases its RAM usage until the machine becomes unresponsive, I wrote a script that periodically checks how much memory it is using, and if it exceeds a threshold, it kills and restarts all the streams, which consume again 43MB together.

I obtain the value in MB from this command ps axo rss,comm | awk -v CONVFMT='%.0f' '/ices0/ {$1/=1024;sum+=$1} END {print sum""}'.
I've also tried to see what changes in memory usage when there is a normal and an excessive RAM usage by comparing the smaps, but they only differ in 4 lines for few kB. I read per-stream smaps with sudo cat /proc/$pid/smaps.

Do you know some other places where I can look the composition of the memory usage when it is excessive? Can this behaviour be a consequence of a memory leak? Why does it only start after some hour the stream have been restarted and not immediatly after?

Could you add a timestamp to each line of the ices0 log, both verbose and not?

EDIT
I was able to find out that only a stream is guily of today fail. It disappeared from the list of Icecast streams in status-json.xsl and its mountpoint returned 404, but according to the logs and the time it took, the stream waited for the song to finish before serving the following track.

Screenshot from htop:

With sudo pmap $pid I found a difference between the normal and the excessive usage at the beginning of the file:
normal

00429000     72K r-x-- ices0
0044a000      4K r---- ices0
0044b000      4K rw--- ices0
0044c000    728K rw---   [ anon ]
00f81000    132K rw---   [ anon ]
00fa2000    452K rw---   [ anon ]
74381000     36K r-x-- libnss_files-2.30.so
[...]

excessive

00429000     72K r-x-- ices0
0044a000      4K r---- ices0
0044b000      4K rw--- ices0
0044c000    728K rw---   [ anon ]
00f81000    132K rw---   [ anon ]
00fa2000 171432K rw---   [ anon ]
74381000     36K r-x-- libnss_files-2.30.so
[...]

This is the output of sudo cat /proc/$pid/maps:

00429000-0043b000 r-xp 00000000 b3:02 78340      /usr/bin/ices0
0044a000-0044b000 r--p 00011000 b3:02 78340      /usr/bin/ices0
0044b000-0044c000 rw-p 00012000 b3:02 78340      /usr/bin/ices0
0044c000-00502000 rw-p 00000000 00:00 0 
00f81000-00fa2000 rw-p 00000000 00:00 0          [heap]
00fa2000-084ee000 rw-p 00000000 00:00 0          [heap]
74381000-7438a000 r-xp 00000000 b3:02 29087      /usr/lib/libnss_files-2.30.so
[...]

Hexdumping the last line outputs hundreds of MB of junk.

The stream log file looks like this:

[...]

# Start of the strange behaviour
DEBUG: Builtin playlist handler serving: /path/to/Artist - Title.mp3
DEBUG: Filename cleaned up from [/path/to/Artist - Title.mp3] to [Artist - Title]
DEBUG: Trimmed short frame (301 bytes missing) at offset 109247768
DEBUG: MPEG-1 layer III, 320 kbps, 44100 Hz, j-stereo
DEBUG: Ext: 0	Mode_Ext: 0	Copyright: 0	Original: 1
DEBUG: Error Protection: 0	Emphasis: 0	Padding: 0
Playing /path/to/Artist - Title.mp3
Updating metadata on /mountpoint failed.
DEBUG: Done sending

# Other tracks show a log like this until the script kills the source
DEBUG: Builtin playlist handler serving: /path/to/Artist2 - Title2.mp3
DEBUG: Filename cleaned up from [/path/to/Artist2 - Title2.mp3] to [Artist2 - Title2]
DEBUG: ID3v2: version 4.0. Tag size is 332806 bytes.
DEBUG: ID3v2: Title found: Title2
DEBUG: ID3v2: Artist found: Artist2
DEBUG: MPEG-1 layer III, 320 kbps, 44100 Hz, j-stereo
DEBUG: Ext: 0	Mode_Ext: 2	Copyright: 0	Original: 1
DEBUG: Error Protection: 0	Emphasis: 0	Padding: 0
Playing /path/to/Artist2 - Title2.mp3
Updating metadata on /mountpoint failed.
DEBUG: Done sending

[...]

* Stream is automatically stopped and manually restared with a new playlists that begins with the new "faulty" track*

# Begin of streaming
DEBUG: Builtin playlist handler serving: /path/to/Artist - Title.mp3
DEBUG: Filename cleaned up from [/path/to/Artist - Title.mp3] to [Artist - Title]
DEBUG: Trimmed short frame (301 bytes missing) at offset 109247768
DEBUG: MPEG-1 layer III, 320 kbps, 44100 Hz, j-stereo
DEBUG: Ext: 0	Mode_Ext: 0	Copyright: 0	Original: 1
DEBUG: Error Protection: 0	Emphasis: 0	Padding: 0
Playing /path/to/Artist - Title.mp3
Mounted on http://127.0.0.1:4040/mountpoint
DEBUG: Delaying metadata update...
DEBUG: Updated metadata on /mountpoint to: Artist - Title
DEBUG: Updated metadata on /mountpoint to: Artist - Title

[...]

The .mp3 files are fine, I can't understand why it can now mount and update the metadata if it failed some minutes ago. The timestamps would confirm if this strange behaviour started with the "Artist - Title" track, or if it had already begun.