[Icecast] Automatic Update of MP3 Files

[Gene Steinberg]

Now we’re cookin’.

I’m forwarding this feedback to the Webmaster to deal with.

Peace,
Gene


> On Sep 27, 2014, at 8:49 AM, epicanis+icecast at dogphilosophy.net wrote:
> 
> 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.
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast