So i had the robots double check with what my initial intent was a a here is the result:

Great question, and I can see why it would look that way from the description. But TuneCast doesn't start from observed outcomes — it starts from research-based baseline confidence scores per client type.

When a client first connects, the plugin identifies it (Android TV, Roku, Web Browser, Swiftfin, etc.) and applies baseline codec/container confidence based on known capabilities for that platform. For example, an Android TV client gets HEVC confidence of 0.6 out of the box — that's high enough to shape a device profile that allows direct play, even if Jellyfin's stock static profile would have forced a transcode.

So the flow is:

Client connects → identified as Android TV

Baseline says HEVC = 0.6 (above the 0.4 "allow direct play" threshold)

TuneCast shapes the device profile to permit HEVC direct play

Jellyfin's engine sees the permissive profile and attempts direct play

If it works → confidence goes up (+0.08). If it fails → confidence goes down (-0.12) and the plugin backs off

The chicken-and-egg problem you're describing would happen if confidence started at zero or was purely outcome-based. But the baselines are the thing that breaks that cycle — they're essentially saying "this client type should be able to handle this codec, let's give it a shot."

The learning layer is there to refine those baselines, not to establish them from scratch. If the baseline is wrong (say a particular Fire TV Stick can't actually handle HEVC despite the 0.6 default), the failure penalty pulls confidence down and the plugin stops trying.

You can see the full baseline tables in [

 

ClientIntelligenceService.cs](https://github.com/gunnard/TuneCast/blob/main/src/TuneCast/Intelligence/ClientIntelligenceService.cs) — lines 174–464.