Support timeOffset for audio too

Type of change

  • API tweak

Proposal description

Opus is a way better codec than MP3 for streaming and transcoding. Unfortunately ffmpeg and Subsonic solution with estimateContentLength does not work very well for seeking and might generate issues.

Supporting timeOffset for audio files too would allow proper seeking via stream restart at the proper position and solve this issue.

Backward compatibility impact


API details

No change just support timeOffset for audio files.

Security impacts


Potential issues

Alternative solutions

Proposal status


Server implementation status

1 Like

BTW since the API did say it’s not supported I actually never tested on any server.

@deluan Does Navidrome support that already? (Transcoding breaks progress bar (Navidrome))

Navidrome supports the estimateContentLength, but as you already know this is not precise due to variable bitrate encoding. And ND currently doesn’t support the timeOffset.

What I do for the web player is set the duration of the song in the player, and support the HTTP range header. I also set the x-content-duration header in the response with the duration in seconds.

Unfortunately ExoPlayer have some issues with wrong values returned by estimateContentLength causing issues are the end of the songs so is not reliable enough to be used.

timeOffset would solve this as it’s supported by all other APIs but I guess I’ll have to wait and see how the extension goes :frowning:

The web player of LMS already uses a time offset to seek when transcoding is active, so it would be quite trivial to add. When no transcode is active, there is some more work to have enough precision but I think it would still be feasible.