Bug 4421 - Pressing play when displaying a track title in the playlist plays Track 1
: Pressing play when displaying a track title in the playlist plays Track 1
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Playlists
: 6.5.1
: PC Windows XP
: P2 enhancement (vote)
: ---
Assigned To: KDF
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-25 11:58 UTC by Mick
Modified: 2008-12-18 11:12 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mick 2006-10-25 11:58:49 UTC
I'm running 

SlimServer Version: 6.5.1 - 10426 - Windows XP - EN - cp1252
Server IP address: 192.168.2.3
Perl Version: 5.8.8 MSWin32-x86-multi-thread
MySQL Version: 5.0.22-community-nt
SB2 & SB3 both running FW67

Library contains all MP3's.

If I am playing 10 songs and on song 4 (for e.g.)
I then scroll down to track 7 and scroll right to the song title. I then press play.
The playlist jumps back to track 1 and starts playing the song.

Tested with a playlist containing 1 album using Softsqueeze & running random mix on an SB3.
The fact that I can repeat on both real h/w and Softsqueeze makes me think this is a server issue.

Also, on Softsqueeze 3.2, playback of track 1 often happens at 1/2 speed.
I haven't seen this on my SB3 though.
Comment 1 Mick 2006-10-25 13:32:38 UTC
Just downloaded the nightly of the 25th to confirm that this is still an issue.

SlimServer Version: 6.5.1 - 10471 - Windows XP - EN - cp1252
Server IP address: 192.168.2.3
Perl Version: 5.8.8 MSWin32-x86-multi-thread
MySQL Version: 5.0.22-community-nt

Comment 2 Chris Owens 2006-10-31 11:23:31 UTC
This is as-designed.  If you scroll down to track 7, and hit play, then track 7 plays.  If you scroll down to track 7, and hit 'right' to go look at the track info, then hit 'play', the 'play' applies to what the playlist is currently doing, i.e. playing track 1.  If you play track 1, and hit 'play', track 1 begins playing again.

It seems like you would rather see this play the track you are browsing.  What would you like to happen if you browse to the track artist and hit 'play'?  Play all that artist's tracks starting with the current one?  What about if you hit 'play' on the track year?

Or would it be okay to do something like just ignoring 'play' if you hit it while browsing track info?

I'm interested in your opinions on this, but we'll of course need to make the decision that makes sense for all our customers and our overall product plans.

Thanks for any info!

Comment 3 Mick 2006-11-01 13:05:59 UTC
Chris,
This is hardly a showstoppper but...
What's happening is slightly different to your explanation. The behaviour doesn't match up with the expectation which is why I consider something to be broken.

If track 5 is playing and I scroll down to track 7, scroll right and click play, I think most people would expect track 7 to play. By your logic, track 5 might start again, and that might make some sense. But track 1 start's playing.
I don't think anyone can say that that design decision makes sense to the user. They certainly didn't ask to got back to the start of the playlist.

Since i found this by accident and as mentioned is hardly a showstopper, I think I'd like either track 7 to play or nothing at all to happen.

Keep up the good work.

Mick
Comment 4 KDF 2006-11-01 13:57:58 UTC
Actually Chris, this looks like legacy cruft.  The Trackinfo mode used to load playlists and play based on which item was being selected (genre, album, etc), with a fallback to simply bounce out of trackinfo and play if the trackinfo item wasn't playable.  This got optimised down, then moved to using INPUT.List. During all of that, the jump(0) command was left behind.  This is what is causing the problem.  For non-playable items in trackinfo, the command is there to pop right and play, but then it is incorrectly followed by a jump to the first track in the playlist.  This jump was originally ONLY called when a new playlist was loaded as a result of loading a genre/album/artist.


The line should be around line 46, and needs to go away:
$client->execute(['playlist', 'jump', 0]) unless $addOrInsert;

windows would require this in a nightly build as local mods don't affect slim.exe.  I would definitely call this a bug.

Comment 5 KDF 2006-11-01 21:24:45 UTC
committed to trunk at change 10554.  not sure if we want to bounce this into 6.5.1...can merge if that seems ok.
Comment 6 Mick 2006-11-02 01:28:07 UTC
Dean,

I'm not quite ready to start running 7 yet. I do usually do an update to 1 6.5 nightly each week. This isn't a major issue, so it might be worth leaving.
On the other hand, what is it likely to break if included in 6.5.1. I can then at least test and confirm the bug is closed.

Mick
Comment 7 KDF 2006-11-02 01:55:14 UTC
I'm not Dean.
it's ok if you don't want to run 7.0al, the QA folks can if it is felt to be important enough to try.  Overall, Bugzilla is a developer too, so most times the comments are among developers.
Comment 8 Chris Owens 2006-11-08 10:49:46 UTC
I'd rather leave this out of 6.5.1, especially since it's such a minor bug.  Thanks for pointing out my error!  I have added this point to the spec, as well.
Comment 9 KDF 2006-11-08 12:17:05 UTC
heh, I had to dig well back through the history to get to the original intent :)
assigning to me so that I can make the note in the changelog for 7.
Comment 10 Mick 2006-11-08 14:52:38 UTC
Thanks Kevin.

Apologies for the name mix up in my earlier post. Your e-mail address confuses my dyslexic brain at times.

Mick.
Comment 11 KDF 2007-09-29 22:35:51 UTC
sorry.  lost track of this one.  changelog added at change 13391
Comment 12 Chris Owens 2008-03-07 09:05:07 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.