mirror of
https://github.com/lox-audioserver/lox-audioserver.git
synced 2026-04-26 06:45:47 +03:00
[GH-ISSUE #77] Queue gets cleared when selecting a track from the queue #33
Labels
No labels
bug
enhancement
pull-request
released
released on @beta
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/lox-audioserver#33
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ds556 on GitHub (Nov 17, 2025).
Original GitHub issue: https://github.com/lox-audioserver/lox-audioserver/issues/77
When opening the queue and selecting a track, a new queue with a single track gets created instead of moving within the existing queue.
@rudyberends commented on GitHub (Nov 17, 2025):
This one is a bit tricky. The root cause is that the Loxone client does not differentiate between:
• selecting a track inside the queue, or
• selecting a track from the library, a playlist, an album, etc.
In both cases, the client sends a regular content-play command, for example:
audio/14/serviceplay/spotify/nouser/spotify:track:c3BvdGlmeTovL3RyYWNrLzFUbjMxd0RTWUdQeUZsS1JMTEZmcTk=/noshuffle/?q&ZW5mb3JjZVVzZXI9dHJ1ZQFrom this command alone it is impossible to determine whether the user actually clicked an item inside the queue (which should trigger a queue-seek), or clicked a track somewhere else in the UI (which should start a new playback session with a new queue).
Because the Loxone protocol provides no context, there is now a workaround in place:
1. When a content-play command comes in, it first checks whether the item already exists in the current queue.
2. If it does, it treats the action as a queue move and triggers a queue_seek.
3. If it does not, it treats it as a normal new playback request.
This workaround solves the original issue—queue navigation now behaves correctly—but it is not perfect.
If a user browses the library and happens to click a track that is also present in the queue, the system may incorrectly interpret this as a queue-seek instead of starting new playback.
Because the Loxone client offers no reliable way to distinguish these actions, this is currently the only practical approach.
@ds556 commented on GitHub (Nov 18, 2025):
Awesome! I wonder if the same limitation exists with the Loxone Audioserver.
@rudyberends commented on GitHub (Nov 18, 2025):
Great question. I tested this against public demo Miniservers, and our queue handling is 100% identical to a real Loxone Audioserver. You can also see the normal play action appear there in exactly the same way. That is indeed a bit odd.
From what I remember, the previous generation Loxone apps behaved differently — they actually used a dedicated queue command. The new clients no longer do this. The original implementation of this code was also based on NAS content emulation, while it now emulates a Spotify-style service. It’s very possible that the real Spotify backend used by Loxone handles this server-side and returns the proper queue together with the selected index. A real Spotify queue on a Loxone Audioserver also only exposes three items — previous, current, and next.
In any case, I’ve taken another look at the workaround and found a better solution.
When building the queue items, we no longer expose the original media URI. Instead, we now generate a synthetic URI in the format:
queue://<queue_item_id>The Loxone app now sends this back when the user selects a queue item. This gives us an explicit and unambiguous indicator that the action is a queue navigation event. We no longer need to scan the queue for a matching media item — we can simply pass queue://<item_id> straight through to Music Assistant as a proper queue-move command.
With this new implementation there are no false positives anymore, and the original problem is fully resolved.
I think this approach is stable and production-ready. Shall we close the issue?
@ds556 commented on GitHub (Nov 19, 2025):
Great, that makes a lot of sense! I can confirm it is now able to differentiate between moving to a track within a playlist and playing the very same track from the library (starting a new playlist).