When seeking on the now playing screen track restarts regardless of position on the progress bar

Issue description:

On the now playing screen, when scrubbing the progress bar anywhere on the on the line, the songs audio restarts from the beginning regardless of where the progress bar is. ALTHOUGH, changing either of these settings fixes the issue:

  • Playback cache size: 256MB>None, (Original value>New value)
  • Maximum bitrate (Cell, or Wifi): Anything but Original>Original


debug-20230605_151036.zip (12.3 KB)
debug-20230605_151102.zip (843 Bytes)


Additional information:

I hope that the screenshot made it more clear what I was referencing. I was having difficulty describing it clearly. To clarify, I mean moving the vertical bar that shows the progress along the horizontal line left or right, not pressing the buttons to skip ahead some time.

This is pulling from: Jellyfin 10.8.10
My server OS is Ubuntu 22.04 LTS
Symfonium version is v5.4.0 (1008)

So you’ve reached one of the edge case here.

When transcoding to opus it’s not possible to seek, the proper way is to restart the transcoding at the new seek point. This works well by itself.

Now when you enable playback cache the app caches media but since there can be missing gaps in the file it’s not really possible to know if a file is 100% cached or not. This is also not an issue in normal usage.

Now when you mixes the 2 there’s a choice to be made:

  • Either priorise the cached data and so broken seek in some cases. This is current choice as it ensure no extra cellular usage that could be unwanted.
  • Or priorise the seek, meaning the the previous cache can’t be reused (unless seeking to an exact same point already seeked to) so more cellular data used.

I think current default choice is the proper one for most users. But if there’s enough up votes / comments here I might add an option to priorise seek.

1 Like

I understand. I assume that option 1 would be the most popular usage. I’m just curious though, my server supports transcoding on it’s own through navidrome, is there something preventing the app from asking it to transcode on its end so that that app only caches the transcoded file?

Apologies if this is an overly ignorant question.

There’s a difference between offline cache that are controlled and can be seek even when transcoded and playback cache.

The playback cache cache during playback and pre cache the next songs, but it does cache at block levels not file so that you can play the media even if it’s not fully cached to avoid long delays.

Navidrome is Subsonic and currently Subsonic does not support setting the offset point to seek properly during transcode.
If OpenSubsonic does not move fast enough I think I’ll ask @deluan to support it before the global vote because it’s an highly requested stuff.

1 Like

That would be awesome if you’d be able to talk with them. I’m definitely in support of this feature as well.