[Redesign] Transcoding configuration improvments

[Komodo5197]

This is an experimental attempt to redo the transcode configuration. It allows multiple transcoding configs to be set up for different scenarios. The currently enabled scenarios are the global config, a toggalable override that disables the autoswitch and could also be added to the player track menu if desired, when on cellular data, and when using the remote url. These scenarios select from a customizable set of transcoding configs with a few presets. If multiple configs apply to a situation, the lowest bitrate one is selected. I'm not sure if this whole customizable config thing is overbuilt, but I think android could have up to 6 different transcode scenarios, so it doesn't seem to crazy.

I have additionally put together some modifications to just_audio to add just-in-time resolvers so that we can choose the actual transcoding config only when buffering begins. This is android-only, although I should be able to also add it to windows/linux if it works out. Android additionally may be able to hot-swap local and remote urls mid song, but I haven't been able to test this, so it might just break playback. Just-in-time url resolution allows android to additionally support autotranscoding FLAC/very high bitrate files, and potentially auto-transcode of incompatible files if we can find a way to get or predict the supported codecs. This is awkward to do on other platforms because the codec info seems to only availible in the mediaStreams, and I don't want to slow down playback start even more with these large additions to the requests, so we don't know the codec until the metadata provider loads it just before playback starts. just_audio changes can be found here.

To support these changes, I've fully refactored network manager service. This PR also includes some of the fixes from #1603 due to how I ended up splitting the branches. In terms of testing, I've done a number of basic spot tests but I don't really have the setup to see how this behaves in the field, so any outside testing would be appreciated, especially of switching between remote and local urls across both direct and transcoded playback.

TODOs:

• Report actual transcoding/direct play status back to the metadataProvider.
• Migrate old transcode settings to new config
• Add transcode config edit screen
• Add support for auto-transcoding unsupported formats? (Android only)
• Maybe change setting to autotranscode any extra-high bitrate file instead of specifically flac
• Potentially unify the download and streaming transcode settings in some way?
• Clean up settings screen
• Lots of testing

[Chaphasilor]

@Komodo5197 finally dedicated some time to review PRs again, and then I see this 😁
Completely missed it before!

I've tried to merge the upstream changes in, maybe you can take a look at the critical parts to make sure I didn't mess up anything. I'll get this out for a bit and then report back!

[Chaphasilor]

Thanks. Could you give me a quick rundown of when to use getLocalized and when getLocalized2? Should we mark getLocalized2 as deprecated if its use is discouraged?
And I guess I should always be using context.l10n instead of the raw context?

[Komodo5197]

I actually ripped out the BuildContext version of the method in the home screen PR, leaving just the Applocalization method. You just accidentally reintoduced it in the merge. If you add a new localization method for a class, it should probably take an Applocalization instead of a BuildContext because that's what you can get out of GlobalSnackbar now.

[Chaphasilor]

Okay, here are my initial thoughts:

The current approach seems to be in line with what mainstream streaming apps are doing, which is probably a good idea. However, I'm not sure if it covers what we're trying to enable (more on that later).

1. Changing the transcoding settings should prompt a queue reload (or do it automatically, depending on the settings)
2. The queue should probably reload immediately when switching between different categories (wifi, cellular, etc.). I don't think anything is being triggered yet, neither a prompt, nor a reload. And the player screen also shows the old transcoding settings. Should this be working already? Is this handled transparently by your modifications to just_audio, or would that only apply the new profile starting with the next track?
3. If I select lossless transcoding, FLAC will be streamed, even for lossy sources. Can we make this smarter, or would you consider this to be out-of-scope for this PR? Basically, that would close Only transcode for higher bitrates #800 and Prevent Transcoding if below a certain bitrate #1023
4. If we stick with the separate categories + profile selector, we could take a similar approach to the home screen config, with a menu that offers a range of presets, but also a option to create a custom config? The main limitation of the current state of the PR is that it doesn't allow selecting specific bitrates and codecs anymore, which would be a breaking change and a net-loss I think. For example, I usually stream OPUS@96kbps, which is plenty for listening on my commute. But at the same time, creating too many presets probably isn't a great idea either, so this should be a good middle ground?
5. We're currently missing a category for when Data Saver is active or the device is on a metered wifi network. These could probably share the same config, but I think they'd be very handy to have.
6. What was the idea behind the manual transcoding config? If it's there to allow having one single setting for everything, then maybe there should be some toggle or mode switcher right above/below the default config ("always use this profile", or "simple" vs "fine-grained" switcher).
7. For the categories, we might want a slightly different selection, for specific use cases? For example, right now we have the FLAC category, and the cellular category. But the FLAC category should probably be "hifi" audio (very high bitrate or lossless), and then we might want to combine that with the cellular category, so that only hifi files are transcoded when on cellular data, and otherwise the original files are played, to avoid excessive data usage. The current categories only allow always transcoding on cellular, or always transcoding flac files (even when connected to the server via the LAN). I think this is where I see the issue with the category-based UI, it doesn't really allow mixing & matching different conditions. So how about approaching this similarly to the filter UI, where it's possible to select different conditions (filters), like cellular, data saver, hifi source, local network, etc? Would be mostly the same, but allow combining multiple conditions. And then instead of providing a fixed amount of configs, people could create as many or as little configs as they need. So all in all the UI would actually be very similar to the home screen section settings, which might be easier to maintain too?

