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

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

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

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

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

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.