Hi Damien!
Your script looks fine. I would just suggest to indent it as I find it
easier to read and fix when it is indented.
Another remark which is optional but can make the script look nicer and help
you to make sure you have the right parameters: since all your playlists
share the same conservative and length parameters, you could do that:
(beginning of the script..)
# Specialize playlist with common settings
playlist = playlist(conservative=true, lenght=4000.)
(rest of the script goes here..)
This redefines the playlist operator with those two parameters already
applied, Then, later in the code, you just have to do:
output.icecast(%vorbis,
host = "localhost", port = 8000,
password = "(password)", mount = "techno.ogg",
description="Synthetronica Radio: Techno", genre="Techno",
url="http://audiodef:8000/techno.ogg";, name="Techno",
fallback( [
normalize( playlist( "techno.m3u" ) ),
single("/var/www/audiodef/htdocs/audio/dc3.ogg") ]
)
)
Concerning the number of queues, one per stream is probably a good rule of
thumbs in your case. With more streams, you may not need a one-by-one
correspondance tho. More importantly, this is up to your situation: just
try, see what works through the logs and get the right number accordingly
:-)
Finally, I know that VLC used to have issues with ogg streams but that was a
long time ago and it has been fixed since then. I have never tried audacious
personally, but maybe others here know better about this player..
Good luck with your streams and have a good week-end!
Romain
2011/9/24 Audiodef Online <[email protected]>
> I forgot to mention, I use either Audacious or VLC, both of which handle
> ogg streams. I use them for this purpose all the time.
>
> Has anyone else every had any issues with these two players as pertains
> to ogg streams?
>
> On 09/24/11 09:21, David Baelde wrote:
> > Hi Damien,
> >
> > I believe your analysis is good in the last mail. By default
> > liquidsoap only has one thread for tasks such as downloading. This
> > would be a good explanation for one stream "stopping" because it can't
> > get its downloads fast enough, when you add other streams that also
> > perform long downloads. Here is the relevant setting for fixing that
> > issue (taken from liquidsoap --conf-descr):
> >
> > ## Generic queues
> > # Default: 1
> > set("scheduler.generic_queues",1)
> > # Comments:
> > # Number of event queues accepting any kind of task.
> > # There should at least be one. Having more can be useful to avoid that
> > # trivial request resolutions (local files) are not delayed because of
> > # a stalled download. But N stalled download can block N queues anyway.
> >
> > In your case I'd set it to the number of streams performing large
> downloads.
> >
> > Now, your streams are not really stopping when they fail to download,
> > but just playing silence thanks to mksafe(). However, streaming pure
> > silence is a bad idea with most codecs, so I'd advise you to not use
> > mksafe(), replace it by some noise or a default file (download it once
> > and for all, so that single("<that file>") will be infallible).
> >
> > One last thing: mplayer (like many other players) doesn't really
> > support reading OGG streams, but only reads the first track and then
> > stops. This is explained in our FAQ, with ways to work around the
> > players' limitations. It's probably not the top issue for now, but you
> > should keep it in mind when testing with mplayer. A player that
> > properly reads streams is.... liquidsoap! (Simply use liquidsoap
> > 'out(input.http("<your stream>"))'.)
> >
> > All this should help fix the problem and understand better what's
> > going on. Using telnet (if only for debugging) would also be useful to
> > monitor downloads.
> >
> > Hope this helps,
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Savonet-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/savonet-users
>
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users
