play other songs feature is specifically for IR remote control only.  Code only exists in Button modes and does not affect CLI/Web/JSON control.

so that makes this an enhancement.

I'll call this a bug, since it's incorrect behavior.  

you were the one who kept saying it was for remote only -- button modes.

jive doesn't use the button modes.

So, are you now saying it should be web and jive (ie in the command dispatch?)

Please keep web and remote interface settings separate.  This is a useful behavior for the remote interface, which is less agile, but probably not very desirable in the web interface.

The end user/customer does not know the difference between buttons, web mode or jive mode.

There is a setting in the Web UI which says "Play other songs in album". If that's set, then there's an expectation that other songs will play. Currently Jive does not fulfill that expectation. The how's/why's of that are irrelevent to the end user.

So the choice is to either remove the setting/functionality, which would be a real pity, or support it from Jive.

Why not recognize that the (now three) different interfaces are... different?  They require different settings due to the different presentations and different mechanics of each.  I'm not sure I care whether a setting previously used only in the remote ui is applied to the jive interface, so long as it's clearly understood.  I'm saying that applying the same preference across all these very different interfaces for the sake of "consistency" or "simplicity" can be a mistake that will make them all less usable.  I want this behavior when using the remote interface, but not in the web interface, and don't at the moment care which for jive.

see also the recent bug 5595 which oddly reiterates that it's a remote ui setting, but per player now. Suppose Brian should review this along with that one.

*** Bug 6450 has been marked as a duplicate of this bug. ***

Sorry to flip-flop on this one.  I'm going to call this an enhancement since we have a prominent Play All selection on the Jive UI.

If we do add a play other songs feature, we should add a setting in the Jive UI, not necessarily on the web ui.

That said, I don't think it's that important.

*** Bug 7037 has been marked as a duplicate of this bug. ***

*** Bug 7036 has been marked as a duplicate of this bug. ***

I'd like to retarget this to 7.0.1.  

The Jive does have a prominent 'Play All', but if you select a specific song, then hit FWD or REW the behavior seems to confuse and irritate users.

Note SB3 has this feature all worked out.  We should not deny it to users of our new products.

it may seem that way, but this is implemented explicitly as part of the player UI:
	$client->execute(["playlist", "addtracks", $findCriteria]);
	$client->execute(["playlist", "jump", $listIndex]);

and in BMF:
	$client->execute(['playlist', 'addtracks','listref', \@playlist]);
	$client->execute(['playlist', 'jump', $listIndex]);

If we want this in Jive, it needs to be created anew as part of the CLI, or we have to consider implementing a direct port for cli/jive/web whichever we wish to have support for this feature.  In the brief period when it WAS supported on the web UI, it was directly in Web/Pages/BrowseDB. Not impossible, but not without risk.

the more I consider this, it seems a central cli isn't an option as we don't always have the same access to the container.  Sometimes it's an album, sometimes a folder.  each context is going to have to create the list of tracks or the findCriteria.  Then could be done with multiple cli calls, or a combined playtracks that has an optional index arg for the starting track.

