jmshrv / finamp

A Jellyfin music client for mobile
Mozilla Public License 2.0
1.83k stars 122 forks source link

[Feature Request] Disable transcoding on WiFi #44

Open persei8 opened 3 years ago

persei8 commented 3 years ago

It would be great to have full quality on WiFi and reduced bitrate when WiFi is not available.

jmshrv commented 3 years ago

That'll be a bit more complicated than your other request, but I should still be able to do it in either the next release or the one after that.

Extarys commented 3 years ago

I would agree, but I would like a whitelist of wifi instead of all wifis. As some people might be on a slow wifi connection. ie in rural areas and such.

Of course this could be implemented later.

Side note @UnicornsOnLSD : Just updated on fdroid, this version is dope! Thanks for your hard work <3 Like most, I really appreciate the time and effort you put into this

ieure commented 3 years ago

I was going to request this same feature! I'd really like to have full quality on my home WiFi, but lossy when I'm out, so I don't wreck my data plan.

Thank you for Finamp, I'm really enjoying it.

gaizaharduz commented 1 year ago

Just came here to express my desire for this feature, after accidentally using up my entire monthly mobile data cap listening to a couple of 24-bit 192khz tracks. Luckily it is nearly the end of the month. 😅

For those of us who hoard very high quality music files and like to listen to them that way at home (but most certainly not on the road) this would be extremely useful to avoid such mishaps.

phip123 commented 1 year ago

I'm assuming this is not yet in the app but it would be very nice to configure the transcoding for Wi-Fi and mobile data connections separately.

AlperShal commented 1 year ago

Just setup my Jellyfin server and both official app and Finamp is lacking this feature. It's interesting how such an important feature is not implemented yet.

jmshrv commented 1 year ago

A rudimentary solution for this could be made relatively easily - when creating the queue we can decide whether or not to transcode based on the WiFi status.

A nicer solution would be possible once https://github.com/ryanheise/just_audio/pull/779 lands - that'll do the check and generate the URL just before the track is played.

AlperShal commented 1 year ago

A rudimentary solution for this could be made relatively easily - when creating the queue we can decide whether or not to transcode based on the WiFi status.

A nicer solution would be possible once https://github.com/ryanheise/just_audio/pull/779 lands - that'll do the check and generate the URL just before the track is played.

My idea was to have a checkbox in the transcoding settings titled like: "Use transcoding only when on a metered connection", request access to operating system's location permission and everytime just before a transcoding event call happens check if this is enabled and if the device is connected to a metered connection. This looks like how more or less every application does this. Not sure about the efficiency but looks fine. If this was not what you have meant by "a nicer solution" wanted to mention this to give an idea.

jmshrv commented 1 year ago

Yeah that's how the nicer solution would work, although the OS lets you check whether Wi-Fi is connected without location, and I'm pretty sure you can also check if the connection is metered. The issue is that the current audio system wants a URL when creating the queue, which is when you click play on a playlist/album. Finamp uses two different URLs for transcoding and direct play. There might be a hacky way to change the URLs after the queue is made, but I'd be surprised.

AlperShal commented 1 year ago

Yeah that's how the nicer solution would work, although the OS lets you check whether Wi-Fi is connected without location, and I'm pretty sure you can also check if the connection is metered. The issue is that the current audio system wants a URL when creating the queue, which is when you click play on a playlist/album. Finamp uses two different URLs for transcoding and direct play. There might be a hacky way to change the URLs after the queue is made, but I'd be surprised.

I don't have any idea on how Finamp works so, sorry I can't help. But definitely waiting for the feature. You guys doing an awesome work.❤️

Also, is there any chance you guys can add more options to transcoding bitrate? Like 512, 768, 1024, 1512, 2048 etc. or just text input? 320 is looking pretty low knowing some people have files with bitrates even higher than 5120Kbps. I may create another issue for this if that's the proper way or is it impossible? (like limited with server-side options?)

Chaphasilor commented 11 months ago

@jmshrv How about we simply listen to changes in the network connection and then reload the queue? Biggest problem with that is probably that the buffer is cleared with results in unnecessary data usage, but it could be doable. I saw no easy way to update the AudioSource's URL after-the-fact.
Also it could happen that "reloading the queue" isn't as trivial as it sounds because of some audio_service strangeness...

jmshrv commented 9 months ago

We could do that, but there are scenarios where you switch from WiFi and mobile data multiple times, which would be pretty bad if we throw out the cache every time. I'm not sure if just_audio gives us enough control to do something like reload, while keeping the cache if we hace it.

Chaphasilor commented 9 months ago

I guess we have to wait for that MappingAudioSource to arrive, and then commit to transcode / don't transcode when we start fetching the song. Worst case you burn some of your data fetching one track untranscoded.

There also seems to be a userspace equivalent to the MappingAudioSource that we could use for now...

ha-ku commented 5 months ago

I also need this feature very much. Right now I have to keep switching the transcoding on and off manually. Or at least until automatic toggling of transcoding is implemented, put the transcoding switch in the sidebar for easier access?

Chaphasilor commented 5 months ago

@ha-ku It would probably be possible to implement this, but the new setting will only be used for new items added to the queue. Anything else will still use the old setting, as replacing the queue while it's playing causes some issues. I might try doing that again at some point, at least for the upcoming tracks.