[Icecast] Prefered way to check if mountpoint is in use
tyctor at post.cz
Fri Dec 10 13:08:48 UTC 2021
thanks for your reply
On Fri, 2021-12-10 at 11:45 +0000, Philipp Schafft wrote:
> Good morning,
> On Fri, 2021-12-10 at 12:02 +0100, tyctor wrote:
> > hi, thanks for hints
> > On Fri, 2021-12-10 at 00:27 +0000, Philipp Schafft wrote:
> > > This is the 'correct' way. There is no point in checking first
> > > beside
> > > creating an extra race condition and more ways for the check to
> > > go
> > > wrong. ;)
> > >
> > understand, no check, just to try to run ezstream, while mount
> > point
> > is not in use, am i right?
> yes. Maybe it also has a auto-reconnect option.
ok, i will try newer version of ezstream, if it have auto-reconnect
we are using 0.5.6 and there is already 1.0.2
> > > Generally I would suggest to have a look at <on-disconnect>,
> > > "mount_remove" option for URL auth, as well as the "source-
> > > disconnect" event (Icecast 2.5.x).
> > >
> > > Those can provide triggers.
> > <on-disconnect> should be the best way, but it seems not working in
> > version 2.4.4-1 which we are using
> I'm not aware of any bugs regarding it for 2.4.4.
> * Please note that the option takes the path to what is to be
> executed. This is not passed to a shell so you can not include any
> commandline arguments. A set of standard arguments and a basic ENV
> is passed to the binary/script.
> * (Not the case for you) IPC functionality such as this may be
> on Windows systems.
good to hear that it should work
i checked setup and i found, that owner of that file wasn't icecast2
so maybe that was point why it not working, we will se now
> > this seems is latest version in ubuntu 18.04
> > $ apt-cache policy icecast2
> > icecast2:
> > Installed: 2.4.4-1
> > Candidate: 2.4.4-1
> > Version table:
> > *** 2.4.4-1 500
> > 500
> > http://download.opensuse.org/repositories/multimedia:/xiph/xUbuntu_18.04
> > ./ Packages
> > 100 /var/lib/dpkg/status
> > or is there 2.5.x package, for ubuntu 18.04?
> We are currently working on changing infrastructure here a bit.
> There is this repo you could have a look at:
> /!\ However it is at your own risk: it contains non-released code as
> well as repo URL can/will change later on. /!\
> > > I just wonder why not just send the backup signal to the fallback
> > > all the time.
> > probably i am not clearly understanding how you mean this :o)
> > could you please describe it more?
> I understand your setup this way: When there is no "master signal"
> want some kind of fallback signal that is provided by ezstream. And
> already have some source that provides a fallback: Why not let
> run all the time and provide the fallback? This would make the setup
> much less complicated.
our setup is like this:
- mountpoint radio - main mount point where all clients are
connecting, here we are streaming live shows, it has fallback-mount
- mountpoint loops - when is brodcast day, we streaming here jingles
and loops, so when next live show is preparing, this is what clients
listening, while next live show is started, it has fallback-mount
- mountpoint archive - here we are nonstop streaming our old shows, so
when no live stream is available and no loops is available this is what
clients are listening
so we have live DJs show, and we also have prerecorded DJs shows
if DJ cant came to studio, it can send prerecorded DJ set, and it will
play in exact time, when his show was planned
prerecorded DJ sets are playing automatically by ezstream
but if broadcast day is mixed from live and prerecorded shows
sometimes happens that live show last little bit longer
and when ezstream starts planned prerecorded show, it need to wait
while previous live show will release mount point
so this is the cause why i want to start streaming exactly when mount
point is released
but if newer version of ezstream wll have auto-reconnect option it will
More information about the Icecast