Hi,

Here are a couple answers.

On Mon, Mar 10, 2008 at 9:01 PM, sk89q <[EMAIL PROTECTED]> wrote:
>  (1) When a source client connect, it appears, at least through telnet,
>  that only the URL field gets passed through and not title or
>  description. Can this be changed?

This should not be the case, indeed. Please double-check your source
client, and confirm the problem with more details: which source client
are you using (we need to know if it's icecast/shoutcast-compatible),
how does it connect to liquidsoap (input.harbor/http()). You can also
test with a vorbis stream: in that case, it is impossible that the
metadata gets lost anywhere as it is bundled with the audio. I'm sorry
I don't have any more to say here, let's hope that the devs that have
been implementing metadata support in those inputs know possible
tricks.

>  (2) Using a dynamic playlist where the track names come from the
>  output of a called program, no title is sent to the Icecast server. I
>  suppose this is the "song" variable? But it doesn't exist for the
>  playlist tracks anyway. Can I substitute in a metadata myself for each
>  request.dynamic using an external process?

Again, this should not be the case. You can track down the issue by
first checking that liquidsoap can read the metadata from your files,
by calling "liquidsoap -r FILENAME". Then, what metadata is sent
depends on the output you're using. Vorbis outputs send all standard
metadata: "title", "artist", "album"... but not "song". The MP3 output
sends all of these including "song", but unlike with vorbis, MP3
metadata might be dropped by icecast between the source client and the
listener.

If liquidsoap can't read the metadata from your files, or if you just
want to force them, there are at least two solution. The first is
rewrite_metadata(). It won't allow an external process to change the
metadata, but will simply apply some patterns to them, e.g.
rewrite_metadata([("title","blahprefix $(title)"),("artist","forced
artist")],s). A nice solution since you're using a dynamic playlist is
to prepend some annotation to the URI/filename that your script
outputs. Changing FILENAME into annotate:title="forced":FILENAME adds
the metadata to the request. (Don't ask me what happens in case of
conflicts between annotate metadata and file metadata, I don't know
which one is prioritized.)

>  (3) When switching from live to playlist, the playlist song that was
>  playing continues to play. A new song does not start up. Can the
>  playlist be forced to fetch a new song (and fade into it) when it is
>  fallen to, without using track_sensitive=true?

The fallback.skip() function from utils.liq is for you: this is a
wrapper around fallback() that toots made for exactly that purpose.

>  (4) Under the case that I don't want a new song to be played, can the
>  metadata be reset? If the live source cuts off, the metadata for the
>  live source continues to be sent instead of the metadata for the
>  playlist track. The metadata will only be reset once a new playlist
>  track loads up. (Note, the metadata is blank for the playlist tracks
>  anyway, as mentioned in (2)).

This is a possible feature request. We've been considering it, but
fixed other things instead and never really needed that feature in the
end. If you feel like you need it, don't hesitate to ask: it'll be
pretty easy to do.

>  (5) When a source is connected to the harbor but it sends no data,
>  Liquidsoap will still fall back to the playlist. Can this prevented,
>  as long as a source is connected to the harbor?

I didn't know about that. I can't test right now, and don't have time
to dig in the code either. But you can hope to get an answer from the
more harbor-aware devs... otherwise, double-check the issue and file a
bug report on Trac to motivate them ;)

>  (6) I am not sure what the transitions parameter really is for
>  fallback function. If I put in more than one function in that tuple,
>  what happens?

A switching operator (fallback(), random() or switch()) with childrens
[s1,s2..sN] expects N transition functions [f1,f2..fN]. When switching
from sI to sJ, the transition function fJ is used. If the list of
transition is too long, that's an error; otherwise it is padded with
the dummy transition fun (a,b) -> sequence([a,b]).

Have fun,
-- 
David

Reply via email to