SBDeveloper/medley

Watch

Fork 0

Remote control of a Paired Device #51

New issue

Open

opened 2026-10-12 22:19:02 +02:00 by SBDeveloper · 1 comment

SBDeveloper commented

2026-10-12 22:19:02 +02:00

Owner

Part of #49

Phase 2 of Handoff. Control playback on another Paired Device without a Handoff: play/pause, skip, seek, volume, view and edit its Queue, browse and start playback there.

Part of #49 Phase 2 of Handoff. Control playback on another Paired Device without a Handoff: play/pause, skip, seek, volume, view and edit its Queue, browse and start playback there. - [ ] #55 - [ ] #56

SBDeveloper added the

needs-triage

label

2026-10-12 22:19:02 +02:00

SBDeveloper referenced this issue

2026-10-12 22:19:07 +02:00

Handoff between Devices #49

SBDeveloper added a new dependency

2026-10-12 22:19:07 +02:00

#50 Pairing and Handoff between Devices

SBDeveloper referenced this issue

2026-10-13 21:31:36 +02:00

Find handed-off Tracks in a Source's catalog by ISRC #53

SBDeveloper added the

enhancement

label

2026-10-13 21:32:47 +02:00

SBDeveloper commented

2026-10-13 21:34:43 +02:00

Author

Owner

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: Let a Paired Device operate another Paired Device's playback (play/pause, next/previous, seek, Medley's volume) without a Handoff.

Current behavior:
Paired Devices already see each other's playback through periodic Status messages (read-only). The only action one Device can cause on another is a Handoff, or "continue here" (TakeOver). There is no way to pause, skip, seek or change the volume of another Device.

Desired behavior:

From the Devices UI, a Paired Device that is online and has a current Track shows transport controls: play/pause, next, previous, seek, and Medley's own volume.
Commands go over the existing authenticated Pairing connection and apply on the target as if the user had done them there (including MPRIS/notifications, since they use the same player path).
The controlling Device does not predict the result: it shows what the target reports in its next Status. A refused or failed command surfaces as a short error, and the UI keeps showing the target's real state.
Offline Devices, and idle ones with no Queue, have controls disabled. Commands are never queued for later. An idle Device can still be handed playback ("continue here").
Volume is Medley's own player volume on the target, never the system mixer.
Symmetric: any Paired Device can control any other. A Device that is not Paired cannot send commands. Two controllers: last command wins.
Follows ADR 0010 and the glossary term Remote control.

Key interfaces:

Devices wire Message enum: new command message(s) and a reply carrying success or error, accepted only from Paired Devices, like Handoff messages.
Core API and Tauri commands/events: a way for the UI to send a command to a Paired Device by id, using the existing Device status stream for feedback.
Player: reuse the same entry points the local UI uses for transport and volume.
UI: controls on a Device card in the Devices view, disabled per the offline/idle rules.

Acceptance criteria:

A Paired Device sends pause/play, next, previous, seek and volume, and the target's player state changes accordingly (integration test with two Cores).
A command from a Device that is not Paired is refused and has no effect.
Commands to an offline Device or one with no Queue are rejected and not stored for later.
The controlling UI updates from the target's Status, not optimistically.
Volume changes only Medley's player volume on the target.
Controlling works in both directions between the same two Devices.
Command and error messages are covered by wire-level tests like the Handoff ones.

Out of scope:

Viewing or editing the other Device's Queue (child issue).
Browsing a Library/Catalog and starting playback on the other Device (child issue).
Per-Device permissions or per-command consent (see ADR 0010).
System volume, queued/offline commands, optimistic UI.
A Device streaming audio to another (#52).

> *This was generated by AI during triage.* ## Agent Brief **Category:** enhancement **Summary:** Let a Paired Device operate another Paired Device's playback (play/pause, next/previous, seek, Medley's volume) without a Handoff. **Current behavior:** Paired Devices already see each other's playback through periodic `Status` messages (read-only). The only action one Device can cause on another is a Handoff, or "continue here" (`TakeOver`). There is no way to pause, skip, seek or change the volume of another Device. **Desired behavior:** - From the Devices UI, a Paired Device that is online and has a current Track shows transport controls: play/pause, next, previous, seek, and Medley's own volume. - Commands go over the existing authenticated Pairing connection and apply on the target as if the user had done them there (including MPRIS/notifications, since they use the same player path). - The controlling Device does not predict the result: it shows what the target reports in its next `Status`. A refused or failed command surfaces as a short error, and the UI keeps showing the target's real state. - Offline Devices, and idle ones with no Queue, have controls disabled. Commands are never queued for later. An idle Device can still be handed playback ("continue here"). - Volume is Medley's own player volume on the target, never the system mixer. - Symmetric: any Paired Device can control any other. A Device that is not Paired cannot send commands. Two controllers: last command wins. - Follows ADR 0010 and the glossary term **Remote control**. **Key interfaces:** - Devices wire `Message` enum: new command message(s) and a reply carrying success or error, accepted only from Paired Devices, like Handoff messages. - `Core` API and Tauri commands/events: a way for the UI to send a command to a Paired Device by id, using the existing Device status stream for feedback. - Player: reuse the same entry points the local UI uses for transport and volume. - UI: controls on a Device card in the Devices view, disabled per the offline/idle rules. **Acceptance criteria:** - [ ] A Paired Device sends pause/play, next, previous, seek and volume, and the target's player state changes accordingly (integration test with two `Core`s). - [ ] A command from a Device that is not Paired is refused and has no effect. - [ ] Commands to an offline Device or one with no Queue are rejected and not stored for later. - [ ] The controlling UI updates from the target's `Status`, not optimistically. - [ ] Volume changes only Medley's player volume on the target. - [ ] Controlling works in both directions between the same two Devices. - [ ] Command and error messages are covered by wire-level tests like the Handoff ones. **Out of scope:** - Viewing or editing the other Device's Queue (child issue). - Browsing a Library/Catalog and starting playback on the other Device (child issue). - Per-Device permissions or per-command consent (see ADR 0010). - System volume, queued/offline commands, optimistic UI. - A Device streaming audio to another (#52).

SBDeveloper added

ready-for-agent

and removed

needs-triage

labels

2026-10-13 21:34:43 +02:00

SBDeveloper referenced this issue

2026-10-13 21:34:44 +02:00

View and edit another Device's Queue (Remote control) #55

SBDeveloper referenced this issue

2026-10-13 21:34:45 +02:00

Browse and start playback on another Device (Remote control) #56