Bug 11994 - With CM and touch-to-play, we don't need "Play All" or "Add To Favorites" anymore.
: With CM and touch-to-play, we don't need "Play All" or "Add To Favorites" any...
Status: CLOSED FIXED
Product: SqueezePlay
Classification: Unclassified
Component: Browser
: unspecified
: PC Other
: P1 normal (vote)
: 7.4.0
Assigned To: Ben Klaas
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-07 13:17 UTC by Blackketter Dean
Modified: 2009-10-05 14:31 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 Blackketter Dean 2009-05-07 13:17:21 UTC
Play All is replaced by playing the first song
Add To Favorites should be a choice in the CM for the item.
Comment 1 Weldon Matt 2009-05-07 13:28:14 UTC
Agreed.
Comment 2 Ben Klaas 2009-05-07 15:11:23 UTC
fixed for local music, SC 7.4/trunk r26482.

I did not remove the Play All item from XMLBrowse items yet. That's going to require a bit extra thought before I strip that out.

I will be very happy when all of these "special" items can get ripped out of SC and we can restore some sanity to our chunking behavior. Bug# 7829 can finally die when that happens.
Comment 3 Jim McAtee 2009-05-07 17:10:24 UTC
(In reply to comment #0)
> Play All is replaced by playing the first song
> Add To Favorites should be a choice in the CM for the item.

_IF_ you have the pref set to do so.  Although the actual behavior of 'Play' is yet to be defined, right now anyone normally accustomed to building playlists is not going to use 'play other songs'.  Are context menus at the album, artist, genre, etc. levels still to come?
Comment 4 Weldon Matt 2009-05-07 17:21:55 UTC
Jim, I don't follow you.

'Play' does not add a song to the NP playlist per se - it starts a new playlist consisting of the song you selected (plus the rest of the relevant album or, once we get a current bug fixed, relevant playlist) and begins playback.

Adding a track to the NP playlist is a different flow, and the "add rest of album" setting shouldn't apply in that case (if it works that way now, we should file a bug to address it).

So I don't see how "anyone normally accustomed to building playlists
is not going to use 'play other songs'."  Unless I am mistaken about current behavior (which as mentioned above should be changed if needed).

And yes, context menus are going be added elsewhere in the system.  A very basic case (track-level) is being worked on first before other larger changes are made, AFAIK.
Comment 5 Jim McAtee 2009-05-07 17:34:43 UTC
I wasn't aware that the 'Play Other Songs In Album' pref was going to be ignored.
Comment 6 Ben Klaas 2009-05-07 20:35:19 UTC
There is a server pref for play remaining songs in album, and that server pref can be turned on or off. I know of no decision to strip that code out, but rather to make the default (if it isn't already) to play remaining songs in the album.

As long as it still exists as a server pref I don't think we should be dismissive that someone might want to do it. If the server pref needs to die (which I don't believe is the case), that needs a separate bug because there will be a fair bit of SC code to strip out.

I think that we're covered, however, by adding add-hold/context menus for non-track items. This way playing/adding an entire album (or artist, or genre, or year) will remain a simple process, even for those that don't have the server pref set that way.
Comment 7 Weldon Matt 2009-05-07 21:42:38 UTC
I guess my question is: does t he server pref apply only when you "play" a song, or does it also apply when you "add" a song?  If it's only for "play" then it sounds like we're (sort of) covered, right?  If it applies to "add" also (by this I mean add to end/add next), then perhaps we should consider a second pref for this case (so that the default for "play" would be add rest of album/playlist, and the default for "add" would be just to add the one song).  If I understand all this correctly, then this should deal with the problem Jim is hinting at...
Comment 8 Ben Klaas 2009-07-16 09:09:15 UTC
changing several bugs at once-- target milestone on these do not apply to the CXR/CAT milestone
Comment 9 Ben Klaas 2009-08-03 07:49:08 UTC
I don't believe there is anything left to fix on this bug
Comment 10 James Richardson 2009-10-05 14:31:47 UTC
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.