Bugzilla – Bug 1355
Duplicate tracks in cli status command
Last modified: 2008-08-18 10:54:16 UTC
When only a single track is in the playlist the status command returns the track multiple times. As shown below. The web UI and player UI both only report the track once. I think this also happens with two tracks, have not tested three. 00:04:20:05:a1:f7 status 0 10 tag: 00%3A04%3A20%3A05%3Aa1%3Af7 status 0 10 tag%3A player_name%3ASqueezebox2 player_connected%3A1 power%3A1 mode%3Aplay rate%3A1 time%3A17 duration%3A241.306666666667 mixer%20volume%3A35 mixer%20treble%3A50 mixer%20bass%3A50 mixer%20pitch%3A100 playlist%20repeat%3A2 playlist%20shuffle%3A0 playlist_cur_index%3A0 playlist_tracks%3A1 playlist%20index%3A0 id%3A2152 title%3Amissing%20you genre%3ANo%20Genre artist%3Ajem album%3AFinally%20Woken duration%3A241.306666666667 playlist%20index%3A0 id%3A2152 title%3Amissing%20you genre%3ANo%20Genre artist%3Ajem album%3AFinally%20Woken duration%3A241.306666666667
Not a bug, a feature :-) In the example repeat is set to 2 (i.e. all) and shuffle to 0, and the repetition intends to indicate that the same song will play again next. In fact, the playlist_index is correct being at 0 for both instances. If shuffle is on, the SlimServer re-shuffles when it loops (if set to do so) and therefore the CLI cannot "predict" the next playing songs. If shuffle is OFF and repeat is ON, the CLI will try to "fill" the number of items desired with data, by repeating the entire playlist at most once. This behaviour was designed for being used with a '-' as start parameter, which means current. Clients could therefore ask for status - 4 and have a list of songs playing next, taking into account repetition if possible. I think we want to disable the behaviour if - is not used, that'll be less confusing and be a more "proper" call to get the playlist content.
Reopened as a reminder to do last comment, and maybe even check for the "reshuffle on loop" pref. Also check if documentation is clear on this particular point.
SVN 3381
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!