[Icecast] Icecast source with updateable metadata?

[t***@757.org]

Hello everyone,

I'm not new to Icecast, but I've always used Darkice. A new project
friends and myself are building for fun utilizes a Rivendell automation
setup that will run on one computer, then a source client for icecast on a
2nd computer with a mixer inbetween.

I'm looking to push the title information from the Rivendell system over
to the system that will have the icecast source. The icecast source
program needs to have some interface to modify the title information
(metadata) while encoding, not just at the start.

I'm looking for a source client that allows updating of the stream
information real time. In darkice it's set in the config and it doesn't
allow modification of this. Do any of the other source clients allow this?

I've looked at MuSE and it didn't appear to, although the documentation
file is offline. I haven't begun building them all looking for the
feature. Anyone know of one that can do this?

If it comes down to it we can possibly hack one of them to do it. Just
thought I'd check!

[Romain Beauxis]

Post by t***@757.org
I'm looking for a source client that allows updating of the stream
information real time. In darkice it's set in the config and it doesn't
allow modification of this. Do any of the other source clients allow this?

you can use liquidsoap for that.You can either insert metadata in a stream or,
in the SVN version use the operator
icy.update_metadata
to update metadata of any source at any time.

Romain

[David Baelde]

Post by Romain Beauxis
you can use liquidsoap for that.You can either insert metadata in a stream or,
in the SVN version use the operator
 icy.update_metadata
to update metadata of any source at any time.

To be fair, there's no need to use liquidsoap. As the second
possibility shows, inserting metadata can be done independently of the
actual streaming: you just need to send an HTTP request. You should be
able to find how to do that online. You could also use liquidsoap, if
only for the metadata update.

Cheers,

[Geoff Shang]

Post by t***@757.org
I'm looking for a source client that allows updating of the stream
information real time. In darkice it's set in the config and it doesn't
allow modification of this. Do any of the other source clients allow this?

If you want to change the title of the stream etc, which Darkice can send,
then no you can't do this. It's set when you connect and won't change
unless you disconnect and reconnect. Moreover, if the listener is not
disconnected during this process (e.g. if you use fallback mounts to keep
them connected), they won't see the title change, even if new listeners
see the new title. This is because the title is only sent from the source
at connect time and only to the client at connect time. I'd like to be
able to change this too but the specs don't seem to allow for it.

If you want to send track metadata (aka "now playing" information), which
IIRC Darkice does *not* support in any fashion (but I could be wrong about
this), you can probably send this directly from your playout system as has
been pointed out.

Assuming you're using a native Icecast2-style connection (i.e. not
Shoutcast emmulation), I believe the format is as follows:

http://<username>:<password>@<server>:<port>/admin/metadata?mount=<mountpoint>&mode=updinfo&song=<metadata>

Most of these should be self-explanatory. If you've not set a username,
use "source". Track metadata is usually sent as "Artist - Title". All
fields need to be URL-encoded.

Here's an example:

http://source:***@example.com:8000/admin/metadata?mount=%2Fstream&mode=updinfo&song=The%20Beatles%20-%20Hey%20Jude

In case you're actually using Shoutcast-style connections, the format is:

http://<server>:<port>/admin.cgi?mode=updinfo&pass=<password>&song=<metadata>

Note that for Shoutcast-style connections, the audio is sent to the
listener port + 1 (e.g. port 8001), but the metadata updates are actually
sent on the listener port (e.g. 8000).

HTH,
Geoff.

[Thomas B. Ruecker]

I'm a bit surprised you're asking this as the official rivendell wiki
seems to cover this already and there are some other explanations
when you use the search engine of your least distrust to search for
'rivendell icecast'.

http://rivendell.tryphon.org/wiki/Stream_under_Debian#Icecast2.2FShoutcast_Meta_Data_from_Rivendell

just my 0,02€

Thomas

[Bryan D. Brown]

Hello,

I'm having a major problem with the timestamps in both the Icecast access.log and error.log. The timestamp on the logfiles themselves is accurate, but the logging of the various connections to my streams is in UTC. No matter how I try to configure the hwclock or the system clock, the log timestamp is always UTC, which is 8 hours ahead of my current time zone. I've even tried setting the hwclock to localtime, but to no avail.

I've just updated and compiled to the newest kernel as well, but that still hasn't solved the problem. Clearly, I'm missing something, but I'm at a loss as to what it could be.

I am running Icecast 2.3.2 with Darkice on a Gentoo box (Intel Pentium 4 CPU 3.20GHz kernel-2.6.36-gentoo-r5). I'm including my conf.d/clock settings and the result of 'date', 'hwclock --show' and 'uname -a' as well. I should also mention that the timestamps in my other logfiles (/var/log/messages for example) are accurately timestamped - the icecast logs are the only place where this UTC issue occurs.

# date
Thu Dec 16 12:24:02 PST 2010
# hwclock --show
Thu Dec 16 12:24:08 2010 -0.156608 seconds
# uname -a
Linux live 2.6.36-gentoo-r5 #2 SMP Thu Dec 16 10:56:44 PST 2010 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz GenuineIntel GNU/Linux

