Sonos queue management

Plugins & Plugin Development Sonos
1

I open a new topic to discuss about Sonos queue and how to manage it through the plugin.

Here is a copy of a short discussion from another topic:

[quote=“Jukka, post:8, topic:174113”]Hello lolodomo

Thanks for the information.

I managed to get it almost working doing like this:
RemoveAllTracksfromQueue
AddURIToQueue EnqueuedURI: file:///jffs/settings/savedqueues.rsq#2
(where #2 is the number of my saved “alarm playlist”)
EnqueueAsNext: 1
All other field=0
SetPlayMode NewPlayMode: Shuffle
Play (random track from my “Alarm Play list” starts to play)
… and after some time
Stop[/quote]

Fine, you have discovered how to manage the internal Sonos queue. 8)
I think we have to add a new parameter to PlayURI to be able to add to the queue, like you did manually if this is requested by the user.

Is it possible to save that queue which is removed from step 1 and restore it back when Play is stoped in the end of scene? I have not managed to do that, SavePlaybackContext and RestorePlaybackContex din't do that. This is not so important to me but I would like to know if it is possible.

Probably. I confirm that it is not yet handled by SavePlaybackContext and RestorePlaybackContex. I know how to get the content of the internal queue; I don’t know yet exactly how to restore this internal queue. Probably like you did, but adding each item individually including metadata…

2

I just played with callback AddURIToQueue and I have good news. This callback works perfectly with Sonos playlists (as Jukka already mentioned) and for x-cifs-files, either audio files (like MP3 file) or even playlist files (like M3U file). And the good news is that there is no need to provide metadata, they are automatically retrieved by the Sonos.

