Hello,

i'm using Shoutcast v2.2.1.190 with transcast v2.0.0.54 and Winamp with DSP-Plugin v2.3.3.
The server is set up to start and play with the autoDJ. The metadata is displayed just fine and all fields are filled.
When i connect to the transcast-port for the shoutcast 2 protocol only the field with the current song is updated. All other fields regarding station name, stream genre and stream url stay the same as set from the autodj.
If i look into the source.log i can see the following entries:
msg:[DJPROTOCOLUVOX] ICYNAME for DJNAME is mytestname
msg:[DJPROTOCOLUVOX] ICYGENRE for DJNAME is Alternative
msg:[DJPROTOCOLUVOX] ICYURL for DJNAME is http://www.testurl.com

It seems like those entries aren't sent to shoutcast 2 and thus nothing is updated there.

Even more interesting, if i use the DSP-Plugin with v1-protocol and the v1-port, then i only see updates for the song-name in the source.log. Although it works just fine with the plugin when streaming directly to a Shoutcast v1 server.

What can i do to fix the display of the other fields beside song?
Did i miss something?

Hope you can give me a hint.

Best regards
Azrael

The main details of streams provided through a v2 DNAS are fixed which is determined according to what has been set in the authhash for the stream(s). So this is an intentional design as constantly changing station names for example make it hard to find a station that way and it can cause other issues with the SHOUTcast platform.

sc_trans does not pass on all of the information from the DJ source (whether it is from a v1 or v2 based source) to the DNAS as it's not a feature of the v1 protocol (all that the v1 protocol allows for is providing the information on connection) and support had not been completed in the v2 protocol (it was being worked on to allow for name, genre, url and DJ name to be relayed on, but with sc_trans currently removed and uncertain of its future, those changes are now unlikely to see the light of day + it would have only been of use if the DNAS was not publically listed as the authhash takes precedence).

When connecting a source directly to a v1 DNAS or a v2 DNAS in private mode (or when unable to access the YP) then it will show the information from the source since it isn't controlled by an authhash under those situations (which has it's benefits and also it's issues as ease of updating information vs generally inconsistent details between DJs which typically can lead to the stationid changing - which the authhash is there to prevent against happening [unless it's a codec/bitrate change] ).

So what you're seeing is completely expected with both versions of the DNAS and the version of sc_trans you're able to use.

Thank you for the answer. This clarifies a lot.

Unfortunately i have several customers who rely quite much on sending specific metadata for each DJ. On Shoutcast 1 with ices-cc this worked by stopping the autodj and then sending directly.
With Shoutcast 2 and sc_trans2 as autodj, this behaviour and usage doesn't seem to be intended any more.

Is there a suitable way to accomplish such a behaviour with Shoutcast 2 without too much effort?

By stopping sc_trans2 every time a dj wants to broadcast would render all the new dj-features useless.

It's not a simple change to allow it since it's just not in the protocol (v1 or v2) to allow for live updating of such information, hence having to disconnect the source when using the v1.x DNAS to force an update. So it'd need at least a) DNAS updates, b) potential source software updates (which for sc_trans is pretty much not going to happen) and c) potential YP changes.

Also as the authhash (so pre-registering the stream details) is a core part of the v2 platform, something would need to be done with that to allow for things which is then somewhat at odds with how that has been implemented.

What specifically are they wanting to show / pass on and why? As altering the station name per DJ is not a good experience as i know from a lot of listener feedback i've seen that they just want to see the playing information and don't want all the extra 'crap' (as they put it) in the titles (which is obviously at odds with what stations / DJs want for promotional aspects).


I guess what i'm trying to get at is to understand what / why this information is so critical and why it must be live updated inorder to help decide how / what can be done on the SHOUTcast protocol side to help (if it's possible without major platform breakage).

After talking with the customer i was able to confince them, it wasn't really necessary, thus this is no problem any more.

Another point which is important to them.
Currently there is a delay of 30 seconds betweeen the connection of  a live source to transcast until the listeners hear the live dj.
Is it possible to shorten the delay to e.g. 20 seconds?

not really as there's no options to control the size of the buffers used in sc_trans (which is where the largest delay will be introduced from in such a setup).

the v2.2.x DNAS by default (unless configured otherwise) has it's buffer set to a few seconds (based the bitrate of the stream) instead of a fixed buffer size which v1.x and v2.0 use by default, which helps lessen the lag between source and listener.

however, SHOUTcast is not a live system and although it's possible to lower the buffering (depending on the DNAS version and source software being used if it allows for it), so it'll never be guaranteed to be below a few seconds at most.