Bugzilla – Bug 1738
"Coming Next" listing
Last modified: 2009-09-08 09:15:41 UTC
When you select a genre or artist and have it shuffle by song it places a long list of tracks in the right pane. The song that is now playing appears above the song list and changes as songs change. However, the long list of songs doesn't scroll in order to keep the now playing song at the top of the list. It still does appear in the now playing box. The long list of songs stays stationary. The song playing is bold and the bold moves down the list. If you listen to more than 15 or so songs you can no longer see the bold. You have to manually scroll in order to see where you are in the list. Therefore if you want to see what is coming next and manage that you have to scroll down. In my opinion it should scroll automatically as it progresses through the song list. This is the way iTunes functions when you put it on party shuffle. Listing "Coming Next" below "Now Playing" would address part of this problem but I like to see a full screen list of what is coming next. Then I can delete songs I don't want to hear in one fell swoop versus having to do it one at a time or wait for it to start and skip over it.
Patrick, can you supply details as to which browser and version you are using. Most of the skins should be refreshing the current playlist every so often (30s by default) and should be refreshing such that the anchor is set to the current song. You should not have to be scrolling.
Windows XP Latest version of Explorer
seems to work in Firefox. only jumps to correct position on a manual window refresh in IE.
commenting out the if (window.location.hash == '') { in the javascript function, to_currentsong() seems to do the trick. I can't recall the reason that we needed to check for '', but debugging using an alert popup seems to show that the currentsong anchor is always there. For some reason, on a simple reload, IE decides not to honour that anchor.
KDF, feel free to go with a fix.
I'll commit the fix when I get home. I'll leave this open for the 'coming next' feature and mark as an enhancement when that is all that's left. In the meantime, Dean was the original committer on the to_currentsong() function. It would be nice to know the origin of the if window.location.hash=="" test, just to be sure its not going to cause another problem elsewhere under some less common use.
committed at change 3585. Leaving this open as an enhancement for 'coming next'. given what is already on everyone's plate, I'll take it off 6.1 for this part. if I come up with something that's simpler than what I'm expecting it to be right now, I'll revisit and post a patch.
well, that didn't work. it turns out that Safari goes into rapid reload with this change. sorry for the false start :(
moser posted a potential fix, which I committed at change 3591. This tested against IE as the browser and forces the hash setting then. the other option was to test against a 'bogus' hash value, which would work for any browser that is messed up in the same way as IE, yet would barf if a hash of that name ever happened to come up. I went with the browser check. If this is acceptable, we can close this off or remark as enhancement for later in regard to the 'coming next' idea.
That setting to 'bogus' then setting to the real thing is more for Safari's bug rather than IE's. The two bugs are: IE: must have the location.hash explicitly set (even if it is already at that value) in order to scroll the window to that value. Safari: reloads full page rather than just scrolling if you explicitly set location.hash to its current value. This possibly also affects KHTML. With the bogus fix Safari will break if we set to a bogus value which turns out to not be bogus, and was already set to that value. With the browser check fix Safari will break if it impersonates IE, and IE will break if it impersonates something other than IE (if that is even possible). Since other browsers apparently don't suffer from either of these bugs, they won't break in either case.
What do we think so far? I'd like to close this off if the current performance is acceptabe, or get goiing on a patch if we need to go a different route on this, or got with Moser's suggestion
Seems like the browser check works for the 99% case. If someone sets up Safari's user agent string to impersonate IE (or vice versa), they'll get exactly what they asked for.
thanks. marking as fixed. can always re-open if a 'coming next' display is really needed.
This bug was marked resolved in Slimserver 6.1, which is several versions ago. If you're still seeing this bug, please re-open it. Thanks!