Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DJ appears to step down while skipping song #10

Open
stevenleeg opened this issue Jun 9, 2014 · 1 comment
Open

DJ appears to step down while skipping song #10

stevenleeg opened this issue Jun 9, 2014 · 1 comment
Assignees
Labels

Comments

@stevenleeg
Copy link
Member

When skipping a song I've noticed that the DJ (myself, in this case) will appear to step down and then step up again and resume playing the next song.

Ideally the expected behavior is for the active DJ to be passed onto the next DJ in line or seamlessly skip to the next song if you are the only DJ on stage (in my case I was the only DJ).

@stevenleeg stevenleeg changed the title When skipping song DJ appear to step down DJ appears to step down while skipping song Jun 9, 2014
@stevenleeg stevenleeg added the bug label Jun 9, 2014
@clehner
Copy link
Member

clehner commented Jun 9, 2014

I introduced this delay in 8b6def3 for skipping from a single DJ to themself, to prevent a race condition in the WebRTC signaling. When skip is triggered, the DJ removes the stream for the current song from their peer connections with the other users in the room, and then adds a new stream to each peer connection, with the new track. Both removing and adding the stream trigger a negotiationneeded event, which we listen on to renegotiate the PeerConnection (offer, answer, exchange ICE candidates). Initiating the renegotiation twice without waiting for the response seemed to put the peer connection in a bad state and caused an error.

The delay does look a bit sloppy. We could handle this more cleanly by detecting when negotiationneeded is going to be fired twice, and only start renegotiation after the second time. This could be done by using a debounce function, or by manually triggering the renegotiation instead of using the negotiationneeded event. Or, reuse the same stream for the new track so the connection doesn't have to be renegotiated at all.

@clehner clehner self-assigned this Jun 9, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants