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 43024]

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 43024]

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 43024]

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 1706]

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 1869]

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 16674]

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.