Bugzilla – Bug 3404
Playlist pane not updated when player is changed
Last modified: 2008-09-15 14:38:25 UTC
In the Default skin the playlist pane doesn't get updated to the playlist for newly selected player. It gets refreshed, but with the playlist for the previously selected player. I can also see the wrong MAC address in the playlist's control URLs. It's just a little inconsistent in it's behavior. Not sure if this helps, but I have two SB2s and a software player defined at the moment. When I select the software player the playlist always gets updated correctly, but when I switch from one of the hardware players to the other it's never updated correctly. This is at r7386 running the Perl code on XP Pro and is seen in both Firefox and IE.
probably the new cookie-based control? I've used cookies with Fishbone skin for some time, and it's been a bumpy road.
Hmm at first I was going to say I can't reproduce, but then it did happen to me. I think there is a race condition between the time the cookie is set and the time the playlist frame is reloaded. I will look into it.
(In reply to comment #1) > probably the new cookie-based control? I've used cookies with Fishbone skin > for some time, and it's been a bumpy road. No, this was happening before the new cookie based control. Which isn't working either. I was going to post another bug report on that issue but hadn't gathered from the checkin whether it was actually supposed to be working or if the code checked in was just in preparation for some future change. New observation: I think it may only happen when the playlist of the newly selected player is empty. If both playlists are non-empty then they switch as expected.
I can reproduce with both playlists populated. As you said it's not related to the cookie because all the refreshes use the player query param anyway. The cookie only comes into play when you do a full refresh or open a new browser.
Just to be sure I rolled back to r7382, before the cookie code was added to the trunk (r7383). Same behavior.
have a look at the doLoad function from common.js then. might also be useful to watch newPlayer var in switchPlayer. However, that script is very similar to the code used in the Fishbone skin...and I haven't noticed a bad player frame refresh with that for a some time. I could be possible that I overlooked something I needed to merge from one of those fixes in that back into default.
I think I've tracked it down to the Safari code in doLoad(). When status_header.html refreshes, it reloads the playlist frame *using the old URL*. Either the Safari code needs to be changed to rewrite the player param, or the refresh function needs to refresh the playlist first, then the status_header.
hmm... Fishbone version of the doLoad function is in ajax.js, called refreshPlaylist. I had to add a var for the new player, and replace that in the url as well in order to make it work reliably. That might be one way to go.
And the race condition comes into play when switchPlayer changes the playlist location, but if the doLoad code fires before the playlist has finished reloading, I think that's when you get the wrong playlist reloaded.
Checked in a possible fix. Can you see if it helps?
Yep, so far it looks good. I'll do some more testing.
I assume we can close this bug? I'll merge back to 6.3 if you guys think it looks good.
I'll leave this as Jim's call. The patch looks good, but I've been unable to test with multiple players.
Definitely working well for me. I have four players now - two hardware and two software - and switching between any of them, empty playlist or populated, is working without a hitch.
Great, marking as fixed.
This bug fix is now part of a released version, and so has been marked closed. If you are still experiencing this problem, please reopen the bug.