[Icecast] Automatic Update of MP3 Files

[epicanis+icecast at dogphilosophy.net]

Okay, I'm pretty new to icecast myself, and have had to work my way through 
the same kind of confusion, so I think I know where you're coming from here.
Part of the problem is that what you're describing and asking for doesn't 
really make sense...except that I know I'd have been mis-describing my 
situation pretty much the same way not too long ago so I think I understand
what you mean (and I can make a couple of suggestions). 

I would suggest that icecast actually has nothing to do with your situation 
(read below) - you can therefore probably ignore all the stuff about init 
scripts[1] for icecast in the previous discussion if you want.

Read on for some possible solutions...

> >>>>>> On 09/26/2014 12:39 AM, Gene Steinberg wrote:
>So I have a new Icecast setup with two channels, each of which carries a link 
>to MP3 files.

So, you have an icecast server configured to handle two independent streams of
mp3 data, each of which is coming from a running copy of "icegenerator"?

Part of the confusion up to this point is that icecast doesn't read mp3 files, 
or m3u files, or anything else except its own configuration file, but I think 
Mr. Ruecker is assuming that since you are being told to restart icecast by 
hand anyway that there's something very odd in icecast's setup, and if he 
gives you a typical way of dealing with this situation it will at best just 
not work, and at worst break something. He's not being insulting - the 
description you've given is a bit confusing. I imagine it is worse for someone
whose first language may not be English.  (I also have to admit that what
you've described doesn't sound like the way most system administrators would
usually choose to install and configure things, suggesting that they're either 
relatively new to it, OR are dealing with some kind of unusual situation that
might make typical approaches to fixing things difficult or 
counterproductive.)

icecast is a much simpler, "dumber" program than it looked like to me when I 
first heard about it and started trying to use it. Icecast only takes a "live" 
stream of audio or video data and passes copies of that "live" stream to media 
players that have connected to it, and nothing more. It has no idea if the 
"live stream" is coming from an actual live recording, or one giant .mp3 file, 
or a series of .mp3 files listed in a .m3u file and streamed to it one after 
the other, or what. All of those details are handled by the "source client", 
which in your case is icegenerator.

>Whenever I update the .m3u file to reflect a changed link, I have to restart 
>Icecast and the Icegenerator to make it recognize the change.

I *suspect* that you actually *don't* have to restart icecast, and the person 
who told you that it was necessary is mistaken (again, not too long ago I'd 
have also assumed that icecast needed to be restarted, too, but now that 
I've had a little time to experiment that doesn't seem to be the case).
The only thing I can figure is you've been told to do that because the 
icegenerator processes will die when the icecast connection they're talking to 
goes down. ("killall icegenerator" seems like it'd be simpler, though).

On my own setup, when the "source client" ("oggfwd" sending a stream of .opus 
data in my case, but this doesn't really matter) disconnects, the "channel" on 
my icecast server disappears.  When it reconnects, the channel reappears and 
people can connect to it again. I find I don't need to restart icecast for 
this.

>Is there a way to automate this process? So when I update the file link, 
>that’s reflected in the stream, which auto updates too?

Yes...probably. 

I think the problem is entirely just that icegenerator only looks at the .m3u 
file when it first starts up, and then after it has loaded the playlist into 
memory it closes the file and forgets about it. That would explain why you 
have to restart icegenerator every time you change the file.

How easy it would be to automate handling this kind of depends on how picky 
you are about exactly what you're asking.

>How do I go about this?

My initial suggestion would be to try a different source client. I know ices2 
apparently watches the playlist file (if that's where it's source material is 
coming from) for changes and automatically handles this, though it is only for 
.ogg [vorbis] files (I really wish it was updated to support .opus as 
well...).

There is an older "ices0"[2] that is written for .mp3 files. I'm not sure, but 
I *think* it otherwise works the same way as ices2, so it might do exactly 
what you want (automatically notice changes to the .m3u file and update the 
stream accordingly) if you replace icegenerator with it.  (If it turns out 
that monitoring the playlist file for changes is a newer feature only 
implemented in ices2, there may be other source clients for the mp3 format 
that do what you want instead.)

If you aren't willing to switch away from icegenerator for some reason, it's 
still possible but it's going to be more complicated.  Here's what I would 
try:

First - contact the icegenerator developers and ask about having icegenerator 
monitor the .m3u file for changes. It's possible that they'd be interested in 
adding that feature, or maybe even already have and it's just not documented.

Next, as an experiment, next time you modify the .m3u file try using "killall 
-HUP icegenerator" (skipping the entire complex process of manually killing 
and restarting icecast by hand and then [re-]starting icegenerator by hand 
twice).  

The "hangup" (-HUP) signal traditionally tells daemon processes to reload 
their configuration files, so it's possible that command by itself will do 
everything that you're currently doing. There's no guarantee that icegenerator 
works that way, but if it does that will make things simpler. That still 
leaves you manually running one command after updating the .m3u files, but 
it's a start.

If it doesn't work this way for icegenerator, that command should instead tell 
the instances of icegenerator to terminate normally and you can (if nothing 
else) manually run those last two "icegenerator" commands in your procedure as 
usual but skip the restarting of the icecast server.

The only way to fully automate this is to have ANOTHER, separate program 
running to monitor the .m3u files and issue the commands for you. This is 
probably not an optimal way of doing it. However:

There is a set of utilities called "inotifytools" that is specifically 
designed for watching files and directories for changes.  If that is 
installed, supposedly, something like:

while inotifywait -e modify /usr/local/etc/paracast.cfg; do
killall -HUP icegenerator
done

run as a shell script in the background would do what you're describing for 
the "paracast" feed (assuming in this case that "killall -HUP icegenerator" is 
all you need - if you need to run other commands as well you'll have to add 
them...). I should also disclaim that I've never used the inotify tools 
before, so I can't guarantee that what I wrote there would do what I think it 
does.

If you move the icegenerator stream config files to their own directory (e.g. 
/usr/local/etc/audiostreams or something of the sort) you can have inotify 
watch the whole directory of files at once instead of one file at a time.

Yes, that was kind of long, but hopefully the situation makes a little more 
sense to people reading this thread (unless I've gotten confused, too.)


[1] - on CentOS, I *think* (it's been a few years) that the init scripts are 
in /etc/init.d somewhere. The same scripts that get run automatically when the 
system boots up to make sure all the server programs (potentially including 
icecast) start up are normally ALSO used to stop or restart them. Typically if
you're restarting an icecast server on CentOS, the command would be something 
like "/etc/init.d/icecast restart", without needing a complex series of 
commands typed in by hand. If those commands really ARE necessary, then there 
is something unusual about the way it's installed.  If icecast has been 
installed "by hand" instead of using a CentOS ".rpm" package[3], that init 
file may not exist.  As I mentioned, though, this probably doesn't actually 
have anything to do with your problem...

[2] - http://icecast.org/ices/

[3] Icecast seems to be available pre-built for CentOS 6.5 in the "EPEL" 
repositories, so if installed from there I would expect the init scripts to be 
there.  ices0 and icegenerator BOTH appear to be bin the "ATrpms" repository 
as prebuilt packages as well, so they could be installed from there instead of 
built and maintained manually from source. If you have the server's system 
administrator add those two repositories (EPEL and ATrpms), you might find it 
a lot easier to install and  maintain than installing them by hand from source 
will be.