DJ hand off

BLCR · 27th June 2017, 20:10

We've switched to v2 on a number of our servers. They are used in Second Life which uses a player that is embedded in the viewer software. When a DJ hands-off the stream to another DJ there is dead air that lasts until the listener restarts their audio player in the software. When I listen on Winamp, windows media server etc... the hand-off is smooth and seamless.

This leads me to believe that the issue is the player in the games viewer. I was wondering if anyone has experienced this. The makers, Linden Lab, insists its not the player, but it seems to happen to everyone listening in the game - again on Winamp or any other external player that I have used it is flawless.

Any thoughts or experience with this happening? SHOUTcast version is 2.5.1.724

sqgl · 11th July 2017, 11:31

Quote:

the hand-off is smooth and seamless.

At best you will get a sudden cut from one to the other. A cross-fade would be "smooth and seamless" but this is impossible.

I have no idea about Second Life but I often have my internet connection go down in which case my backup computer at a different geographic location picks up the stream (like your DJ hand-off). However I notice that some listeners will stay connected, others have restarted (either automatically or manually). Some just stop listening.

These behaviours are player related... kind of: some players/agents/versions are inconsistent. I posted a summary a few months ago.

neralex · 11th July 2017, 20:15

BLCR, on the SHOUTcast v1 you had a short time (buffer) where you can "overtake" the stream from another live-dj. But this was more an bug as an feature. This bug was fixed in v2 and if a source is dropped, then v2 is closing the connection. This caused your pointed "issue". You could try to add a backup file in v2, which would start in this case.

But I would suggest you to install/use a playlist-manager, which is connecting to the DNAS. Because then you can handle a 24/7 or fallback playlist. If you are using linux, then keep an eye on liquidsoap.

dopelabs · 14th July 2017, 03:29

Quote:

A cross-fade would be "smooth and seamless" but this is impossible.

this is easily possible.

also check the shoutcast config setting for

code:
autodumpusers=

a value of 0 should not disconnect the listener if the source drops.

another thing to be aware of is usually tune in files come in the form of playlist files... pls, m3u, etc.

