UPnP cast: played ratio uses a stale duration → shorter tracks are not scrobbled and get a bogus bookmark

Support
1

App version

Production

Issue description

Hello.

While diagnosing some casting issues I noticed that some of the songs playing weren’t getting scrobbled.

I run a log through Claude to try and sort out this and another issue (which was solved going from the beta 2 of version 15 to the 15.1.0 release), and it picked up the UPnP played ratio issue.

It seems like the played ratio for all songs played in a session is being computed based on a fixed total duration, I assume based on the first song played.

I uploaded a log fragment showcasing the issue via the “secure file sharing” webpage, as the app displayed a “over 100mb” error.
The log is accompanied by a claude generated description for clarity.

Device type

Phone

Media provider

Navidrome

Steps to reproduce

  1. Connect Symfonium to a Subsonic/OpenSubsonic server (Navidrome 0.64.2 here) and enable debug logging.
  2. Select a UPnP/DLNA renderer as the output device (Denon AVR-X1800H here).
  3. Play an album or queue whose tracks have clearly different lengths, including some shorter than the first track (e.g. Ozric Tentacles – Strangeitude: 6:26, 7:32, 7:31, then 4:07).
  4. Let the queue play through on its own with gapless transitions, without seeking or skipping.
  5. After a track shorter than the reference duration has finished (here Bizarre Bazaar, 4:07), stop playback and export the log.
  6. Look for the MediaStateUpdater lines: the second value in [position-duration] stays the same for every track (374000) instead of matching each track’s real duration.
  7. Check the server: the shorter track has no scrobble, and it has a bookmark at its last second (createBookmark ... position=246000).

I searched existing issues first

on

I understand that logs are mandatory

on

Log upload name / description

UPnP played ratio using a fixed duration.log

2

Thanks for the detailed report. The log confirms that Bizarre Bazaar finishes but is evaluated against a stale 374-second duration, so it misses the played threshold and receives an end-of-track bookmark.

The likely cause is duration handling during gapless transitions. The fragment doesn’t show whether the receiver supplies missing or outdated timing, but the failure is confirmed and recorded for investigation.