Direct File Access - Exoplayer

[Teddyknuddel 145]

@vdatanet
That's actually a much better way of putting it, and I mostly agree with you.

You're right that “the server isn't in the media path” is, by itself, an architectural difference rather than automatically an advantage. Whether it becomes an advantage depends on the setup.

But you've also just listed several concrete situations where it does become an advantage: avoiding an unnecessary network hop, players whose native file access behaves better, and media structures that benefit from real file access.

And that's really all I've been arguing. I never claimed that SMB universally beats HTTP, nor that it somehow produces better picture or sound from identical data.

In my particular setup, everything is local, the player and storage are on the same network, Kodi has excellent native SMB support, and I neither need nor want the server to mediate media delivery. So Direct File Access is the architecture that suits that setup better.

For a browser, Chromecast, remote client or a client that may require remuxing/transcoding, HTTP obviously has major advantages. I wouldn't suggest otherwise.

So yes: two architectures, different trade-offs, and which one is preferable depends on the setup.

Which brings us to the slightly ironic conclusion that Direct File Access does indeed have concrete benefits — just not for everybody.

And that was my point all along.

[ebr 16686]

7 hours ago, Teddyknuddel said:

After all these discussions, have we now reached the point where the strategy is simply to sit this out in silence and hope that the thread starter eventually “forgets” about it?

From my perspective there is nothing left to discuss at this point in time.  There is not enough benefit in this feature to warrant further development at this time.

[Teddyknuddel 145]

@ebr
And this is exactly where we disagree.

You say there is “not enough benefit” to warrant further development. But that isn't an objective technical conclusion — it's your assessment of how much those benefits are worth relative to the number of users who would use them.

@vdatanet has just described several situations himself where Direct File Access can provide an actual advantage. So I think we've moved beyond the question of whether benefits exist at all. They clearly can.

The remaining question is how much value Emby assigns to those benefits and to the users who want them.

And that's the part I don't agree with.

Direct File Access existed, it worked, and I used it successfully myself. It wasn't abandoned because it was technically useless or because HTTP made it functionally impossible. Android changed, maintaining the feature became less attractive, and Emby decided that the number of users benefiting from it didn't justify the effort.

That's your development decision to make. But I'm equally entitled to challenge the reasoning behind that decision — especially as a user who actually used the feature and found it valuable enough to downgrade an entire Shield just to retain it.

So no, from my perspective there is still something to discuss. Saying “there is not enough benefit” doesn't settle the question; it simply states Emby's current position on it.

And positions can be reconsidered.

[yocker 1886]

@Teddyknuddel



Is this what you are looking for?

[ebr 16686]

1 hour ago, Teddyknuddel said:

And positions can be reconsidered.

We are not currently reconsidering this position.

1 hour ago, yocker said:

Is this what you are looking for?

He's well aware of that field.  The issue is our Android apps do not currently use it due to the reasons I laid out.  Our Windows (and possibly Linux, I'm not positive on that) apps will use that.

[yocker 1886]

7 minutes ago, ebr said:

He's well aware of that field.  The issue is our Android apps do not currently use it due to the reasons I laid out.  Our Windows (and possibly Linux, I'm not positive on that) apps will use that.

I was asking because i wanted to be sure of the conversation.
Must admit i have gotten a little curious about the smb thing.

[Teddyknuddel 145]

@ebrYes, I know you're not reconsidering it. That's precisely the problem I'm criticizing.

The functionality is already part of Emby's server architecture. The “Shared network folder” field exists specifically so that Emby clients can access media files directly. As you've just confirmed, the Windows client uses it, while the Android clients don't.

So we're not discussing some exotic concept that doesn't belong in Emby. We're discussing an Emby feature that already exists, was previously usable on Android TV as well, and is still used by other Emby clients.

The Android implementation stopped being maintained after Android/Shield changes because you decided that too few users benefited from it.

I understand that decision. I simply don't agree with it.

And “we are not currently reconsidering it” doesn't really address any of the arguments made here for reconsidering it. It only confirms that you currently don't intend to. Which is evidence of a lack of professionalism.

Which, incidentally, brings us right back to why I originally described Direct File Access as being “rejected”.

@yocker
Ironically, it was precisely this setting on the server that made Direct File Access possible in the first place. Not just on Kodi, Linux and Windows… no, on Android as well.

[ebr 16686]

4 minutes ago, Teddyknuddel said:

So we're not discussing some exotic concept that doesn't belong in Emby

Actually, it is pretty much a legacy concept.  It is there from the very early days when it was necessary for mounting ISOs and such. It was put in to support "Emby Classic" which ran in WMC.  That is no longer today's world.

4 minutes ago, Teddyknuddel said:

I understand that decision. I simply don't agree with it

That is your prerogative and I'm sorry this is such an issue for you but we have a very long list of other items to work on that will provide very clear benefits to a much larger segment of our user base.  That is where our energy is going to stay for the time being.

[Teddyknuddel 145]

