Bug 5614 - Random mix buttons don't work in default skin
: Random mix buttons don't work in default skin
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Web Interface
: 7.0
: PC Windows (legacy)
: P2 normal (vote)
: ---
Assigned To: Squeezebox QA Team email alias
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-29 07:53 UTC by jeffrey s miller
Modified: 2008-12-18 11:12 UTC (History)
3 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jeffrey s miller 2007-09-29 07:53:58 UTC
SqueezeCenter Version: 7.0 - 13344 - Windows 2000 - EN - cp1252

Seen in Firefox 2.0.0.1 and Opera 9.20

The button seems stuck on Random Songs. When hovering Random Artists, Albums, 
or Years, the cursor indicates a link that is not clickable.

Behavior not seen in Fishbone skin.
Comment 1 KDF 2007-09-29 11:14:28 UTC
Interesting. The hover highlight is indeed stuck. This is relatively new, as it was working only a few days ago.
Comment 2 KDF 2007-09-30 00:31:05 UTC
fixed in trunk as of change 13392.
Not sure if changelog is required for this one so leaving open for comment.
Comment 3 Michael Herger 2007-09-30 02:48:10 UTC
Kevin - I'll probably end up adding some JS to make sure all those elements have a unique ID (Ext.id()). The reason it now failed is due to my optimizing the highlighting: before I added the event handler when the page was loaded, now it's created in TT (onmouseover=Utils.highlight()). But this doesn't make sure anymore there's a unique ID, which we now have to take care of.
Comment 4 KDF 2007-09-30 13:04:46 UTC
Random mix id's are unique now :)
Is this still something you plan to do right away?  Might it be something that's post 7?
Comment 5 KDF 2007-09-30 14:59:46 UTC
this is a tricky one. The random mix adds a new track at the end if you delete a track, so the test used in default skin won't work (it matches the new track count with old track count).  In Fishbone skin, when I experimented with this kind of playlist loading, I had to compare each track id, but the Default skin is optimised to avoid loading all of that info.  It is also not valid to simply check the "is playlist changed" flag, as SC currently considers a change of current song as a playlist change.

i did have a patch that got rid of the playlist change for a simple move to the next song, but that does require much more testing with all skins.  At this point, Id suggest it may not be something we want to commit to for 7.0.  Also, given that cometd is in use, it may be a post 7.0 thing to start using that for playlist updates.

for now, it might be good enough to create a special case that puts up a flag for the json response saying that random mix is active, or force a reload from the playerControl function when the command is 'delete'
Comment 6 KDF 2007-09-30 15:01:14 UTC
nevermind.  above comment was for another bug.
Comment 7 Michael Herger 2007-09-30 22:34:38 UTC
> Random mix id's are unique now :)
> Is this still something you plan to do right away?  Might it be something
> that's post 7?

Shouldn't be that hard to do. In fact the code has +/- already been there. I think I'll do it as there will be more and more plugins and others browse modes which can profit.
Comment 8 Michael Herger 2007-10-01 08:01:39 UTC
Change 13423 - make sure any element of the selectorMarker class has an unique ID. This solution should be generic, so not every template making use of selectors has to care about it iself.

Make sure you reload your browse and flush the cache. Re-open  if needed.
Comment 9 Chris Owens 2008-03-07 09:04:57 UTC
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.