because this thread existed before yours and it’s been deemed a “feature request” and not a “bug”.
i’ve been beating the wall about this for some time with it mostly falling on deaf ears.
my advice? use the native jellyin app on mobile devices (it’s more than adequate). i only use Infuse on tvOS and use Jellyfin app on iOS/iPadOS for the remote bandwidth features.
The title of this thread is not the same thing. I don’t want to support the remote bandwidth features, I simply want the bug fixed where the incorrect API is being used.
Jellyfin app doesn’t support Atmos.
it’s the same, as the remote bandwidth isn’t working also because the wrong API is being used.
Can you change the title to reflect that the incorrect API is being used to prevent the confusion the devs had above that this is a request for transcoding?
the title was already changed by the mods here from what it was originally.
however, i wouldn’t hold any breath on seeing anything happen about this. seems there is no interest to resolve there jellyfin issues.
As far as I understand, Infuse supports playback of many different video and audio formats, and many of those being behind the paywall - meaning the source of income for Firecore team. That is for sure one way to do it, I have no problems with this. However, supporting remote transcoding would be somewhat like shooting yourself in the foot, right? I see this as the only possible reason to deliberately use “wrong” endpoint. And, if you think about it twice, then you understand it is not the wrong endpoint at all.
explain why you think that? as it’s non-sensical to me
i’ve thought it about 4 times and still don’t understand the point you’re trying to make.
jellyfin devs have confirmed the wrong end point is being used for playback.
If you got large library with whole bunch of different video formats, chance is that you won’t be able to play many of those without paying for Infuse Pro, one way or another.
However, if transcoding is available, Jellyfin would be sending all the videos in format supported by free Infuse, and then Firecore loses potential income.
That is how I see it. How else would you explain this pointless thread? How complicated is for devs to confirm the endpoint that was asked for numerous times here? I reckon it takes a minute, or two.
Infuse does not currently support transcoding or remote access limits. This is not something that was done with the intent to extract more revenue from users, but simply due to the fact that the integration method currently used is the simplest and most reliable.
I understand there are some who would like to see more advanced controls and/or transcoding options added to Infuse and these are things we may consider for a future update if there is enough interest.
If you are interested in seeing either of these things added to Infuse I would encourage you to ‘like’ the first post in the relevant suggestion thread to show your support. This is very helpful for us when it comes to determining which features to work on next. Thanks!
this is not what people are asking for though.
jellyfin server handles it based on whether the playback is local or remote.
Infuse, in direct mode, is reporting that playback is local all the time, even when it’s remote.
this is the issue, and jellyfin dev advise it’s because you are using the wrong API/
again, we are not asking for infuse the support transcoding within the app itself, we are simply asking for infuse to use the correc API so that the server can see if playback is remote, and the server itself applies the bitrate limit at server-side.
you have totally gone down the wrong road, and you’ve totally misunderstood the thread topic.
this has nothing to do with infuse pro or loss of income.
I want to add my experiences here (and upvote the desire to have a fix or at least an option in Jellyfin server config here).
Infuse on a remote client does not have the bandwidth limits applied in Jellyfin. It does show up in the Jellyfin dashboard as if it’s playing the file directly. This is with global or per user bandwidth limits applied in Jellyfin. I also tried “on network” IP ranges over a VPN and saw the same thing whether specifying that subnet as local or remote. In each config I confirmed the native Jellyfin web client respected bandwidth limits.
This ultimately means a remote Infuse client will buffer and eventually run out of buffer and pause/stutter if upload bandwidth from server is less than the bitrate of the native file. This makes Infuse un-usable for any 4k / BR streaming off network without fiber level upload speeds. In network, it’s the best option period.
Other clients have this issue as well on tvOS - SenPlayer was tested and had same issue.
Native Swiftfin and Jellyfin on Android / Chromium all respect the bandwidth limits. Swiftfin is currently hot garbage so would love to find a tvOS solution and ideally that is Infuse.
Is it possible to support the streaming vs download endpoint and let the server decide to transcode or direct play? Or make it a toggle in the server config?
Happy to provide logs or testing or anything that can assist on this issue!
Don’t forget that you need to click the like button on the first post in this thread to show your support for this suggestion! 
you keep saying that, but this isn’t a suggestion for a new feature, this is a bug that needs fixed.
jellyfin devs have already suggested it’s due to the way infuse is using the jellyfin API (ie using it incorrectly).
this thread was incorrectly moved to suggestions, when in fact it’s a bug.
I have a feeling upcoming Streamyfin releases this year will be the nail in the coffin for me to switch over and cancel my infuse subscription. I’ve loved the app for years but it isn’t keeping up with the basics of what I use it for. This topic is a huge one that keeps sitting unaddressed.
Transcoding support will never be added to Infuse. It’s been 10+ years at this point even tho Streamyfin and Android JF apps support it. Just wait for Streamyfin to come to Apple TV or hop to a better OS (CoreELEC with Kodi is best).
we’re not asking for transcoding support - the issue keeps being misunderstood and your post shows that.
Okay why is this still an issue? Jellyfin has an end-point for remote access and Infuse is simply just not using it at all. So Jellyfin itself can regulate your bittrate, but since Infuse only uses one end-point jellyfin thinks you’re streaming locally, WHICH YOU ARE NOT. I do not see why changing this to the correct end-point for remote access is such a big deal that it hasn’t been resolved yet. And why is this in suggestions when it’s a bug? This is a bug because Infuse is using the API in an incorrect way. Lets give an example of why this sucks big time. Let’s say I’m out of my house and doing something, on a buss or whatever and I want to watch Star Wars or whatever. Now I have limited mobile data and with that in mind I have configured Jellyfin to use lower bittrates when remote, because that means I can watch more stuff before my data dies. Infuse says no to that idea and will then gobble up my data faster then I can blink. This is not a feature suggestion. This is not something we want to be added. This is something we want FIXED.
Jellyfin direct support is half-assed at best.
there seems to be no desire to fix it.
I’m not sure if you’re misunderstanding what transcoding is or just think that it and using the correct endpoint are separate issues, but they are the same in practice.
Your first post is literally requesting transcoding support:
when i use Infuse remotely, jellyfin is not recognising that it’s a remote connect so no bitrate limit happens
“Bitrate limit” means “transcoding”. Same thing. Everyone in this thread who you have told don’t understand the issue are correct and you do not seem to understand the issue. You can’t separate using the correct endpoint from the point of the thread: bitrate limits while remote, which is transcoding.