@ebr
Let me remind you about the DTS HD High Resolution issue – you kept putting that off back then, until I got absolutely livid after three months. Or what ever happened to the person who, from one day to the next, could no longer record TV programmes? I don’t know what became of it – but I reckon, after two years, it still hadn’t been sorted out. So much for all the effort you’re putting in.

I’m more inclined to think this is just defiance on your part.

[Teddyknuddel 145]

On 9/4/2026 at 11:00 PM, Luke said:

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

You originally said you wouldn't describe Direct File Access as being “rejected”.

Eric has now made Emby's position quite clear: the feature isn't considered beneficial enough to warrant further development, and that position is currently not being reconsidered.

So I'm genuinely interested in your view now: would you still say that “rejected” is the wrong description?

[Luke 43061]

Nothing is ever completely off the table unless it's just outside of our primary goals.

For example if we were to start seeing an influx of users interested in bluray folders and iso's, then perhaps we would invest more resources into them.  The same goes for any other feature. 

So yes we see your request and acknowledge it and are keeping an eye on it. Right now our developer time and energy is being spent on things that are wanted by larger numbers of users.

[Teddyknuddel 145]

@ebrAnd I think @yocker has just unintentionally demonstrated one of the problems with judging this feature purely by how many people used it.

He's a Top Contributor with more than 2,000 posts, and even he first had to clarify what we were actually talking about. Now that he understands it, he's curious about the SMB functionality.

That's exactly my point: how can you reliably conclude that too few users are interested in Direct File Access when many users may not even know what it is, what the “Shared network folder” field is for, or that Android TV used to support it?

Low usage is measurable. Low interest is not the same thing.

If a feature is barely known, barely exposed and hasn't been available on Android for years, then its historical usage numbers tell you very little about how many current users might actually find it useful if they knew it existed.

@yocker has just provided a rather nice real-world example of that — without we even having to look for one.

10 hours ago, Luke said:

Right now our developer time and energy is being spent on things that are wanted by larger numbers of users.

Your development team would do better to focus on existing issues rather than new features. This example alone is an absolute disgrace – look at what you’re getting up to:
 

 

[yocker 1886]

2 hours ago, Teddyknuddel said:

@ebrAnd I think @yocker has just unintentionally demonstrated one of the problems with judging this feature purely by how many people used it.

He's a Top Contributor with more than 2,000 posts, and even he first had to clarify what we were actually talking about. Now that he understands it, he's curious about the SMB functionality.

That's exactly my point: how can you reliably conclude that too few users are interested in Direct File Access when many users may not even know what it is, what the “Shared network folder” field is for, or that Android TV used to support it?

Low usage is measurable. Low interest is not the same thing.

If a feature is barely known, barely exposed and hasn't been available on Android for years, then its historical usage numbers tell you very little about how many current users might actually find it useful if they knew it existed.

@yocker has just provided a rather nice real-world example of that — without we even having to look for one.

Your development team would do better to focus on existing issues rather than new features. This example alone is an absolute disgrace – look at what you’re getting up to:
 

 

I just wanted to be 100% sure as the functionality you are asking for could be something slightly different.

Curious yes, doesn't mean i need the functionality.
I have a main Emby server and a storage server, it could lessen the data transfers on my network but the amount is negligible as i'm the only user of my server on my local LAN in my home and i'm running 10gb network.
It would ofc. be a nice feature to have but not something i really need.

I'm personally much more interested in a higher version FFmpeg, not that direct access could not be useful.
Just my opinion.

[FrostByte 5617]

I'm sure a lot of people would prefer to use direct access if available, I would and did so when it was available.  However, I don't think I've noticed a big difference since it was taken away.  Though my network is pretty good so I'm sure that helps.

The E4K plugin with Kodi running in native mode is another option and is somewhat easy to set up.

[Teddyknuddel 145]

@yocker

Fair enough — I know you said you're curious, not that you need it.

But I suspect you'd grow rather fond of it if you actually had the option to try it. That's more or less how it was for me: once I had my local playback accessing the files directly, I didn't really want the server back in the media path unless there was a reason for it to be there.

With your 10 Gb network and only one local user, you're obviously not going to see some dramatic performance improvement. That's not really the point. It would simply give you another playback option — and, as you said yourself, a nice one to have.

And @FrostByte actually illustrates the other side of my argument perfectly: he did use Direct File Access when it was available and says he would prefer to use it again if it were available.

So within a few posts we've already gone from “too few users need this” to one experienced user becoming curious about it and another experienced user saying outright that he would prefer it if it were still available.

I'm not claiming that proves millions of Emby users are waiting for Direct File Access. It obviously doesn't.

But it does reinforce my point: you can't measure demand for a feature properly when the feature hasn't been available to those users for years and many of them don't even know what they're missing.

Sometimes people have to know an option exists before they can decide whether they want it

[ebr 16686]

6 hours ago, Teddyknuddel said:

he did use Direct File Access when it was available and says he would prefer to use it again if it were available.

But you left out the fact the he saw no real benefit from it.

We have limited resources and are choosing to work on things that will truly benefit a large number of our users.

I've said this over and over again.  This will be my last post on this topic until such time as we find a reason to reconsider it.

