Hi,

As said before, I'm open to enhance liquidsoap's fault tolerance, and
we've already made trade-offs in that direction. Here is the log
message I was talking about the other day:
  log#f 2 "Decoder %s betrayed us on %S!" format filename
If this is detected (it happens in case of file deletion) we don't
crash but simulate an empty file. However, this only handles the
deletion of a file before its opening for decoding. Once decoding has
started, it's up to the encoder to handle gracefully or not a
deletion.

On the other hand, achieving fault tolerance at all costs is a bad
idea. It hides real problems, and there are often better solutions.
For example:

On Mon, Oct 19, 2009 at 7:56 AM, Alessandro Ranellucci
<[email protected]> wrote:
> However I'm interested in achieving fault tolerance for all
> situations you mentioned, including the deletion of a file
> that's currently playing. My users have FTP access to their
> music folder, so they're free to add/remove files and the radio
> should never stop whenever they delete something.

How about you setup your own little protocol that copies a file in a
secure (temporary) place before playing. (Look into the add_protocol
function, and perhaps at the cookbook.html and concepts.html in the
doc, and ask for help here if you need.) In your case, this custom
solution is much better than a builtin tolerance at all costs, because
a file will never be cut in the middle of its playing, which is nicer
for the listener.

Have fun,
-- 
David

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users

Reply via email to