View previous topic :: View next topic |
Author |
Message |
NM
Joined: 05 Jun 2012 Posts: 3
|
Posted: Wed Jun 06, 2012 1:27 pm Post subject: Multiple sources for the icecast streaming server |
|
|
Hi all
I have got icecast working with ezstream as my source client (I couldn't get ices to work). My question is as follows;
We have an application that allows users to upload mp3 files to their own specific directory (also sub directories below this). In order for icecast to stream these mp3s do I need to have an ezstream.xml file for each directory (the contents of which will translate as a playlist)?
Do I then need a mountpoint defined for each directory within icecast? Or even for each user directory?
I think the workflow will look something like: user uploads mp3 file -> mp3 file added to playlist -> server streams playlist. Or am I barking up the wrong tree (or maybe just barking!).
If this is possible, does icecast and/or ezstream need to be restarted after the xml files have been updated? |
|
Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Wed Jun 06, 2012 7:03 pm Post subject: |
|
|
icecast does not care where the content originates from as long as the source client provides the stream.
As to what needs to be done for the source client to handle any new files depends on the the applications ability to update the playlist it uses. In some cases the playlist is a static file which can be re-read on a signal, in others, the playlist is virtual, in as much as that the next entry is determined when the next filename is required.
I suspect if you read the docs then it will become obvious how to trigger a re-read of the playlist.
karl. |
|
Back to top |
|
 |
NM
Joined: 05 Jun 2012 Posts: 3
|
Posted: Wed Jun 13, 2012 10:29 am Post subject: |
|
|
Thank you for your quick response.
I'm still a bit confused about how to set up the source client(s) to create the scenario outlined above.
My best guess at the moment is that I need a source client for every user directory with a corresponding config file. The source client then needs to be restarted with an updated config file every time a new mp3 file arrives in the directory.
I didn't really share your optimism regarding the documentation and having spent more time trawling through config file options in the Icecast Streaming Handbook, I still don't.
I apologise if you think that you're spoon feeding me, but I am still unconvinced that this set up will even do what we want it to, and I can't really afford to spend loads more time wrestling with it.
Thanks Again. |
|
Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Wed Jun 13, 2012 5:30 pm Post subject: |
|
|
A source client like ices reads the files to send based on a playlist which can refer to files in subdirectories or all in the same directory. ices can reload the playlist when required so all you have to do is decide when to update the playlist eg
find /base/directory -type f -name '*.mp3' > playlist.txt
killall -HUP ices
IIRC, you may not need to send a signal, I think the timestamp of the playlist file is checked when the next file is read and if updated, reloads it.
karl. |
|
Back to top |
|
 |
|