Bugzilla – Bug 6135
Player change doesn't work reliably
Last modified: 2009-05-19 08:44:47 UTC
On a player change the Default skin tries to update all links to use the new player. That's bigger problem with the left hand frame: - we have less control over its content than in the main panel where we try to avoid using hard coded player ids - having a JS go through all links and change the player id wouldn't work for JS based links - reloading the page (as done today) with the new player id has some dangerous side effects like eg. a random mix being started automatically if this was the last action executed in the left frame - bug 5842 is reporting similar odd behaviour for the favorites plugin
Phil - can you give me step by step instructions on how to get favorites play on the wrong player? While I've seen it with RandomPlay, too, I can't reproduce it.
Select Player A. Add a Live Music Archive album to the Favorites. Navigate to the favorite. Switch to Player B. Press the Play button on any item within the favorite.
"Navigate to the favorites" - do you just select them from the expanded list in the home or what do you mean by "navigate"?
In the WebUI default skin, from the home page, expand the Favorites menu, and click on the the name of the favorite.
let js use a global var for player, then you only have to update that var. OR have js always grab the stored cookie so that it gets the player last set by the chooser. for html links, replace player in the dom. for forms, have to use the cookie or reload the form. where none of the above works, reload the page with a string replace on player and remove any other args where you can so that queries dont' cause new commands. It's also an idea to have all commands be made as posts through an ajax call where possible so you avoid having these repeat commands (there is a nasty problem with safari in this regard)
Thanks for the input, kdf. But I'm not sure we can reliably replace all references withing a page. If there's eg something like "<a href="javascript:doIt('01:23:45:67:89:ab')"> then we're lost. We can of course fix the official pages not to do so. But we've no control over 3rd party plugins. The current implementation reloads the page after having replaced player ids in the url. But this again is potentially dangerous as we can't control what action is launched by this url. Playing random mixes on the wrong player was an annoying, but still harmless example. Removing all parameters renders this effort useless in eg. the browse menus where state is transferred in urls. I was wondering whether we should come up with a list of safe urls which we can use with the player id replacement. And in all other cases we'd remove parameters before adding the new player id.
> In the WebUI default skin, from the home page, expand the Favorites menu, and > click on the the name of the favorite. change 14630 should fix this
*** Bug 6147 has been marked as a duplicate of this bug. ***
Let's consider this fixed and re-open if needed.
This bug is being closed since it was resolved for a version which is now released! Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html If you are still seeing this bug, please re-open it and we will consider it for a future release.
Request that this bug be reopened. See http://forums.slimdevices.com/showthread.php?p=407088. Playing or adding music from the browse pane will occasionally be sent to the wrong player/playlist. I don't know how to reproduce the problem, but it happens fairly regularly on my system. Maybe once a month or so. When it happens, changing the player using the drop-down has no effect. I can change it several times, but music continues to go to the same (wrong) player. When it gets into this state I don't recall whether or not I see the left hand pane reload, as it should when the player in the drop-down is changed. I'll try to take note next time.
Just experienced this today ,added my vote
Happened to me with the 7.4 nightly from May 13 (one of the last before the switch to SQLite). Haven't tried it yet with the SQLite builds.
Do we want to reopen this bug or start a new one?