Thanks.

[Teddyknuddel 145]

@ebr

I don't think it's quite that simple.

You say @FrostByte saw no real benefit. What he actually said was that he didn't notice a big difference after Direct File Access was taken away. In the very same post he also said:

“I'm sure a lot of people would prefer to use direct access if available. I would and did so when it was available.”

If somebody used a feature and would prefer to use it again if it were available, then clearly that feature has value to him — even if losing it didn't make his system unusable.

@yocker illustrates the other side of the problem. He's an experienced Emby user and Top Contributor, yet this discussion has only now made him curious about Direct File Access. He doesn't need it, and that's perfectly fine. But it demonstrates something important: low historical usage does not necessarily equal low potential interest.

People cannot use, evaluate or request a feature they don't know exists — especially one that hasn't even been available on Android for years.

Nobody here can prove that a large number of Android users would use Direct File Access today. But equally, I don't see how Emby can know that they wouldn't if the feature isn't available, isn't exposed to them and most users probably don't even know it ever existed.

And that brings me to the “limited resources” argument.

When Direct File Access was originally added to the Android TV app, @rbjtech was the one who persuaded you to implement it. If I remember correctly, he said at the time that the actual implementation took you about five minutes.

Obviously Android has changed since then. I'm not claiming that restoring it today would take another five minutes.

But before “limited resources” becomes the decisive argument, there's an obvious question: has anyone actually assessed how much work restoring Direct File Access on Android would require today?

If you've looked at it and concluded that it would require substantial development and ongoing maintenance, that's a concrete resource argument.

But if it hasn't been evaluated because the assumption is already that too few users would benefit, then “limited resources” isn't really the reason for not doing it. The prior decision that it isn't worth investigating is.

And that creates a rather circular argument:

Too few users used it → therefore it isn't worth restoring → therefore current users can't try it → therefore there can never be usage data showing that more users might want it.

Perhaps the first step towards finding the “reason to reconsider” you mentioned wouldn't be development at all. It would simply be finding out how many users would actually want Direct File Access if it were available again.

A poll or feature vote would cost considerably fewer development resources than either of us has already spent discussing whether there's any demand for it.

Limited resources” is a perfectly valid argument — once we know that restoring the feature would actually require significant resources. Has that ever been established?

[ebr 16686]

21 minutes ago, Teddyknuddel said:

Limited resources” is a perfectly valid argument — once we know that restoring the feature would actually require significant resources. Has that ever been established?

Yes and it isn't just development, it is support.  Android devices aren't built for direct network file access generally because it just isn't what they are used for.  Only some devices (like the Shield) will even support it. And even then, it requires specific setup on the part of the end user to make it work properly.  On top of that, there is only one field for the network path but Android devices will require a different style of value here than, say, a PC meaning now the single field cannot support both Android devices and an HTPC (where it is currently supported and arguably more useful just because of disc formats).

All of those factors increase the support requirement for the option AND severely limit the number of people who will undertake the steps necessary to get it working properly and, even then, it could screw up other setups those same people have (an HTPC).

Add to that the fact that there is no quality or performance benefit for the vast majority of situations and you end up with a very high cost low benefit feature.  Us spending that time (not just development but also support) on it would be a very poor choice of resource use on our part.

Okay, now I'm finished  

[Teddyknuddel 145]

@ebr
Interesting.

I have to ask, though: why are all of these supposedly decisive technical and resource arguments only appearing now?

We've been discussing this for quite some time. Initially the argument was that too few users needed Direct File Access and that its benefit was “very debatable”. Then the Android permission issue was raised. Then it became “limited resources”.

Only after I specifically questioned whether restoring the feature had ever actually been assessed as requiring significant resources do we suddenly get a detailed list of additional technical and support problems.

If these were the real reasons behind the decision all along, why weren't they mentioned when I originally asked why Direct File Access was no longer supported?

And some of what you've now described still sounds less like an inherent problem with Direct File Access and more like limitations of Emby's current implementation.

You say there is only one shared network path field and Android would require a different value from an HTPC. Fine — but that's a limitation of the current path-mapping design. It doesn't demonstrate that Direct File Access itself is a bad or prohibitively expensive feature.

Likewise, Android devices clearly can access network files directly when the application provides the necessary implementation. Kodi demonstrates that every day. Whether Emby wants to implement and support that is another question entirely.

I'm also not claiming that bringing back the old implementation would take another five minutes. Android has changed since then. But I do remember @rbjtech persuading you to add Direct File Access originally, and according to him the actual implementation at the time was essentially a matter of minutes.

So when “limited resources” suddenly becomes the central argument years later, I think it's entirely reasonable to ask what the actual estimated development and support cost today is.

Has somebody actually evaluated that? Or are we working backwards from the already-made decision that the feature isn't worth supporting and assembling the reasons why?

Because those are two very different things.

And “Okay, now I'm finished” doesn't make that question disappear.

Edited 26 minutes ago by Teddyknuddel

[roaku 847]

We need some sort of token limit and monthly reset for forum posts.