Thanks for the swift reply and apologies for missing the reporting details. I will try to get these uploaded later today.
No logs or versions, just a question:
I had set Normalize Volume to off in mijj desktop cliënt. (under playback)
And I had to set the streaming quality to lossless using my desktop client ( it was on auto)
I was under the impression, these are user dependant settings.
Does this mean you could do something simular for “streaming quality”?
Or am I correct in asuming quality must be set with the desktop client?
PS: I noticed you also did the “crossfade button” in 0.8.8?
SJ
Hey @Sterke-Jerke,
Two different places.
Normalize and quality in the desktop app are that app’s playback settings. They are not written into Soloist on the Volumio box. Loudness normalization in the plugin is a separate write of the engine prefs on this speaker. Turning Normalize off on the PC does not turn the plugin switch off, and the other way around.
Streaming quality is not in the plugin. Soloist has no official switch for it. We do not write those prefs. The line you see in Volumio is a measurement of the file that already arrived, not a setting. To get Lossless on Connect you still enable it in the Spotify app. If it was on Auto on the desktop, setting it to Lossless there is the right place. I am not adding a Quality control for now.
Yes, 0.8.8 has Crossfade. GitHub only, store still 0.8.5. Off by default. Same unofficial prefs as loudness. If a later Soloist build ignores the keys, the button will still be there and the audio may not fade.
Kind Regards,
1 Like
Here is another attempt at reporting.
Streamer: ASRock N100DC-ITX – JCAT Femto USB card
DAC: JLsounds I2SoverUSB DAC input card
Version: Volumio 4.119 (Premium sub), Spotify Soloist 0.8.6
What happened:
Started playing a playlist from the Spotify app on my Android phone. After the first song, it failed to automatically advance to the second track of the playlist. Clicked ‘next track’ which moved the player to the next track. After another couple of tracks, it stalled again, failing to advance.
The log should be here:
http://logs.volumio.org/volumio/4Mm41P2.html
Hey @mogelsvs,
Thanks. That report is in the right form, and the log is enough.
This is Connect advancing Spotify’s own list. The plugin does not pick the next track. It waits for Soloist’s track_changed. In your capture that event arrives in about a second on some cuts (Clair de lune to The Swan, then later Gymnopédie and Fracture). On others Soloist stays on the same URI: buffering about 1 s before the end, then about 10 s later playing at that same place, no track_changed. That is the first track, The Swan, and the Brahms where the log stops. Next on the phone still works. That skip is a different path.
hold publish in the log is a hold so we do not republish the old title while it buffers. It does not wait those ten seconds and it does not abandon the cut.
I cannot send a next-track that Soloist did not emit. There is no plugin setting that waits for prefetch. Store 0.8.5 / GitHub 0.8.6 / 0.8.8 do not change this path.
If you have another capture, same verbose, one good cut and one stuck cut in the same session is enough. No need to edit env files.
Kind Regards,
Thanks @nerd - If there is anything else I can provide, just let me know.
Just an FYI. The same Android Spotify app has streamed to my RPI5 streamer all day, without pause.
Hi,
First off — thanks for the plugin, it’s been running really well here on two Volumio players.
One thing I keep worrying about is the 90-day expiry of the Soloist binary. From reading the code (0.8.8), the freshness check runs when the plugin starts: onStart, when settings are saved, and via the manual update button. That covers most people fine.
My setup is a bit of an edge case, though. Both boxes are on permanently. Most of the time they’re playing web radio, and Spotify Connect gets used now and then — but the plugin itself basically never restarts.
Would it be an option to have the plugin schedule the refresh instead of only checking at start? Something like a systemd timer that:
- from day 75 tries “softly” — skip the refresh while a device is actively playing, retry the next day;
- from day 85 goes ahead regardless, so an always-on player can’t keep postponing it past day 90.
Hey @Sterke-Jerke,
The hole is real. Freshness is only checked when the daemon is started (plugin start, a Save that restarts Soloist) or when you press Update. An always-on box that mostly plays radio never takes those paths. If the binary then exits 10, systemd will not restart it.
I will not add a timer that downloads on its own, and I will not force a pull while something is playing. We do not know what the next Spotify tarball contains.
What I am considering: a remaining-days notice and the Update button, so the box can tell you before day 90. An auto-update switch only if it exists, off by default, with that same warning. No extra systemd unit.
Available from 0.8.9 - cutting edge on GitHub. Store stays on 0.8.5.
Kind Regards,
1 Like
Dear Volumionauts,
Spotify Soloist Connect just grew up.
0.9.0 is in the store as stable. Same number on GitHub. The beta badge can go sit in a drawer.
Plugins → Music Services → Spotify Soloist Connect
Store plugin is armhf. x86 still takes the scenic route: GitHub (sparse clone or alsa_soloist_connect-main.zip). Uninstall the store plugin before that, or you get two plugins arguing over one DAC.
Thank you to everyone who installed this while it still said beta, sent a log instead of a vibe, and did not pretend Soloist was a finished Spotify product. And thank you @Wheaten, who tested this like the binary owed him money.
What you get now that 0.8.5 does not: it no longer steals AirPlay because the account is playing in the kitchen. Loudness and crossfade switches. An optional once-a-day Soloist refresh so a box that never reboots does not wake up dead on day 91. UI strings so the settings page is not a wall of TRANSLATE.
What has not changed, because honesty is cheaper than a second beta:
- Unofficial. Not Spotify. Bring your own API key.
- Their builds still expire after 90 days. Their decision. The Update button still reboots. The daily refresh is off until you ask for it. We still do not read their tarball.
- Loudness and crossfade are not a Soloist API. The switches write unofficial keys. A later build may shrug.
- Skip and volume can still take 1-3 s. That is their binary thinking.
- Queue playback is still a prototype and still off.
- The Tested table is still the 0.8.0 listens. We did not invent new Pass rows to look grown-up.
Opening post has the known issues and the long changelog: thread.
Kind Regards,
Rivo + version 0.9.0 missing from the store.