Duration and seeking with transcoded streams: some measurements against Navidrome, and a few questions

[aarizaga90]

Hi! I've been trying to understand why song duration shows as --:-- and seeking is unavailable when streaming with transcoding (reported in #725 and as Problem 3 in #672), and I ran some measurements against my own server. I'm not an iOS developer and I don't know the Amperfy codebase, so I'm posting this as data and questions rather than as a diagnosis. The tests were put together with AI assistance, so please sanity-check anything that looks off — I'm happy to re-run or adjust them.

Setup: Navidrome 0.64.0, MP3 streaming format, uncached tracks (I varied maxBitRate on each request to avoid the transcoding cache), sources in FLAC, M4A and MP3.

What I measured

1. No byte ranges on an uncached transcode

Range: bytes=0-50000  →  HTTP/1.1 200 OK, Accept-Ranges: none

2. No Xing/Info header in the transcoded MP3

Across 15 samples (3 source formats × 5 bitrates) the first 8 KB always contained LAME and ID3, never Xing or Info.

3. estimateContentLength=true returns a Content-Length that is consistently ~2.3% larger than what is delivered

source   bitrate   declared     delivered    difference
FLAC     128       3,686,563    3,600,986    +85,577
FLAC     192       5,529,845    5,401,370    +128,475
M4A      192       7,036,846    6,874,060    +162,786
MP3      256       7,713,259    7,533,254    +180,005

The declared figure matches duration × bitrate × 1024 / 8, the delivered one duration × bitrate × 1000 / 8. No audio was missing in any of these — measured duration always matched the track. (I did see truncation, but only when requesting non-standard bitrates such as 179, which I don't think any client does.)

4. timeOffset works, and accurately

My server advertises transcodeOffset v1 via getOpenSubsonicExtensions. On a 257 s track, &timeOffset=60 returned a stream measuring 197.5 s with ffprobe.

https://opensubsonic.netlify.app/docs/extensions/transcodeoffset/

My questions

1. Would it make sense for Amperfy to take the track duration from the song metadata already returned by the API, rather than from the stream? Or is that already the case and something else prevents it from being shown?
2. Has seeking via timeOffset (re-opening the stream at the requested position when the server advertises transcodeOffset) been considered? I don't know how well that fits AudioStreaming's model.
3. Is the ~2.3% discrepancy in point 3 something that would matter to the player, or is it harmless?

I'm aware this has been discussed before (#305 has a lot of analysis) and that there may be good reasons these routes were not taken — I'd genuinely like to know. Happy to run further tests against my server if that helps.

Environment: Amperfy 2.1.1 (build 22), iPhone 16 Pro on iOS 27.0, Navidrome 0.64.0.

Thanks a lot for the app — it's what I use every day.