When the parameter EnqueueAsNext is set to true, the item(s) are added at the end of the queue.
When the parameter EnqueueAsNext is set to false, the item(s) are added starting at the position defined by the parameter DesiredFirstTrackNumberEnqueued. Using 0 for this parameter will result as adding items at the end of the queue (same result as setting EnqueueAsNext to true.

As a result, I should be able to add easily a simplified support for queue management [s]through two new parameters to the PlayURI callback. The first parameter will alow the user to choose between playing the file or only enqueuing it. The second parameter will ask what kind of enqueuing to do:

  • no enqueue
  • enqueue
  • replace queue[/s]
    And saving/restoring the queue should not be difficult.
3

Now my “Sonos alarm clock” is working fine. It is nice to wake up with different random track playing. And if you find how to save/restore previous queue then my “clock” is perfect.

By the way do you know how to use playlist names rather than those numbers (#2, see above). I didn?t find right way to do it.

And thanks again for great plugin… (I am using it daily)

4

Yes, of course, as I already mentioned, if one of your Sonos playlists is named “Morning playlist” for example, call PlayURI with “SQ:Morning playlist”.

5

The random play (shuffle) dosn’t work if I use PlayUri with “SQ:Morning playlist”. It starts form the first track.

I have to load the play list first to queue using AddURIToQueue and change the playmode to Shuffle and after that start the play with PlayURI “Q:”.

My question was how to replace file:///jffs/settings/savedqueues.rsq#2 with play list name.

6

New version committed (in trunk):

  • Queue management: new callback EnqueueURI + new parameter EnqueueType for callback PlayURI
  • Callbacks SavePlaybackContext and RestorePlaybackContext now respectively saves and restores the Sonos queue

You can enqueue 3 kinds of things:

  • an audio file (x-file-cifs)
  • a playlist file (x-file-cifs) containign audio files
  • a Sonos playlist
7

[quote=“Jukka, post:5, topic:174463”]The random play (shuffle) dosn’t work if I use PlayUri with “SQ:Morning playlist”. It starts form the first track.

I have to load the play list first to queue using AddURIToQueue and change the playmode to Shuffle and after that start the play with PlayURI “Q:”.[/quote]

It is now possible with the new version I just committed.
1- first active shuffle on the queue => the shuffle mode is restored even if you switch to a radio and then return back to the queue.
2- Now call PlayURI with “SQ:Morning playlist” setting EnqueueType to “REPLACE_ENQUEUE”. Doing that, your playlist will be inserted (replaced) in your Sonos queue and so the shuffle mode is now usable.

My question was how to replace file:///jffs/settings/savedqueues.rsq#2 with play list name.

It is not possible (or I don’t know).

8

In a future version, I will:

  • propose a new enqueue type: ENQUEUE_PLAY_NEXT to have the same behaviour as the menu item “Play Next” of the Sonos control application
  • enhance the UI of the plugin to be able using the new queue feature
9

I installed your new version (truck 106) and changed my test scene according to your instructions above… all worked, thanks for the modifications. Also queue save and restore works.

The plugin is now much better. It is also much easier to do my wake up scene (less steps needed) and I can use true play list names (“happy user” here :D).

10

New version committed (in trunk):

  • New allowed values as EnqueueType for PlayURI and EnqueueURI: ENQUEUE_AT_FIRST, ENQUEUE_AT_NEXT_PLAY and CLEAR_QUEUE

The parameter EnqueueType for PlayURI and EnqueueURI can take one of these values (string):

  • NO_ENQUEUE: the URI is not enqueued
  • ENQUEUE: the URI is enqueued (at the end)
  • ENQUEUE_AT_FIRST: the URI is inserted at first place in the queue
  • ENQUEUE_AT_NEXT_PLAY: the URI is inserted just after the item in the queue being played; if no item is being played, the URI is enqueued at the end
  • REPLACE_QUEUE: the queue is first erased and then the URI is enqueued
    - CLEAR_QUEUE: the queue is cleared and the URI is not enqueued
11

Remains now UI to enhance to have full queue management. But queue can now already be managed easily in scenes.

12

Hello lolodomo

I loaded trunck-107 files (I_Sonos1.xml and S_Sonos1-xml) to my Vera. After that REPLACE_QUEUE is not working any more (files are not loaded to queue>therefore no Shuffle play). So I reverted pack to trunk-106 files and now it is working again. So there must be something “wrong” on those two trunck-107 files.

13

I checked again and it works well for me.
I have attached the scene I am using for testing.

Please try again with the files from the ZIP archive.

Or give me more details how you have doing things.

14

I tested it again… and now it is working, so I am very sorry for wrong information. Maybe I did something wrong last night when I loaded the files to my Vera, maybe I forgot to tag the restar Luup after upload (it was midnight when I did it).

(I will make a new test tomorrow morning to be sure that I made it right now)

(I am using exact the same test scene as you, only difference is the play list name)

15

Morning test is done… and it is working. I don’t know what went wrong first time when I upload files to Vera. I am quite sure that I tagged the restart Luup after upload…

So thanks for that extra test and for your help…

16

I discovered a little bug: “CLEAR_QUEUE” should work even if the URI is not provided.
Will be fixed later.

17

[quote=“lolodomo, post:16, topic:174463”]I discovered a little bug: “CLEAR_QUEUE” should work even if the URI is not provided.
Will be fixed later.[/quote]

“CLEAR_QUEUE” type has now been suppressed.
RemoveAllTracksFromQueue callback can be easily used for the same result.

18

New changes have been done (in the trunk): http://forum.micasaverde.com/index.php/topic,8505.msg104965.html#msg104965

To enqueue (and play) a URI, you must now use EnqueueURI. PlayURI is only for playing without enqueuing.

Note that action name or parameters names could change again.

19

Using qobuz service, I discovered a bug relative to the queue restore.
qobuz is using the queue.
When restoring the queue (for example when using action Say or Alert actions), nothing is lost and the queue is resumed but all information on the queue items are lost.
I will provide a fix later.

20

For information, parameters EnqueuedURIs and EnqueuedURIsMetaData for action AddMultipleURIsToQueue are list of values separated by a blank (space).

For the restore of the queue, I will probably replace the use of multiple calls of action AddURIToQueue by a unique call to action AddMultipleURIsToQueue. It will be more efficient I imagine.