Bugzilla – Bug 15609
Add a "index:<track#>" parameter to playlistcontrol
Last modified: 2010-02-12 00:42:56 UTC
This is an enhancement request I'd need for iPeng for iPad. It's about adding an optional "index:#" parameter to the playlistcontrol CLI command. It would apply to "add" and "insert" commands and allow to add tracks to a playlist at an arbitrary position. playlistcontrol cmd:insert album_id:12 index:15 would insert the tracks of album 12 at position 15 (16th track in the list) or at the end of the list if the list contains fewer than 15 tracks. index could also (optionally, I have a possible use case but don't really need this) take relative arguments which are anchored around the currently playing track, so playlistcontrol cmd:insert album_id:12 index:-1 would add the tracks BEFORE the currently playing track, +1 would resemble the current "insert" behavior.
Andy, is this feasible?
Yeah sounds like a reasonable enhancement. I know Alan just implemented something similar for 'playlist play'.
Doesn't "playlist play" replace the whole current PL? Or did he implement a way to play an album from track X after all? THAT would be something I'm heavily interested in, too since right now I emulate this using two commands in one comet message.
Yeah it replaces the playlist. He added an index param so you could play+jump with one command instead of two. The change is here: http://svn.slimdevices.com/slim?view=revision&revision=29988
Can you add that to the CLI spec as well?
Oh, and I forgot the rationale for the request: I want to be able to drag-and-drop items to the current playlist.
Actually I added it to 'playlist playtracks' which is an undocumented synonym of 'playlist loadtracks' with a few extra parameters intended for internal use.
vote for this bug if you'd like to see it implemented!
This is a technical enhancement, don't think voting is going to work for this. I need this to implement drag'n'drop to the current playlist for iPeng for iPad. I believe it will be simple to implement but if it isn't coming, I'll probably find a workaround. That workaround will probably involve issuing several commands, put load on the server and suck, technically speaking, but it will work. If you implement it later, I will not care because it would mean branching making my code even more complex. The feature I want to do would make for a great enhancement for the user experience but so far nobody wanted to implement it (e.g. For the web UI -not that the feature hasn't been requested). So who's supposed to vote for this? End users will never use this, Logitech/SD developers don't need to vote if they need this. I believe we need a different process for cases like this. The question is: does it make technical sense and do you want to support the use case.
Joerg, this is a non-trivial enhancement. I would say that there is virtually no chance of this happening for 7.5, even if you were to supply the patch. Sorry.
OK, good to know. I had thought it might have been a simple change. Will try a workaround of "playlist add" and "playlist move" then.