How are we supposed to interact with play_file/dir playlists?

[davidbgk]

I'm still working on a web frontend and I wonder how I am supposed to reach the prev/next files and on a more general matter how I can retrieve the filenames from the currently playing directory?

I hacked a bit the next command using seek_forward 1h because it didn't look to be possible to jump to the next file but it's probably a bad idea(?).

I also retrieve the current playing file extracting it from get_uri at the moment but I wonder if I'm missing something in the logic and it doesn't allow me to get the directory/album currently playing.

Reading the code, the server doesn't look to keep a reference to the current playing dir.

My hope was digging into the interaction_manager to learn how to do it but the NEXT command is actually stopping the speaker?

It's starting to take shape!

[pwt]

Moving this to discussions.

[davidbgk]

Since then, I found that you can call track but the returned value from the API is a string that requires parsing. Maybe a more usable format from JS would be pertinent? I can create a dedicated issue for this, this is the only action calling pretty_print_values so the adaptation should not be that costly.

[davidbgk]

Mmh this is not that trivial considering how run_command captures the output.

[pwt]

I'll be away for a bit, so can't do much on this for a while.

The files played by play_dir obviously don't appear in the Sonos queue, the same as for playlist files:

This feature works by invoking the play_file action for each file in the playlist in sequence, so the same rules apply as for play_file. Note that play_m3u does not create a Sonos queue on the speaker -- the 'queue' is managed locally by SoCo-CLI -- so it's not possible to skip forward or back using a Sonos app.

I think the option of seeking to end of the currently playing track is probably fine/safe, as a way of forcing play_dir to move to the next track in the list.

Since then, I found that you can call track but the returned value from the API is a string that requires parsing. Maybe a more usable format from JS would be pertinent? I can create a dedicated issue for this, this is the only action calling pretty_print_values so the adaptation should not be that costly.

As you've noted, the output of run_command is oriented towards command line use, so the return values are what would be displayed in a terminal. It's not trivial to change this -- long-standing design choice made when SoCo-CLI was much simpler! I think you're stuck with parsing for now.

I think it's possible to add some kind of get_tracks_in_dir action that returns the list of playable audio files in the supplied directory, if that would help?

[davidbgk]

I think you're stuck with parsing for now.

Alright 👍

I think it's possible to add some kind of get_tracks_in_dir action that returns the list of playable audio files in the supplied directory, if that would help?

That would definitely help 🙇

[pwt]

Version 0.4.79 adds a /list_audio_files/{directory_name} path to the HTTP API server that returns a simple list of strings, which are the filenames of the audio files found in the top level of the supplied directory.

I haven't documented this because I need to think about how it 'fits' within the overall structure.

[davidbgk]

I understand, thank you so much! I'll play with it and provide feedback.

For my usage, I'll probably have to match the list with the result of get_uri to know from where we are currently playing the list. Maybe it helps sculpting the big picture :)