Direct File Access - Exoplayer

[Teddyknuddel 144]

Why is direct file access being rejected? Why are they so keen on Exoplayer when there are better solutions available?

[Luke 43032]

Hi, I think you mean SMB support? I would not say that it's being rejected.

[Teddyknuddel 144]

I brought this up years ago. But it keeps getting ignored.

[Teddyknuddel 144]

@Luke

No reply? I’ve got a few more questions. Why is a top-class programme like Emby paired with such a poor-quality Exoplayer? Why can’t you use other players, such as Just Player? Yes, I know you can integrate it as an external player, but then features like ‘skip intro’ and ‘next episode’ are lost. It should be possible to use the app in both a local mode and an external mode. Local mode for the internal network. External mode via the internet.

[Luke 43032]

1 minute ago, Teddyknuddel said:

@Luke

No reply? I’ve got a few more questions. Why is a top-class programme like Emby paired with such a poor-quality Exoplayer? Why can’t you use other players, such as Just Player? Yes, I know you can integrate it as an external player, but then features like ‘skip intro’ and ‘next episode’ are lost. It should be possible to use the app in both a local mode and an external mode. Local mode for the internal network. External mode via the internet.

First, why should the player be different based on connection? Second, from a quick google, Just Player is built on exoplayer.

[Teddyknuddel 144]

That's actually an interesting point — and yes, you're right: Just Player is also based on ExoPlayer/Media3.

But that makes my question even more interesting.

If both Emby's internal player and Just Player are based on ExoPlayer/Media3, why does Just Player handle some media on the same Android hardware better than Emby's internal player?

So perhaps my criticism of ExoPlayer itself was too broad. The issue may be less about ExoPlayer and more about how the playback stack is implemented, configured and extended by the application using it.

Regarding local vs external mode: I don't necessarily mean that Emby needs two completely different playback engines.

What I mean is two different playback paths:

Local network: Direct File Access via SMB, where supported.

Remote connection: HTTP streaming through the Emby server, with transcoding available when necessary.

The same internal player could still be used for both.

For me that would combine the best parts of both approaches: full Emby integration such as Skip Intro and Next Episode, while allowing capable local clients to access the original files directly instead of requiring the server's HTTP media path.

[Luke 43032]

Quote

If both Emby's internal player and Just Player are based on ExoPlayer/Media3, why does Just Player handle some media on the same Android hardware better than Emby's internal player?

They could be on an older or newer version that happens to handle your media better than the one we are on. We are due to update it again soon.

We've customized exoplayer heavily to add and fix things. Maybe they've done the same. We have added software decoding with ffmpeg and maybe there are cases where it's using this even when a hardware decoder is available.  This was reported recently by someone.

I think you have been so heavily focused on what you think the solution is that we haven't even really looked at your problem.

[vdatanet 1707]

12 hours ago, Teddyknuddel said:

Why is direct file access being rejected? Why are they so keen on Exoplayer when there are better solutions available?

Worth separating the two questions in the title, because they have different answers.

On ExoPlayer/Media3: it's the default on Android because it's the player Google maintains and integrates with the platform — tunneled playback, audio passthrough for TrueHD and Atmos, frame-rate matching, DRM, and updates that track new Android releases. Alternatives like libVLC or mpv are genuinely good and better at some formats, but shipping a second player means a second set of bugs, a second audio path and a second lot of device-specific quirks to support across thousands of Android devices. That's the trade-off, not a lack of awareness that alternatives exist.

On direct file access: the harder problem on Android is that an app can't just mount a share the way a desktop can. There's no OS-level SMB mount without root, so the app has to bundle its own SMB client and then feed it into the player through a custom data source. That's a real, ongoing maintenance job — dialects, authentication, credential storage, reconnects, seeking behaviour — for a feature only a small slice of users can set up.

And there's some irony in the example usually cited: the Shield is the one device that plays essentially everything and has no trouble at all over HTTP. If any Android device didn't need direct file access, it's that one.

As for why it was dropped, I'm speculating — presumably the effort wasn't justified by the usage. But that's a question for the developers, not for us to guess at.

[FrostByte 5613]

1 hour ago, vdatanet said:

Worth separating the two questions in the title, because they have different answers.

On ExoPlayer/Media3: it's the default on Android because it's the player Google maintains and integrates with the platform — tunneled playback, audio passthrough for TrueHD and Atmos, frame-rate matching, DRM, and updates that track new Android releases. Alternatives like libVLC or mpv are genuinely good and better at some formats, but shipping a second player means a second set of bugs, a second audio path and a second lot of device-specific quirks to support across thousands of Android devices. That's the trade-off, not a lack of awareness that alternatives exist.

