GNOME Bugzilla – Bug 522731
Current song not kept visible
Last modified: 2009-06-15 20:08:08 UTC
It should be so I know which is the next or previous track in my playlist (and for just the sense of place in space)
I can't reproduce this; for me the playing track is highlighted correctly. Is there anything specific you're doing, e.g. playing from a playlist, etc.? Also, if you're using trunk, can you 'svn up' and make sure it wasn't a temporary problem?
Created attachment 107412 [details] Blur is playing but 3 doors down is still selected See?
Created attachment 107413 [details] Screenshot of playing indicator Ah, I see what you mean. The appropriate behavior is that the track is given an icon while playing; any track can be selected, playing or not. (See the attached screenshot.)
The real issue seems to be that your icon isn't showing for the playing song. Which icon theme are you using?
Well no, the problem is not that the icon is not shown (it is shown here), the issue is that the view is still where I originally dbl clicked. I would expect it to jump to the current playing song. See rhythmbox for what I mean, on song change the list jumps to the playing song (selecting it and showing it with a play icon). My idea is that if the list doesn't jump and there's no "jump to playing song" then I have to manually browse to the current "play anchor" location.
Aha, I see what you mean.
Setting a more sensible milestone.
Actually, I disagree with this 'enhancement' (providing I understand it correctly). Personally I do not want focus to suddenly switch from my personally selected track to a new track just because it starts playing. That kind of behaviour always annoyed me in iTunes. Diego, you can use Ctrl + J for that.
A vote for this enhancement.... MANY people trying to switch from iTunes expect this behavior and this minor feature is a dealbreaker for some!
I'd also like to vote for this feature. How about this solution which should make more people happy: When one uses Ctrl+J to jump to the currently playing track, the list keeps following the playing track even on track changes. But when one scrolls the view, this "keep the currently playing track mode" is disabled again and the view stays where it is. Then one can press Ctrl+J again and the view follows the track again. Alternatively, it could always follow the currently playing track and there could be a configuration option for this. What do you guys think?
(In reply to comment #10) > I'd also like to vote for this feature. How about this solution which should > make more people happy: > > When one uses Ctrl+J to jump to the currently playing track, the list keeps > following the playing track even on track changes. But when one scrolls the > view, this "keep the currently playing track mode" is disabled again and the > view stays where it is. Then one can press Ctrl+J again and the view follows > the track again. > > Alternatively, it could always follow the currently playing track and there > could be a configuration option for this. > > What do you guys think? > I'm fine with it as long as there is still the opportunity to opt-out, as I under no circumstances want this 'enhancement', which I think is hugely annoying.
I think the biggest improvement would be following the current song when the user presses "next" and "previous" and not necessarily following for automatic transitions.. just my .02
*** Bug 585603 has been marked as a duplicate of this bug. ***
As people is annoyed with both behaviors, a compromise would be the best choice. Two suggestions: 1. Have a setting that let's the user choose what behavior he would like. 2. Automatically jump to the currently playing song until you select another item in the list or scroll the list manually. Then it would go back to automatically after 15 seconds (or something) of no scrolling. This way people will not be annoyed when banshee jumps to another track when they are trying to find a song.
This issue is mostly the same as the one reported in bug 537168. I'm marking this report a duplicate, because bug 537168 has a patch. *** This bug has been marked as a duplicate of 537168 ***