if you open a pls file and your local player treats it as a playlist, you may have only the contents of the file in the players playlist. (I'm already tired of typing 'playlist')

if your local player is configured to repeat all, and you opened a pls file with a single shoutcast server, you may not notice the player loop and start playing the same thing again, basically looping through a playlist of 1 file. many players are pretty good at this and it can happen very quickly.

the easiest way to test this out is to just add the stream in a playlist with other items and see if it jumps to the next track.

does this happen every time there is a switch without fail or only sometimes?

is there normally something being broadcasted when there is not a live dj connected?

I've seen issues when live djs connect too soon after a previous dj disconnects.

generally this is where a nicely tuned auto dj comes in handy to handle the switching between live and archived content, or switching between 2 live djs so that there is never a disconnect between the source and the DNAS. the auto dj always stays connected, detects when a live dj connects and stops playing archived content and sends the live stream instead... and back again when they disconnect.

sqgl · 18th July 2017, 11:00

Quote:

Originally Posted by dopelabs

this is easily possible.

Pray tell.

dopelabs · 19th July 2017, 18:42

you need to have a setup where djs connect to an instance of dnas or a separate sid. I have 4 different servers that djs connect to. when its time for them to go live, my software will just tune into the 'staging' server they are connected to and stream that out... this way while that dj is ending their show, the next dj can already be connected to the 2nd 'staging' server, the software can tune into that one and crossfade from the ending dj to the starting dj.

sqgl · 22nd July 2017, 08:01

Nice workaround. Thanks for sharing the inventiveness. Just as well for society that you are working on the creative side rather than the dark side

I still wish that using a fallback server didn't result in dropped connections half the time. A glitched DJ handoff would then be possible too for those who like to keep it simple.

dopelabs · 22nd July 2017, 14:47

I think the problem your experiencing happens because there's a source disconnect on the dnas when the dj disconnects and the next dj or auto dj connects.

to solve this problem you basically need to have your source stay connected all the time. the source software would manage whats being played on the air. and can switch between archived content and live content.

something that 'might' work is setting a backup file on the dnas so that it will default to something if the source drops for any reason. the only thing to keep in mind is that the backup file needs to be the same bitrate, sample rate, stereo mode, codec, etc as the live content and archived content. some players don't handle switching between bitrates or mono vs stereo, or to/from different codecs very well.

sqgl · 23rd July 2017, 10:00

The reason for the backups is that internet is unreliable in Australia and I get a laptop at another location to take over therefore it cannot be at the same location as the DNAS. The DNAS and the two sources are all at different locations (ie total of three). The DNAS is at the most reliable location.

I use a backup mp3 but that is no guarantee of a maintained connection to the listener.

dopelabs · 24th July 2017, 00:18

its the disconnect and reconnect of the source to the DNAS from program to program is most likely the source if the problems your seeing.

you can test this by doing the process manually. have your local machine send to the dnas, then you can tune into the dj and relay that to the DNAS, then (without disconnecting from the DNAS) switch to some other archived or static content.

then see if the listeners disconnect after the switch from dj to whatever.

different geographic locations is not uncommon. I have instances of shoutcast for dj's to connect to in several locations so connections for the dj's can be as local as possible.. London, Zurich, Silicon Valley, Los Angeles, Amsterdam, etc ,etc. id rather have a dj from London to connect to a server I have in London rather than trying to cross the pond to a US based server. taking an unpredictable network route which can cause any number of issues for the. stream. instead they broadcast to their local server, which has a much more direct and controllable network route between them and me.

27th June 2017, 20:10	#1
BLCR Member Join Date: Feb 2014 Posts: 68	DJ hand off We've switched to v2 on a number of our servers. They are used in Second Life which uses a player that is embedded in the viewer software. When a DJ hands-off the stream to another DJ there is dead air that lasts until the listener restarts their audio player in the software. When I listen on Winamp, windows media server etc... the hand-off is smooth and seamless. This leads me to believe that the issue is the player in the games viewer. I was wondering if anyone has experienced this. The makers, Linden Lab, insists its not the player, but it seems to happen to everyone listening in the game - again on Winamp or any other external player that I have used it is flawless. Any thoughts or experience with this happening? SHOUTcast version is 2.5.1.724

22nd July 2017, 08:01	#7
sqgl Senior Member Join Date: Sep 2008 Location: Australia Posts: 188	Nice workaround. Thanks for sharing the inventiveness. Just as well for society that you are working on the creative side rather than the dark side I still wish that using a fallback server didn't result in dropped connections half the time. A glitched DJ handoff would then be possible too for those who like to keep it simple. Remixing listener requests of ambient tracks live http://RePlayScape.com

23rd July 2017, 10:00	#9
sqgl Senior Member Join Date: Sep 2008 Location: Australia Posts: 188	The reason for the backups is that internet is unreliable in Australia and I get a laptop at another location to take over therefore it cannot be at the same location as the DNAS. The DNAS and the two sources are all at different locations (ie total of three). The DNAS is at the most reliable location. I use a backup mp3 but that is no guarantee of a maintained connection to the listener. Remixing listener requests of ambient tracks live http://RePlayScape.com

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

11th July 2017, 20:15	#3
neralex Major Dude Join Date: Mar 2011 Posts: 576	BLCR, on the SHOUTcast v1 you had a short time (buffer) where you can "overtake" the stream from another live-dj. But this was more an bug as an feature. This bug was fixed in v2 and if a source is dropped, then v2 is closing the connection. This caused your pointed "issue". You could try to add a backup file in v2, which would start in this case. But I would suggest you to install/use a playlist-manager, which is connecting to the DNAS. Because then you can handle a 24/7 or fallback playlist. If you are using linux, then keep an eye on liquidsoap.

19th July 2017, 18:42	#6
dopelabs Major Dude Join Date: Oct 2006 Location: Silicon Valley Posts: 534	you need to have a setup where djs connect to an instance of dnas or a separate sid. I have 4 different servers that djs connect to. when its time for them to go live, my software will just tune into the 'staging' server they are connected to and stream that out... this way while that dj is ending their show, the next dj can already be connected to the 2nd 'staging' server, the software can tune into that one and crossfade from the ending dj to the starting dj.

22nd July 2017, 14:47	#8
dopelabs Major Dude Join Date: Oct 2006 Location: Silicon Valley Posts: 534	I think the problem your experiencing happens because there's a source disconnect on the dnas when the dj disconnects and the next dj or auto dj connects. to solve this problem you basically need to have your source stay connected all the time. the source software would manage whats being played on the air. and can switch between archived content and live content. something that 'might' work is setting a backup file on the dnas so that it will default to something if the source drops for any reason. the only thing to keep in mind is that the backup file needs to be the same bitrate, sample rate, stereo mode, codec, etc as the live content and archived content. some players don't handle switching between bitrates or mono vs stereo, or to/from different codecs very well.

24th July 2017, 00:18	#10
dopelabs Major Dude Join Date: Oct 2006 Location: Silicon Valley Posts: 534	its the disconnect and reconnect of the source to the DNAS from program to program is most likely the source if the problems your seeing. you can test this by doing the process manually. have your local machine send to the dnas, then you can tune into the dj and relay that to the DNAS, then (without disconnecting from the DNAS) switch to some other archived or static content. then see if the listeners disconnect after the switch from dj to whatever. different geographic locations is not uncommon. I have instances of shoutcast for dj's to connect to in several locations so connections for the dj's can be as local as possible.. London, Zurich, Silicon Valley, Los Angeles, Amsterdam, etc ,etc. id rather have a dj from London to connect to a server I have in London rather than trying to cross the pond to a US based server. taking an unpredictable network route which can cause any number of issues for the. stream. instead they broadcast to their local server, which has a much more direct and controllable network route between them and me.