On direct file access: the harder problem on Android is that an app can't just mount a share the way a desktop can. There's no OS-level SMB mount without root, so the app has to bundle its own SMB client and then feed it into the player through a custom data source. That's a real, ongoing maintenance job — dialects, authentication, credential storage, reconnects, seeking behaviour — for a feature only a small slice of users can set up.

And there's some irony in the example usually cited: the Shield is the one device that plays essentially everything and has no trouble at all over HTTP. If any Android device didn't need direct file access, it's that one.

As for why it was dropped, I'm speculating — presumably the effort wasn't justified by the usage. But that's a question for the developers, not for us to guess at.

The AndroidTV app can still do direct access on a Shield, but only if you fall back on the OS of your Shield.  There was a big security update on the Shield a while back which made ebr disable the option if you updated because only some of us could get it working on the new OS.  I believe you can still see the option grayed out in settings though if your Shield is up to date.  A few of us have fallen back before to get direct access, but I've since updated my Shield again because it wasn't worth it to me to stay on an older OS for this.  

[Teddyknuddel 144]

Thanks, I think this discussion has actually cleared up several things for me.

First, @vdatanet was right about the terminology. I was mixing up Direct Play and Direct File Access. If Emby delivers the original media byte-for-byte unchanged over HTTP, then it is Direct Play. What I was actually referring to was Direct File Access, where the player opens the original file directly from the network share and handles its own I/O, buffering and seeking.

I still prefer Direct File Access for my local Kodi/CoreELEC setup, but I understand why HTTP is the practical solution for most Emby clients.

@FrostByte's information about the Shield is also interesting. So Direct File Access wasn't fundamentally impossible there — it actually existed, but changes to Shield OS made it unreliable enough that the option was eventually disabled. That answers part of my original question.

@Luke, your explanation about Emby's player also corrects an assumption I had made. I wasn't aware that Emby has heavily customized ExoPlayer/Media3 and also integrated client-side FFmpeg software decoding.

Since Just Player is itself based on ExoPlayer/Media3, I agree that simply blaming ExoPlayer is too simplistic. Clearly, different implementations of the same underlying framework can behave differently.

However, I don't want to turn this into another round of reproducing old playback problems on my Shield. I've done that kind of testing in the past, and my current setup is deliberately configured around the solutions that work reliably for me. I'm not going to dismantle or reconfigure my working setup just to reproduce issues I've already worked around.

On the Shield in the bedroom I use Emby with Just Player because that combination works for what I need there. On my main system I use Kodi/CoreELEC with Direct File Access because that gives me the playback path I want.

So I'm not asking you to debug my Shield setup here.

My broader point was to understand why these different playback paths behave differently and why Direct File Access disappeared from the Android TV client. I think the answers from all three of you have clarified that considerably.

I may not agree with every design decision, but I understand the technical reasoning behind them much better now. Thanks for the explanations.

So I think we've actually made some progress here.

[Neminem 1872]

Ok Fair.

Now go apologies to the poster, which post you dismantled.

[Teddyknuddel 144]

@FrostByte Yes, I remember that now. I actually downgraded my Shield to Experience 8.x back then specifically to keep Direct File Access working.

As I remember it, Eric, @ebr, originally implemented the feature very quickly after a user requested it. When the newer Shield Experience changed things and the implementation needed to be adapted, he didn't want to continue maintaining it because he felt that too few users were actually using Direct File Access.

Later I moved my main playback setup to the Ugoos with Kodi/CoreELEC, so Direct File Access on the Shield stopped being relevant to me. My Shield is fully updated again today.

So that's an important distinction: Direct File Access wasn't abandoned because it was fundamentally impossible on the Shield. It was abandoned because maintaining it after the Shield OS changes apparently wasn't considered worthwhile for the number of users using it.

Actually, it all worked perfectly back then with Direct File Access; if I hadn’t bought the Ugoos, I’d probably still be using it that way today.

[ebr 16675]

2 hours ago, Teddyknuddel said:

When the newer Shield Experience changed things and the implementation needed to be adapted, he didn't want to continue maintaining it because he felt that too few users were actually using Direct File Access.

The main issue was that Android now requires a new permission that could scare users away from the app.  Given so few users need this and the benefit is very debatable for most users, this is not worth it in my opinion.

[Teddyknuddel 144]

@ebrthanks, Eric. That is pretty much how I remembered it.

