Bugzilla – Bug 2759
Music will occasionally be queued to the wrong player, depending on UI state
Last modified: 2008-09-15 14:37:04 UTC
This is a bit hard to set up, but once set up, is entirely reproduceable. I have 2 SBs. I've called them SB1 and SB3 (I named them at the web interface). If you go to the home page on the left panel of the UI and hover over, say, Browse Albums, in the message bar at the bottom of the IE window you can see the command that would be generated if the link was clicked. It is http://localhost:9000/browsedb.html?hierarchy=whatever&player=MAC ADDRESS If you, on the right pane, switch to the other SB, the page refreshes and now if you hover over the link it will say yada,yada,yada&player=the other mac address. Now start winamp on the same computer, dial in http://localhost:9000/stream.mp3 and a new player shows up in the right hand pane, allowing you to select that player. Once you select that player, the left hand pane URLs change so that they say player=127.0.0.1 (in my case - that's localhost in IP). Now change the right hand pane back to one of the hardware SBs. The URLs on the left don't update. Now you can no longer queue files to any device except the software one. No matter what you do with the right hand pane, the left hand panes continue to contain player=the software one, and that's the only place you can queue music. You can hit refresh on the browser. For me, this works because refresh always causes the right hand pane to go to SB3 (I don't know why this is - it forgets whatever it was and goes to SB3). For one of the people on the thread that started this bug, it always goes back to the software one. And so he's now stuck only able to queue music to the software player. This last bit sounds like it may need to be broken out as a separate bug. Or it may have been reported already. I haven't checked yet. In any case, Refresh is an undesireable workaround, because you lose your place in the browse hierarchy on the left pane. If you had drilled down to Various Artists/Album/Title, you now have to re-drill to get there again.
This is coming up with increasing frequency. A user reported this to me and had this to say: -------------------- I have 2 SB3s and I also run SoftSqueeze on the host PC. If I sync SoftSqueeze with either of the SB3s, I am unable to select either of the sync'd players from the SS web page player pull-down. They show up as "Living Room (sync'd with PC)" and "PC (sync'd with Living Room)", but if I try to select either player it always ignores my pick and stays with the unsync'd SB3 player. As soon as I unsync the players I can successfully select any of the three to control from the SS pages. See if you can replicate this problem. -------------------- I have yet to be able to reproduce this, though. It seems as if on some systems even when all of the java/javascript stuff is enabled, the web interface just isn't switching properly... Any thoughts, Dan?
On my system it was entirely reproduceable. I set it up and did it three times, shutting down slim in between, etc.
so, is this was bug2810 is about as well?
(In reply to comment #3) > so, is this was bug2810 is about as well? Sorry, kdf, I'm not sure. I tried it with various combinations of SB1s, SB3s, SB1s&3s, everything always worked fine until the first time I went over to an ip based player, then it just broke. In other words, all the hardware players could switch amongst themselves fine, but after you went to a software player you never came back. I don't have a SLiMP3 to test with. So it may happen there too, but I can't verify. Oh, if only someone would donate a SLiMP3 to a good cause :-)
(In reply to comment #4) > (In reply to comment #3) > > so, is this was bug2810 is about as well? > > Sorry, kdf, I'm not sure. I tried it with various combinations of SB1s, SB3s, > SB1s&3s, everything always worked fine until the first time I went over to an > ip based player, then it just broke. > > In other words, all the hardware players could switch amongst themselves fine, > but after you went to a software player you never came back. > > I don't have a SLiMP3 to test with. So it may happen there too, but I can't > verify. Oh, if only someone would donate a SLiMP3 to a good cause :-) > I gave Kevin Pearsall the IP of a system where the bug is entirely reproducible, using IE6 or Firefox. That system has only one SB1, and the introduction of a remote streaming player using WinMedia always breaks the queueing--it always goes to the software player. Perhaps having that IP will aid in identifying the problem. Steve Terry
Since I can reproduce this, is there someone who can tell me what sort of debugging information is needed to start tracking down this bug?
d_http (should show the urls being processed and served up at each refresh. d_playlist will show the rendering of the playlist (no changes needed, render is skipped) also try javascript console to see if there are any errors reported in there that might be interfering with the scripts. I put in a small fix to the doLoad() function that has been reporting an exception. it doesn't interfere with the refresh for me, but the fix is cleaner and may be somewhat related for those having refresh problems.
Created attachment 1103 [details] log.txt Very Wordy log.txt showing (I hope) the problem. I hope you have tools to delve through this thing, it's half a megabyte long for half a 3 minute song.
I finally had some time to re-create this. Sorry for the delay. Day job interefering with hobby again. The Java console is quiet.
Sorry, I should have noted. This was run against 6.2.2 build from about 4 nights ago.
I did some more research on this bug. The problem does not surface with softsqueeze, but it does with winamp. The difference seems to be related to the fact that a softsqueeze player gets a MAC-Address like name, whereas a winamp player gets an IP like name. I don't know if this will help debug the problem.
That could explain why I could not reproduce. I'm working with only hardware players.
(In reply to comment #12) > That could explain why I could not reproduce. I'm working with only hardware > players. Bug only shows up with a mixture of hardware players and (as it turns out) a winamp player. I originally assumed that softsqueeze would have the same problem, but it doesn't. The original description does mention winamp as a necessary pre=condition.
Try this with default skin and hopefully this will trap the IP playerid as well as the mac id cases. Edit EN/html/common.js, change switchPlayer to: function switchPlayer(player_List) { var newPlayer = "=" + player_List.options[player_List.selectedIndex].value; parent.playlist.location="playlist.html?player"+newPlayer; window.location="status_header.html?player"+newPlayer; if (parent.browser.location.href.indexOf('setup') == -1) { for (var j=0;j < parent.browser.document.links.length; j++) { var myString = new String(parent.browser.document.links[j].href); var rString = newPlayer; var rExp = /(=(\w\w(:|%3A)){5}(\w\w))|(=(/d{1,3}\.){3}\d{1,3})/gi; parent.browser.document.links[j].href = myString.replace(rExp, rString); } } else { myString = new String(parent.browser.location.href); var rExp = /(=(\w\w(:|%3A)){5}(\w\w))|(=(/d{1,3}\.){3}\d{1,3})/gi; parent.browser.location=myString.replace(rExp, newPlayer); } }
fix committed to 6.5 builds at change 5757. if this clears up the issue, please confirm so that I can merge with 6.2.2
ok, no takers then :) I've committed 6.2.2 at change 5815. please reopen if there is still any trouble with this issue
*** Bug 2872 has been marked as a duplicate of this bug. ***
apparently not solved for Handheld skin, but can use the same fix. It will have to wait until tonight.
(In reply to comment #16) > ok, no takers then :) > I've committed 6.2.2 at change 5815. please reopen if there is still any > trouble with this issue Sorry, I have been tied up with other things the last few days. Day job interfering with hobby again .... Will check it out on the weekend if not sooner.
Hi Installing 6.2.2. from the nightly build (confirmed the fix was applied to the installed version), and I still se the problem. My setup: I have a slimp3 device, and I am streaming to a XMMS player on my laptop. I named the slimp3 device "slimp3", and left the XMMS player to be identified by the IP. Changing the current player in the right pane to "slimp3", and navigating to a track in the left pane, and adding it to the playlist, updates the playlist for player "192.168.1.4" which is the XMMS player. Prior to testing I did remove all traces of previously installed 6.2.1, including conf. files. Br Jan
which skin, please? can you also right click on one of the left side links copy the url, then change players and copy the url again? paste those urls here as well, thanks.
Hi. Ok, wiped the system again, and this time resintalled 6.2.2 under a different username (to ensure I didn't stumble into old .slimserver files somewhere). Either it's a weird problem that only kreeps up under certain conditions, or there must have been a lingering file somewhere that I didn't find at first system wipe, because I can't recreate the problem now. The links seam to update correctly as I change the player. I'll do some more testing over the next few days to confirm.
The problem, as I originally described it (with winamp or other non-softsqueeze stream players) is fixed as of 6.2.2 nightly from the 26th and the default skin.
I am going to close this one now as fixed. If there is in fact a problem with the handheld skin, someone is welcome to open a problem report against it. I am unfamiliar with the handheld skin, but 10 minutes of poking around with it made me understand the problem there with a winamp stream player is that you can't even navigate away from the winamp player once it has been selected, a quite different problem (which was solved in the default skin a few weeks ago as I recall). So it may be that Handheld has a problem, but it's a different problem than this one.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.