Handle "estimateContentLength" on stream endpoint in subsonic api

[thelinkin3000]

Hi!

I noticed LMS doesn't handle the "estimateContentLength" parameter on the stream endpoint while using the subsonic api.

The reference for the endpoint is here http://subsonic.org/pages/api.jsp#stream

The handling of this parameter is useful for players such as VLC. Wihtout the Content-Length HTTP header set to some reasonable value, VLC does not report a current position while playing, thus the client can't report the current position nor seek to a desired position.

Note that this only happens when transcoding. If I disable transcoding on the server the error goes away and VLC reports position as expected.

[epoupon]

Hello,

Just tried this, and I am a bit puzzled:

• if we set a Content-Length header that is too small, the produced file is truncated.
• if we set a Content-Length header that is too big, we have to pad with 0 to satisfy clients, and I am not sure it is always a good idea for audio formats (maybe that's fine for the output formats supported by lms, will have to check)
• but what about embedded metadata and pictures If we keep them while transcoding? It becomes quite tricky to calculate an accurate output size.

Do you know how other servers handle these problems?

[epoupon]

Some updates:

• setting a smaller value will make MP3 and Ogg/Opus correctly be detected and played by VLC (but truncated)
• setting a higher value (pad with 0) will make MP3 files show higher durations (but VLC stops playing at the end of the actual transcoded file). However for Ogg/Opus files the duration is not displayed.

[epoupon]

Well let's go for a basic guess for Content-Length for now...