hello!
thanks for your answer. However it didn't solve my problems, unfortunately.
1) Regarding my question about metadata rewriting, I'm really no good
writing liquidsoap scripts. I first tried fancy things using your tips but
then I stepped back to something really simple, but still no go: the
metadata don't seem to be rewritten. Please can you help me fixing my
broken liquidsoap language writing skills.
My conf file is the same as before, except this small modification:
def mklivedynamic(source)
# Add lastfm submission
source = on_metadata(lastfm,source)
# Get metadata from external source
live_title = list.hd(
get_process_lines(
scripts^"suds-getcurrentlivetitle "^quote(radiopilote_conf)
)
)
# Rewrite
rewrite_metadata(
[("artist", "Live"),
("comment", "$(radio_name)"),
("title", live_title)],
source
)
end
the suds-getcurrentlivetitle outputs a correct line of text, each time
(terminated by a line feed), but the tags are not modified. Neither the
"artist" tag (this is quite odd BTW) or any other.
2) Liquidsoap keeps disconnecting from the shout socket from time to time
even if I increase the number of available generic queues.
2008/11/05 23:20:44 [generic queue #2:4] There are 0 ready tasks.
2008/11/05 23:20:44 [generic queue #3:4] There are 0 ready tasks.
2008/11/05 23:20:44 [src_3668:4] Got metadata at position 384: calling
handler...
2008/11/05 23:20:44 [decoder:4] Trying MP3 decoder for
"/home/overfitted/radio/resources/pool/994.mp3"
2008/11/05 23:20:44 [format.mp3:4] open
"/home/overfitted/radio/resources/pool/994.mp3"
2008/11/05 23:20:44 [format.mp3:4] close
"/home/overfitted/radio/resources/pool/994.mp3"
2008/11/05 23:20:44 [dyn_Global:4] queue length 1323000+=1323000 (rid 5)
2008/11/05 23:20:44 [fast queue #1:4] There are 0 ready tasks.
2008/11/05 23:20:44 [src_3669:4] Got metadata at position 384: calling
handler...
2008/11/05 23:20:44 [generic queue #4:4] Left select at 1225927244.588542
(1/0/0).
2008/11/05 23:20:44 [generic queue #4:4] There are 2 ready tasks.
2008/11/05 23:20:44 [liqfm:4] Submiting Space Art -- Alpha Du Centaure
Part Two to
lastfm
2008/11/05 23:20:44 [fast queue #1:4] There are 1 ready tasks.
2008/11/05 23:20:44 [fast queue #1:4] There are 0 ready tasks.
2008/11/05 23:20:44 [fast queue #1:4] Enter select at 1225927244.619826,
timeout
-1.000000 (4/0/0).
2008/11/05 23:20:44 [fast queue #1:4] Left select at 1225927244.619950
(1/0/0).
2008/11/05 23:20:44 [fast queue #1:4] There are 0 ready tasks.
2008/11/05 23:20:44 [fast queue #1:4] Enter select at 1225927244.620059,
timeout
-1.000000 (4/0/0).
2008/11/05 23:20:44 [generic queue #3:4] There are 0 ready tasks.
2008/11/05 23:20:44 [non-blocking queue #1:4] There are 0 ready tasks.
2008/11/05 23:20:48 [root:2] We must catchup 4.38 seconds!
2008/11/05 23:20:48 [non-blocking queue #2:4] There are 0 ready tasks.
2008/11/05 23:20:48 [/:2] Shout socket error: timeout, network failure,
server
shutdown? Restarting the output in 6 seconds.
2008/11/05 23:20:48 [generic queue #1:4] There are 0 ready tasks.
2008/11/05 23:20:49 [src_3671:3] switch to src_3667 with transition
2008/11/05 23:20:49 [source:4] src_3817 gets down
2008/11/05 23:20:49 [source:4] src_3815 gets down
2008/11/05 23:20:49 [source:4] src_3814 gets down
2008/11/05 23:20:49 [source:4] src_3816 gets down
2008/11/05 23:20:49 [source:4] src_3830 gets up
2008/11/05 23:20:49 [source:4] src_3828 gets up
2008/11/05 23:20:49 [source:4] src_3827 gets up
2008/11/05 23:20:49 [source:4] src_3829 gets up
2008/11/05 23:20:49 [src_3666:4] Got metadata at position 128: calling
handler...
3) Then I noticed something really strange (a new problem ;)), I can
connect and stream to input.harbor with an Icecast-compatible source
client but it appears liquidsoap does not speak ICY though. The source
client cannot connect to liquidsoap if it uses the Shoutcast idiom.
I've tried with both the official Winamp Shoutcast DSP and Virtual DJ.
2008/11/05 22:40:22 [harbor:3] Invalid ICY request
2008/11/05 22:40:22 [harbor:3] Failed: Invalid ICY request
See the previous message for the conf file.
Thank you for your time and dedication to liquidsoap fast development.
Cheers.
<citation de="Romain Beauxis">
> Le Tuesday 04 November 2008 20:55:59 okay_awright, vous avez écrit :
>> hello everyone,
>
> Hi !
>
>> Please bare with me, I'm a new user of the magnificent liquidsoap ;)
>
> Woah, thanks :-)
>
>> I've recently migrated to a recent SVN of liquidsoap, the latest one
>> that doesn't encompass the video-related code (SVN #5946)
>
> As there seems to be some concern about the addition of video into
> liquidsoap,
> there should not be any performance or other thing with it.
>
> In particular, the video channel is currently disabled by default in the
> current svn, so video support shouldn't matter.
>
>> and I have
>> one question and one request for troubleshooting.
>>
>> First, I've updated my release of liquidsoap because I needed the
>> 'auth' function callback in input.harbor. And this feature works
>> really great. Thanks for that. However, I have one question: I need to
>> rewrite the metadata of the stream from input.harbor with dynamic data
>> (i.e. non-static, not hardcoded in the configuration file but
>> retrieved from an external resource). I know the ANNOTATE
>> functionality won't work because it can only be used along with URIs
>> but it is exactly this kind of mechanism I would require: fetching
>> external data from script outputs.
>> Maybe I could use the 'auth' or 'on_connect' functions of input.harbor
>> and store the global variables retrieved until I use rewrite_metadata
>> for the stream. The problem is that I really don't know how to write
>> that using the liquidsoap language. Any hint please? (and with a short
>> example it would even be better)
>
> I believe you need the map_metadata operator:
> This operator provides a callback for rewriting metadata.
>
> For instance:
> def my_rewrite(metadata) =
> (.. whatever you like ..)
> end
>
> source = map_metadata(my_rewrite,source)
>
> Using this function, you may call any external script of your own, and use
> the
> returned value for the new metadata.
>
> The default behaviour of this function is to update only the returned
> fields.
> For instance, if:
> def my_rewrite(metadata) =
> ("title","dumb song")
> end
>
> Then only the title field will be updated. In case you want a complete
> rewrite, you can use the "update" option. You may also remove empty
> metadata
> by using the "strip" option.
>
> Actually, rewrite_metadata is written using this function. The code is in
> scripts/utils.liq in the source tarball, or in
> ${prefix}/liq/liquidsoap/${version}/utils.liq
>
>
>> My second question is related to the observation of the odd behaviour
>> of my new liquidsoap installed (put in production mind you, I do
>> regret) compared to my old install (0.36SVN).
>> Regularly, the stream completely shuts down after the end of a track.
>> This happens quite often and this is really annoying because it goes
>> up online only a few seconds afterwards.
>> I believe it is either related to this build or to my conf file
>> because the system remained unchanged and so the downstream server
>> used to relay the stream (which is really reliable).
>>
>> Here is an excerpt from my logs, the disconnection appears at
>> 19:31:11. It is always the same error repeated from one end to the
>> other in my logs.
> (...)
>> Any help welcome, please.
>
> The log seems to show that the deconnection is due to liquidsoap lag, as
> shown
> in these lines:
>> 2008/11/04 19:31:05 [generic queue #2:4] There are 1 ready tasks.
>> 2008/11/04 19:31:05 [liqfm:4] Submiting Shina Williams & His African
>> Percussionists -- Agboju Logun to lastfm
>> 2008/11/04 19:31:05 [generic queue #1:4] There are 0 ready tasks.
>> 2008/11/04 19:31:05 [non-blocking queue #2:4] There are 0 ready tasks.
>> 2008/11/04 19:31:10 [root:2] We must catchup 4.99 seconds!
>> 2008/11/04 19:31:11 [/:2] Shout socket error: timeout, network
>> failure, server shutdown? Restarting the output in 6 seconds.
>
> Liquidsoap lags, so the shout connection disconnect by timeout, and the
> source
> gets restarted. Much likely, the lastfm submition induced some latency, as
> we
> also noticed in our production server (running svn !).
>
> The solution could then be to enable more queues. I see you already did it
> in
> your script. Perhaps adding one or two more generic queues, but I am not
> really sure about this, please let us known if it helps..
>
>
> Romain
>
--
best regards,
--
okay_awright,
<[EMAIL PROTECTED]>
[PGP key on request
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users
