# SELECT\_RENDERER API resets playback position to 0:00 when switching to UPnP renderer (Sonos)

**URL:** <http://support.symfonium.app/t/select-renderer-api-resets-playback-position-to-0-00-when-switching-to-upnp-renderer-sonos/15118>\
**Category:** Support\
**Tags:** fixed\
**Created:** [September 18, 2026, 5:47pm UTC](http://support.symfonium.app/t/select-renderer-api-resets-playback-position-to-0-00-when-switching-to-upnp-renderer-sonos/15118 "2026-09-18T17:47:23Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![stephan.lechthaler](http://support.symfonium.app/letter_avatar_proxy/v4/letter/s/838e76/32.png) [@stephan.lechthaler](http://support.symfonium.app/u/stephan.lechthaler)\
**Post date:** [September 18, 2026, 5:47pm UTC](http://support.symfonium.app/t/select-renderer-api-resets-playback-position-to-0-00-when-switching-to-upnp-renderer-sonos/15118/1 "2026-09-18T17:47:23Z")

</div>

### App version

Production

### Issue description

When switching renderers via the API’s SELECT\_RENDERER broadcast intent, the current playback position is reset to 0:00, even though the target renderer (Sonos, via UPnP) is successfully selected. This does not happen when switching renderers manually through the cast screen UI, where playback continues almost seamlessly (roughly half a second gap).

### Device type

Phone

### Media provider

Navidrome

### Steps to reproduce

Start playback on Local device renderer, let it play for a while so there’s a non-zero position.  
Send a broadcast intent: Action app.symfonium.api.SELECT\_RENDERER, extras TYPE=1 (UPnP Player), IDENTIFIER=.  
Observe: playback pauses, and the position briefly flashes the correct (previous) value, then resets to 0:00.  
For comparison: manually tapping the cast icon and selecting the same Sonos renderer from the UI preserves the position with only a brief (~0.5s) interruption.

I’ve isolated this specifically to the SELECT\_RENDERER call — it happens even without sending any follow-up MEDIA\_COMMAND/play intent afterward.

### Additional information

Triggered externally via MacroDroid (Send Intent action, target Broadcast Receiver), not via Tasker, but this shouldn’t matter since it’s the same broadcast receiver.  
Tested with both a 2-second and a 300ms delay before any follow-up action — same result, so this isn’t a timing issue on my end.  
Symfonium was in the foreground the whole time, so this shouldn’t be an audio focus issue.  
Renderer: Sonos, connected via UPnP (TYPE=1).

### I searched existing issues first

on

### I understand that logs are mandatory

on

### Log upload name / description

stephan.lechthaler

---

<div class="post-metadata">

**Author:** ![stephan.lechthaler](http://support.symfonium.app/letter_avatar_proxy/v4/letter/s/838e76/32.png) [@stephan.lechthaler](http://support.symfonium.app/u/stephan.lechthaler)\
**Post date:** [September 20, 2026, 8:01am UTC](http://support.symfonium.app/t/select-renderer-api-resets-playback-position-to-0-00-when-switching-to-upnp-renderer-sonos/15118/2 "2026-09-20T08:01:02Z")

</div>

**Update – narrowed down further:**

I did some more testing and the reset only happens on the **very first** renderer switch after (re)starting the Symfonium app – every subsequent switch within the same app session preserves the position seamlessly, regardless of which song is playing.

**Detailed reproduction:**

1. Fresh app start (force-stopped and reopened).
2. Play a song locally, let it run for a bit.
3. Send `SELECT_RENDERER` (TYPE=1, Sonos) → position resets to 0:00. _(matches original report)_
4. Switch playback back to Local renderer (TYPE=0), song plays fine.
5. Seek to a different position, or pick a **different** song entirely.
6. Send `SELECT_RENDERER` (TYPE=1, Sonos) again → this time playback continues **seamlessly** on Sonos, at the correct position, no reset.
7. Repeating steps 4–6 with different songs keeps working seamlessly, as long as the app process stays alive.
8. Force-stop and reopen Symfonium → the very next renderer switch resets to 0:00 again (back to step 3), then subsequent switches are fine again.

This strongly suggests it’s not about the song, the UPnP URI, or Sonos itself, but about some renderer/session object being lazily initialized on the first `SELECT_RENDERER` call per app process, where the position handoff apparently gets dropped — while it works correctly once that object is already initialized.

Happy to provide more logs if useful, including one that specifically captures a fresh-app-start reset if the ones I uploaded earlier don’t cover that case.

---

<div class="post-metadata">

**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\
**Post date:** [October 2, 2026, 7:09pm UTC](http://support.symfonium.app/t/select-renderer-api-resets-playback-position-to-0-00-when-switching-to-upnp-renderer-sonos/15118/3 "2026-10-02T19:09:36Z")

</div>

Thanks will be fixed in next release.