Also, not sure if you've seen it, but there's a thread on Discord with some discussion and UI mockups (the concept is similar to the current state of this PR): https://discord.com/channels/1064474779043770408/1418343238657511495/1436103367255527656
There's also a partial implementation for it, but I think your PR is way past this already: https://github.com/brumik/finamp/tree/brumik-transcoding

CC @brumik, you might be interested in this discussion too :)

[Komodo5197]

1/2. The just_audio changes should be transparently adjusting things without a queue reload on Android. On other platforms you should still get the existing prompts. The player screen data is basically not implemented yet, so you can ignore what is says there.
3. If you select lossless transcoding for a situation, I would expect it to always fire. There is the flac transcoding situation, which I have been considering changing to a bitrate cutoff. The real annoying thing is that we don't have either codec or size information until the metadata provider loads, which means I'm not sure if per-track transcodes will really be useful outside android due to all the queue reloads.
4. That's basically my plan, and the settings data is set up like the home sections to allow this. The edit screen just isn't implemented yet.
5. That makes sense, and should probably be doable.
6. It was mostly just to maintain the current ability to force a certain transcode profile at will, for unusual situations. There was also a PR somewhere adding a transcode switch button to the player menu, which doesn't seem that crazy and would need something like this. This would allow easy manual handling of incompatible files we fail to detect and things like that.
7. I did decide at some point that a bandwidth cutoff is better than specifically transcoding lossless, so I agree with that. Regarding the mixing, that does seem to be a good point. If we had configs with variable filters like that, would it still be worth keeping the custom named format/bitrate configs? I'm thinking just letting you choose original/lossless/high/low/custom on the filter config bundle would be good enough.

I'll note my biggest concern with all of this is the back end of actually implementing transcode switching. I don't think the current queue switching is actually a good enough strategy for a lot of these more complex or just-in-time changes to be worthwhile, especially because a lot of them are focused on data saving and queue reloads waste data every time. I was messing around with just_audio and got just-in-time resolving working pretty well on Android, but that still leaves out the other platforms. I think the only properly cross-platform solution is to start routing everything through just_audio's localhost proxy, but that seems to come with a separate can of worms.

[Chaphasilor]

• For the lossless setting, we should just check that Jellyfin doesn't artificially balloon up the file size when streaming lossy files as FLAC, but otherwise this seems fine
• I can't come up with a scenario where manually overriding transcoding settings would be needed, aside from compatibility issues for certain tracks. It would of course be nice to handle compatibility automatically, but that might be hard, as you've noted. Aside from that, I like the way Qobuz handles this, where they have a setting on the player screen, but that just opens the transcoding/quality profile menu:

2026-07-01-16-13-29.mp4

It's not ideal (I'd highlight the currently-applied profile somehow), but I do think directly customizing the config for the current scenario makes more sense than completely overriding all profiles.

As for the format+bitrate profile names, I see no reason not to keep them. I'd defer you to the design mockup in Discord for how it could look. Of course we could hide it, but I don't think offering transparency hurts here.

And when it comes to reloading, I guess we could try replacing upcoming tracks in the queue before they are prefetched, by letting the metadata provider look ahead further. That should be a fairly minimal data overhead, and not require an interruption in most cases.
And if people really want to apply new settings immediately, we still have the reload prompts. It's also worth noting that wasting data is probably fine as long as we're connected to unmetered WiFi.

[Chaphasilor]

@Komodo5197 since you added a todo for "lots of testing", should we try to get this into the next update to have people test this before the stable release, or would you rather delay it and introduce it after the move to stable?

[Komodo5197]

I wasn't planning for this to get in before stable. There's too much left to do, I still haven't fully decided on what I might want to do for non-android platforms, and I'm busy with the other PR.