(In reply to comment #14)
> the more I consider this, it seems a central cli isn't an option as we don't
> always have the same access to the container.  Sometimes it's an album,
> sometimes a folder.  each context is going to have to create the list of tracks
> or the findCriteria.  Then could be done with multiple cli calls, or a combined
> playtracks that has an optional index arg for the starting track.
> 

I would LOVE to see this as a configurable option for the default behavior of the server with THE ORIGINAL loadtracks CLI command.

If you want a suggestion on how it could be done as the CLI is now, look at how iPeng does it, even though this is not perfect (will explain below, why):

>playlist shuffle ?
- store <shuffle> value -
IF <shuffle> != 0
>playlist shuffle 0
>playlist loadtracks <whatever>  NOTE: a better way would be to do playlist clear and playlist addtracks, but that's two more calls
>playlist index #  NOTE: for the "addtracks version another "playlist play" would have to be added here.
IF <shuffle> != 0
>playlist shuffle <shuffle>

To determine the container content iPeng calls "songinfo track_id:###", "playlistinfo" or "songinfo url:xxx" depending on context to determine the correct index (if not known).

This is all quite a bit of a nuisance to do over CLI so I would REALLY like to see this done in the server as a configurable option. Guess that would help Jive, too....

Ben, can you follow up with Dean and work out if this is a 7.0.1 fix.

Reset priority

removing priorities from all 7.0.1 target bugs for re-prioritizing

I discussed this bug with Dean today. It's clear there's some back-end SC work to be done first, and then Controller (and whatever else) can follow. That takes it off my pile for now...moving to unassigned for review, and targeting for 7.1 per discussion with Dean.

We did both agree that this is a desirable and needed feature, and needs to be implemented in a way that different UIs can use the same code.

Only for information: I just posted this in the forum (some things changed):

This might seem a minor problem [i.e. the difference behaviour of the play button on my just new SBC, the 'old' remote and the web interface], but for me it is a major one. Maybe I have set up my library a bit weird (but I like it this way). E.g., in my library I have Beethoven > Beethoven Piano Sonatas (Gilels). All sonatas are there (well, all sonatas Gilels had recorded when he died), and I certainly won't start at Sonata 1 all the time. So normally I go to the first part of the sonata I want to hear and press play. But I don't want to hear only the first part of that sonata.

There may be some technical difficulties, but as an end user I strongly feel that the behaviour should be the same everywhere.

Let me add some extra's:

1. some say there is a play all button, but that's not what I want (see description above).

2. When I encountered this, I rechecked my settings and sure thought this was a bug.

I hope action is taken (I'm new here, but it seems the bug is unassigned).

Teus

I'm not a very sophisticated user, and I'm not really able to follow the technical discussion in this thread, but just to add my experience:

To an unsophisticated user like myself, this seems like a bug. In SqueezeCenter there is a player setting "Play other songs in album", and it doesn't make any qualifications as to which interfaces this setting affects. That is, users expect that the player will play other songs in the album, regardless of how the initial song was selected to be played.

More to the point, though, regardless of whether this is properly called a bug or enhancement, it's a serious issue. Within like 2 minutes of using the Controller my wife noticed the problem. We routinely like to start playing an album somewhere in the middle, and it seems pretty silly that the Controller cannot do this.

In fact, I'm going to hold of on recommending the Controller to others until this issue is resolved.

Created attachment 3396 [details]
play all for browse album under web only.

backend work on SC would involve getting the album or folder when a track is picked.  Simple enough, but the blocker is that SC knows nothing of the context of a single track. Controller users Command::playlistcontrolCommand with a track_id, or list of track_ids.  These could have come from genre, artist or folder context.  Not all cases make sense to add the entire album.  

basic problem is there are far too many ways to "play a track", especially since at least three of these ways are all given something similar to "track.id = xxxxx" in order to specify the track.  This would bring to question why additional methods were needed.

this simple patch deals with just one case.  This is around line 1413. browse music folder is handled around line 1136, controller is handled around 1684 as a direct grab of a list of tracks (with no context)

assigning to myself to fix

note: stumbled into another catch... using random mix (as it uses the cli commands) will also trigger play all, so you get the whole album for each song loaded.

This fix is probably going to have to come from each UI, at least until the schema a browsing is rewritten in 7.3.  That, or each UI needs to send it's context to the cli (probably where we're going to be anyway in 7.3)

I've put a fix for this on the controller, 7.1 change 21576

This should work for both browsing in "Albums" and "Music Folder" on the controller. While it works for me, the change was reasonably involved and I'd like to see QA do some extra testing on this one.

I agree with KDF's last comment that, at least how we have things currently, this needs to be solved on a per-UI basis until some more fundamental things are changed re: schema and browsing.

This bug was originally opened against the controller, and I'm considering that fixed now. If there needs to be a similar fix for webUI, that should be a separate bug.

Appears to be fixed in Controller r2551 and SC 7.1-21605

For the records: the queries would fail if there was no player connected to SC. Fixed to check for the existence of a player before accessing its prefs in change 22103.

This bug has now been fixed in the 7.1 release version of SqueezeCenter!  Please download the new version from http://www.slimdevices.com if you haven't already.  

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

This bug has been fixed in the 7.3.0 release version of SqueezeCenter!

Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already.  

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