Fix DLNA players reporting a position that runs ahead of the audio

[marcelveldt]

What does this implement/fix?

A DLNA player could report a playback position that ran ahead of the audio, which since #5461 also propagates to any universal group it plays in.

A DLNA device never sends its position as an event, and the underlying library only re-stamps a position that actually changed. Two things went wrong with that:

• When a device reported that it started or resumed playing, the position refresh and the state update were kicked off at the same time, so the state update read the position from before the refresh had landed — the position of whatever played last, timestamped minutes or hours earlier.
• Right after a resume the device still reports the same position it had when it was paused, so the timestamp that comes with it still dates from the start of the pause. The whole paused period was then counted as playback time.

Resuming after a longer pause could therefore report a position far past the real one, which can make the queue skip the rest of the track.

Related issue (if applicable):

• follow-up to Stop confusing an unknown DLNA position or volume with zero #5469

Changes

• Refresh the device state before reporting a start or resume, instead of alongside it.
• Never anchor a position earlier than the moment playback started.
• Tests for both cases.

Types of changes

• Bugfix (non-breaking change which fixes an issue) — bugfix
• New feature (non-breaking change which adds functionality) — new-feature
• Enhancement to an existing feature — enhancement
• New music/player/metadata/plugin provider — new-provider
• Breaking change (fix or feature that would cause existing functionality to not work as expected) — breaking-change
• Refactor (no behaviour change) — refactor
• Documentation only — documentation
• Maintenance / chore — maintenance
• CI / workflow change — ci
• Dependencies bump — dependencies

Checklist

• The code change is tested and works locally.
• pre-commit run --all-files passes.
• pytest passes, and tests have been added/updated under tests/ where applicable.
• For changes to shared models, the companion PR in music-assistant/models is linked.
• For changes affecting the UI, the companion PR in music-assistant/frontend is linked.
• I have read and complied with the project's AI Policy for any AI-assisted contributions.
• I have raised a PR against the documentation repository targeting the main or beta branch as appropriate.

[Copilot]

Pull request overview

This PR fixes DLNA playback position anchoring so reported elapsed time no longer runs ahead of actual audio after start/resume events, preventing incorrect queue behavior (including universal group propagation).

Changes:

• Serialize “start/resume/pause” event handling by polling device state before reading/reporting position.
• Clamp the position timestamp anchor so it never predates the moment playback resumed.
• Add regression tests covering both the resume-timestamp case and the event-ordering case.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
music_assistant/providers/dlna/player.py	Tracks observed PLAYING transitions to clamp position anchoring; ensures AVTransport TransportState events poll before state/position reporting.
tests/providers/dlna/test_device_state.py	Adds tests for resume anchoring and for polling-before-read on TransportState events.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.