Respect Client's maxBitRate query param stream request

[OpenSrcerer]

Context

gonic version: v0.16.0
client: symfonium
if from docker, docker tag: 257089075b20

Issue

I was having a confusing time understand why my Symfonium client was using so much data, and in the process I found out that Gonic does not respect the maxBitRate setting of the client upon a stream request.

In #244 you state:

I think hopefully that shouldn't happen. gonic will skip a transcoded if
the source bitrate is less than the requested bitrate
the client requests a maxBitrate higher than the source nitrate
the client requests to not transcode

However, right now the behavior seems to be that the maxBitRate param is completely ignored, and the only setting that is respected is the "transcoding device settings" override that you set in the control panel.

I think respecting the param is a good thing to have because it allows users to select different bitrates client-side depending on factors such as WiFi connection status, or (come up with some creative idea here).

[sentriz]

hi it does respect it, you just need to enable transcoding on the gonic web interface

[OpenSrcerer]

Hi @sentriz thanks for the reply! Perhaps I'm confused, but you do mean this, right?

Wouldn't this force the client to use opus @ the bitrate you've provided on the wiki, so 96kb/s?

[sentriz]

without a maxbitrate yes it will default to 96kbps, however if the client instead says maxBitRate 50kbps, then it will be opus @ 50kbps

but it must be lower than the profile

so you could instead set the profile to opus 192, then the client can request anywhere from 0 to 192

if that makes sense 👀

in future i want clients to be able to pick their own profile too - but this will need an extension to the subsonic api

[OpenSrcerer]

Okay makes sense! Thanks for the explanation.

I'm not super well-versed in the new OpenSubsonic impl to really understand the reasons behind your necessity for the extensions, since the maxBitRate param already exists. However, Opus@192 & less is perfect for my usage so I'll call this issue closed on my end.