I’m trying to use Yatse on my phone with my Jellyfin server.
On the server, I set the “direct” path that allows Kodi to read the files directly through the jellyfin addon, without doing any transcoding, e.g. “http://url.to.files”
I notice that Yatse insists on using that direct path when streaming, and whatever I tried (reducing bandwidth, disabling “only transcode if necessary”), I could not force Yatse to ask for a transcode and it just forwards the direct path to the files to the player (VLC or MX), e.g. “http://url.to.files/the.movies.mkv”
That’s not quite desirable on a phone, especially if not at home, so is there a way to disable that behaviour?
If you connect Jellyfin in Yatse via the Kodi addon (so Yatse only connected to Kodi) then Yatse can’t do anything as it’s not aware of Jellyfin at all and Kodi have no notion of transcoding.
If you connect to Jellyfin directly in Yatse then it should request transcoding according to your transcoding settings inside Yatse.
Haha… Time flies and long are my Kodi days
Yatse fills a gap regarding offline watching with Jellyfin, so…
That doesn’t seem to happen and is the issue.
I’m pretty sure it’d work if the “Shared Networf folder” wasn’t set, but if it is, it seem Yastse is always using it.
Hum can you show me your Yatse settings in the streaming part for the transcoding?
Since your files start by http I fear that there’s a special combination here that makes Yatse skip everything as it assume the file can’t be transcoded.
Or even better export just the settings (not the hosts or anything else) and upload the file so I can try to repro.
Edit: BTW what kind of http folder is this? Webdav or simple html index?
Mmm… Actually, I would assume that Yatse wouldn’t even consider that path at all for streaming (or maybe with a setting).
Jellyfin itself will do a “direct”, non-transcode proxy streaming if applicable, so Yatse is doing stuff it shouldn’t, here, I think. AFAIK, that “direct path” is only for the Kodi addon. Not good for “away” streaming, for sure
Mmm… Actually, I would assume that Yatse wouldn’t event consider that path at all for streaming (or maybe with a setting).
When you start to have to deal with 5 different providers that all have bugs and needs workarounds and need to handle sharing in every direction there’s a very complex decision engine in the center. (Dealing with offline and everything add some fun).
So there’s quite a few special cases that skip requesting a transcode decision from the server as it’s not necessary or could even cause issues.
And this is what is happening here you reach a state where Yatse does not even ask for a transcode decision from the server.
Just need to figure what hack generate that state and figure out why it was here and how to reduce it’s scope to not apply in this case.
Can you tell me how you added the http server on Jellyfin ? So I can fully reproduce and not just do code tests.
It’s in the screenshot above, which is the definition of the folders related to a media library in Jellyfin.
Got you. My expectation would be that the Yatse “Only transcode if necessary” would cover this, so that if it’s off, transcode would always be requested.
I meant on the http server side WebDAV? Apache index ? …
This is more complicated, as there’s also all the sharing from other app that reach Yatse and casting to UPnP / Chromecast, FireTV, …
Then you add bubbleupnp as external transcoding platform that can add transcoding to many things.
But in the end the issue here is that the media is not seen as a jellyfin media that should use the normal path l, but as an http file that could have been shared and so use a different path.
I just need to figure out where this wrong decision is made. A check is done at the wrong moment.
So since I’m curious I did a quick code check and pretty sure the issue is :
if (media.file.lowercase(Locale.getDefault()).startsWith("http")) {
// Hack for Kodi curl params as | should be encoded and never present in an url. TODO: Handle this in Kodi provider and handle some of the params?
Kodi being the issue between us as good old times
Will check history and reduce the scope to fix your issue next week.
To confirm your suspiscion regarding this being specific to http, I tried to stream from a different source (one of the “\THEIA”), and transcoding happens as it should.
Please test attached APK. This was the http thing and the necessary hacks to be able to stream from Kodi addons that returns http urls with the params in the curl way.
WebDAV? Apache index ? …