# /etc/conf.d/clock
CLOCK="UTC"
TIMEZONE=""
CLOCK_OPTS=""
CLOCK_SYSTOHC="YES"
### ALPHA SPECIFIC OPTIONS ###
SRM="no"
ARC="no"

(/etc/locatime is copied from /usr/share/zoneinfo/PST8PDT)

Any help would be greatly appreciated.

Thank You.

Bryan

[Bryan D. Brown]

Never mind. I figured it out. I added:

export TZ=PST8PDT

to the .bashrc for the user under which icecast runs, and it fixed the problem. Oops...

Although if some sees something I should fix... :)

Bryan

Post by Bryan D. Brown
Hello,
I'm having a major problem with the timestamps in both the Icecast access.log and error.log. The timestamp on the logfiles themselves is accurate, but the logging of the various connections to my streams is in UTC. No matter how I try to configure the hwclock or the system clock, the log timestamp is always UTC, which is 8 hours ahead of my current time zone. I've even tried setting the hwclock to localtime, but to no avail.
I've just updated and compiled to the newest kernel as well, but that still hasn't solved the problem. Clearly, I'm missing something, but I'm at a loss as to what it could be.
I am running Icecast 2.3.2 with Darkice on a Gentoo box (Intel Pentium 4 CPU 3.20GHz kernel-2.6.36-gentoo-r5). I'm including my conf.d/clock settings and the result of 'date', 'hwclock --show' and 'uname -a' as well. I should also mention that the timestamps in my other logfiles (/var/log/messages for example) are accurately timestamped - the icecast logs are the only place where this UTC issue occurs.
# date
Thu Dec 16 12:24:02 PST 2010
# hwclock --show
Thu Dec 16 12:24:08 2010 -0.156608 seconds
# uname -a
Linux live 2.6.36-gentoo-r5 #2 SMP Thu Dec 16 10:56:44 PST 2010 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz GenuineIntel GNU/Linux
# /etc/conf.d/clock
CLOCK="UTC"
TIMEZONE=""
CLOCK_OPTS=""
CLOCK_SYSTOHC="YES"
### ALPHA SPECIFIC OPTIONS ###
SRM="no"
ARC="no"
(/etc/locatime is copied from /usr/share/zoneinfo/PST8PDT)
Any help would be greatly appreciated.
Thank You.
Bryan
_______________________________________________
Icecast mailing list
http://lists.xiph.org/mailman/listinfo/icecast

[Thomas B. Ruecker]

Post by Bryan D. Brown
I'm having a major problem with the timestamps in both the Icecast access.log and error.log. The timestamp on the logfiles themselves is accurate, but the logging of the various connections to my streams is in UTC. No matter how I try to configure the hwclock or the system clock, the log timestamp is always UTC, which is 8 hours ahead of my current time zone. I've even tried setting the hwclock to localtime, but to no avail.
I've just updated and compiled to the newest kernel as well, but that still hasn't solved the problem. Clearly, I'm missing something, but I'm at a loss as to what it could be.

You're lucky we had this problem once come up on IRC.
What you describe is all well and fine, but you actually need to adjust the environment variables for the icecast process. For some reason those you set globally got ignored, maybe some override in the init script that sets TZ=UTC or sthg like that?

If that's not it I can dig out the IRC logs during the weekend. ;)

Cheers

Thomas

[Bryan D. Brown]

Tom,

Is it the icecast process that's the issue, or is it the user under which the process runs? FWIW, I call icecast from the command line, not an init script.

This is a dedicated machine, so there's nothing else of note running under this particular (and only, aside from root) user. If fact, the only reason there is a user on this box is for non-root SSH and for icecast.

Thanks for your help.

Bryan

Post by Thomas B. Ruecker

Post by Bryan D. Brown
I'm having a major problem with the timestamps in both the Icecast access.log and error.log. The timestamp on the logfiles themselves is accurate, but the logging of the various connections to my streams is in UTC. No matter how I try to configure the hwclock or the system clock, the log timestamp is always UTC, which is 8 hours ahead of my current time zone. I've even tried setting the hwclock to localtime, but to no avail.
I've just updated and compiled to the newest kernel as well, but that still hasn't solved the problem. Clearly, I'm missing something, but I'm at a loss as to what it could be.

You're lucky we had this problem once come up on IRC.
What you describe is all well and fine, but you actually need to adjust the environment variables for the icecast process. For some reason those you set globally got ignored, maybe some override in the init script that sets TZ=UTC or sthg like that?
If that's not it I can dig out the IRC logs during the weekend. ;)
Cheers
Thomas
_______________________________________________
Icecast mailing list
http://lists.xiph.org/mailman/listinfo/icecast

[Thomas B. Ruecker]

Post by Bryan D. Brown
Is it the icecast process that's the issue, or is it the user under which the process runs? FWIW, I call icecast from the command line, not an init script.

Icecast just inherits the environment from the shell you use to launch it.

Post by Bryan D. Brown
This is a dedicated machine, so there's nothing else of note running under this particular (and only, aside from root) user. If fact, the only reason there is a user on this box is for non-root SSH and for icecast.

Well the benefit is that it e.g. starts on boot automatically.

cheers

Thomas