But this is also exactly the part of Emby's approach that I find frustrating.

Direct File Access worked perfectly well for me on the Shield. I even downgraded to Experience 8.x specifically to keep using it. It wasn't removed because the feature itself didn't work or because the Shield was incapable of doing it. Android changed, the implementation would have needed to be adapted, and Emby decided that the number of users wasn't worth the effort.

I can understand the development-effort argument. What I find much harder to understand is the permission argument. If Direct File Access is an optional feature, then surely the additional permission can also be requested only when a user explicitly enables that feature. Users who don't need it never have to see or grant it.

Saying that such a permission might scare users away therefore seems like a rather weak reason to remove a useful advanced feature for the users who actually want it.

And there is a broader issue here. If every advanced feature is judged mainly by how many users need it, then power users will almost inevitably lose features over time. Direct File Access was never going to be something the average Emby user needed — but for the people with a proper local media setup, that was precisely the point of it.

Ironically, I solved the problem by buying a Ugoos and moving my main playback to Kodi/CoreELEC. There I get Direct File Access and the control over local playback that I wanted in the first place.

So yes, I understand why Emby made the decision. I just don't think “only a few users need it” automatically makes it a good decision.

Sometimes the features used by relatively few people are exactly the features that distinguish a powerful media platform from just another streaming client.

[ebr 16675]

1 hour ago, Teddyknuddel said:

What I find much harder to understand is the permission argument. If Direct File Access is an optional feature, then surely the additional permission can also be requested only when a user explicitly enables that feature. Users who don't need it never have to see or grant it.

That's not how it works.  Part of the changes made by Android are that the store listing calls out certain sets of permissions in the store listing making them look dangerous.

Can you provide a specific, detailed example proving any quality or efficiency gain by using SMB file access instead of HTTP?

[Teddyknuddel 144]

@ebr

Fair point regarding the permission. If Android/Google Play exposes that permission in the store listing regardless of when it is requested, then my assumption about requesting it only when enabling Direct File Access was wrong.

But I think we're mixing two different issues here.

Kodi on Android can access SMB shares directly and play media from smb:// paths. I use exactly that myself, both standalone and together with Emby.

So are you saying that Emby's implementation of Direct File Access specifically requires this additional Android permission, or that direct SMB access itself requires it? Because those are two very different things.

As for proving a quality advantage: no. If HTTP Direct Play and SMB deliver exactly the same original data to the same decoder, there is obviously no inherent difference in picture or sound quality. I've already corrected myself on that point.

But I don't understand why Direct File Access has to prove superior picture quality or raw efficiency in order to have a benefit.

With Direct File Access, the player accesses the original file on the SMB share directly and handles the file I/O, seeking and buffering itself. The Emby Server doesn't need to be in the media data path. That's the architecture I prefer for local playback, and it's exactly how I use Emby with Kodi/CoreELEC today.

Kodi has supported direct SMB access for years. It works. Emby itself also supported Direct File Access on the Shield in the past — I used it myself and even downgraded my Shield to Experience 8.x specifically to retain it.

So my question is quite simple: if Kodi can implement and maintain direct SMB file access on Android, why is the same concept considered to have such a “debatable” benefit in an Emby client?

I fully accept that most Emby users don't need it. But “most users don't need it” and “there is no benefit” are two entirely different statements.

Edited 11 hours ago by Teddyknuddel

[pwhodges 2093]

But what is the actual benefit?  The only specific "benefit" you have specified is that you prefer it.

Paul

[Teddyknuddel 144]

@pwhodges The actual benefit is that the media playback path becomes independent of Emby's HTTP streaming path.

With Direct File Access, Emby tells the player where the original file is and the player opens that file directly from the SMB share. From that point on, the player controls access to the media itself — including reading, seeking and buffering — rather than receiving the media through Emby Server over HTTP.

That's not a picture-quality benefit, and I'm not claiming that it is. The bits don't magically become better because they travelled over SMB.

The benefit is that I can use a player and its native file-access implementation directly against my media storage while still using Emby for the library, metadata and playback management.

Kodi is a very good practical example. I can point Kodi directly at the same SMB files and play them completely independently of Emby. With EmbyCon and Direct File Access, I get that same playback path while retaining the Emby library around it.

So yes, I prefer it — because it gives me that separation and control, not simply because I happen to like the letters SMB better than HTTP.

Whether that benefit is important enough to justify maintaining the feature in Emby's Android client is a different question. Eric can reasonably say that it isn't worth the development effort for the number of users who want it. But that's different from saying there is no actual benefit.