All Activity

Fair enough — direct file access and Direct Play are different concepts, and I'm happy to use the terms properly. Direct file access means the player opens the file from the share itself and handles its own I/O, rather than pulling it through the server's playback pipeline. That's a real distinction and it has genuine advantages: the server is out of the path entirely, the player does its own buffering and seeking, and things like BDMV or ISO structures with menus work properly. But that's an architecture argument, not a quality one. Your earlier point was that HTTP alters the file and can't do direct play — that's the claim I was answering. In both cases the player receives the same bytes; what differs is who reads them off the disk and how they're buffered. So if direct file access works better on your hardware and player, that's a perfectly good reason to use it. It just isn't a difference in what ends up on screen or coming out of the receiver.

Because it's available on all Android devices. Supplying another player might also cause other unforeseen problems like audio passthrough not working. IMO. Exoplayer is not perfect but it does a more than fine work. Android it self does not (at least natively) support FEL playback anyway. So using another player would not help anyway and you would need a completely different operating system to fix that. Yes, the Ugoos might have the capability for more but have the developers of it made sure that their version of Android supports it instead of only CoreElec? No matter the hardware it still needs the software used to have support for it. For example, try and get Dolby Vision to work on a Linux machine even though it's hardware is more than capable of it. Buffering in Emby when viewing remotely is most likely a connection problem. I can easily watch remux files remotely from my server without any buffering or stutter.

I'm not talking about whether Emby's HTTP stream qualifies as “Direct Play”. I'm talking about direct file access, where the player opens the original media file directly from the network share instead of receiving it through Emby's HTTP playback pipeline.

what track played? What track did you expect to play?

HI, have you updated to Emby for LG 1.0.51? Has that helped?

Hi, even with the static IP you still need to setup port forwarding in your router, right? Maybe you need to do that for the ugreen?

Will this help to generate folder.jpg?

Hi all, MDBList syncs watched status, ratings, and collection membership two-way between Emby and mdblist.com, plus live scrobbling. Looking for testers (as per requirements ) before requesting catalog access. Requires Emby Server 4.10+ (uses the newer GenericEdit config UI). Install: grab the DLL from Releases, drop it in your plugins folder, restart Emby, then Dashboard → Plugins → MDBList to connect your account. https://github.com/MDBList/emby-plugin-mdblist Feedback and bug reports welcome! Emby.Plugin.MDBList.dll

Hi, is this still an issue following the TOS update?

Can Emby generate folder.jpg? Is there setting/option? Or I have to add folder.jpg to every main Folder (this case Western folder) I tried to add folder.jpg to Western folder (copy image from Movies Folder generated by Emby) and Emby shows this pic, And name of movie instead of name of folder? This is more important. Thanks for helping.

That's actually much closer to the point I'm trying to make. Whether Kodi can do it because it brings its own codec support, uses a different passthrough implementation, or can access capabilities that ExoPlayer doesn't expose is secondary. The important part is that the same Android device is demonstrably capable of doing it with a different playback stack. I'm not arguing that Emby should somehow force ExoPlayer to support capabilities it simply doesn't have. I'm questioning why Emby's own Android playback capabilities should ultimately be limited by ExoPlayer in the first place. Kodi on Android doesn't use ExoPlayer as its playback engine. It has its own VideoPlayer stack and uses Android's hardware interfaces where appropriate. So if Kodi can make better use of a device's capabilities, then the limitation isn't necessarily Android or the hardware itself. It can simply be the playback stack chosen by the application. And yes, I know the obvious answer: “Then just use an external player.” But that isn't an equivalent solution. As soon as playback is handed off to an external player, you lose part of the integrated Emby experience and functionality. Features such as Skip Intro and the seamless Next Episode behaviour depend on Emby controlling the playback session. So you're effectively being asked to choose: Use Emby's internal player and accept its playback limitations, or use a more capable external player and give up Emby features. That's exactly the compromise I'm questioning. What I would like to see is an Emby Android player with a more capable playback stack of its own — something conceptually closer to Kodi's approach — while retaining Emby's full integration. Then we wouldn't have to choose between maximum playback capability and the features we're paying for Emby to provide. Maybe the real question isn't whether ExoPlayer can do everything Kodi can. Maybe the question is why a high-end media application should permanently accept ExoPlayer's limitations as its own.

Atrium 1.8 is on the App Store, and it's mostly this thread. Nearly all of it was reported here in the past few days. The "Recently Added" rows ran out after sixteen items — they show 128 now. Coming back from a film sent the focus to the top of the screen instead of leaving it on the card you came from. Channels arrived in number order rather than your server's own, which with two tuners means repeated numbers and both sources interleaved; and the sort pill still said "Number" after I changed that. Person pages show the biography the app never asked your server for. The alphabet in your libraries is the size it should be next to Sort and Filter. Also from here: the "Next Episode" button used to leave thirty seconds before the end, so when the credits start just before that, it vanished while you were reaching for it. And Live TV now opens a session on your server: before, watching a channel showed up nowhere on your dashboard. The top row on the tvOS home screen speaks the right language too, as long as it's one of the three the app has: English, Catalan or Spanish. Want another, say so here. Two new things: from an episode you can jump straight to its series, and music can finally be stopped from Now Playing. And one to try, if you like: Settings ▸ Home ▸ Enhanced Home Screen. It's off by default. Turn it on and the header stays put, only the bottom row scrolls, and the background follows the card you're on. It's the part I can't test for you: every Apple TV moves a little differently. Say here whether you keep it on.

Not entirely. Kodi might have codex available internally that Exoplayer doesn't have on the Ugoos. Nvidia has licenses to play most formats on their Shield that the Ugoos might not have active when using Android and/or Exoplayer.

Hi, we are looking into this. Thanks.

Excellent news, @Luke. Thank you!! I understand you may not be able to provide too many details, but can you give a rough sense of timing (2026, 2027, later?) and generally what changes you intend for offline play? By the way, I do appreciate that the way it works now probably does make sense for movies, where most people would not try to take their entire movie library with them on a phone, and searching by title makes sense for movies. But for music in particular, the ability to sync all music and retain the ability to use Album Artists, Playlists, and Genres for selecting songs to play is essential for the typical offline user. Assume users who use Emby have larger-than-typical music libraries -- at least dozens (often hundreds) of artists, hundreds of albums, and many thousands of songs would be the norm. Therefore, retaining the organizational structure (especially album artists, playlists, and genres) is vital to even using the offline music. Ideally, offline will work just like online, with the same UI and same features (the online UI is excellent, best I've seen), but if not feasible to just keep that whole UI working offline, then please at least add playlist, genre, and album artist to the existing album and song for offline sorting, filtering, and playback. (At least for me, "album artist" is more important than "artist".)

Hi, we are looking into this. Thanks.

Hi, the item payload will have a list of MediaSources, so you can examine those and see if there is more than one. Make sure to use the single item endpoint, not the multi-item one.

@denisj Hi, we are working on this. Thanks.

You may well be right about HTTP technically qualifying as Direct Play when the original file is delivered unchanged. But that's really beside the point I was making. A checksum only proves that the bytes arriving at the client are identical to the bytes on the server. It does not prove that the client then buffers, demuxes, decodes and outputs those bytes equally well. In fact, your own argument about buffering, throughput and the player confirms exactly that distinction. My point is what happens after those identical bytes reach the client. A good example is my Ugoos AM6B+ running Android. With the Emby Android app, I have certain media where specific HD audio tracks remain silent. The very same files and audio tracks work correctly in Kodi on the same Ugoos, under the same Android installation. That does not happen on my Shield, so I'm not claiming that this is some universal Emby Android audio bug across every device. But it does demonstrate the point perfectly: Same hardware. Same operating system. Same file. Same AVR. Different playback engine — different result. So your 120 Mb/s + TrueHD example proves that your particular material works with your particular setup. It doesn't prove that Emby's Android playback path is equivalent to Kodi's, nor that it exposes everything the underlying hardware is actually capable of. Dolby Vision Profile 7 FEL makes that distinction even clearer. Successfully receiving the original DV7 stream over HTTP does not mean that the playback engine is actually processing the FEL. Transporting all the information and actually using all the information are two entirely different things. And that brings us straight back to the problem of the thread starter. If the original 4K file arrives unchanged but the client nevertheless interprets or handles it incorrectly, then the fact that the transfer itself was bit-identical obviously doesn't solve the problem. That's why I brought up direct access to the original media through something like SMB and a capable playback engine such as Kodi in the first place. It removes parts of Emby's playback path from the equation and lets software that demonstrably handles these files correctly deal with them. So yes, you may be right about the definition of HTTP Direct Play. But proving that HTTP can transport an unchanged file was never the interesting question. The interesting question is what the client does with it once it gets there.

Hi, were you able to get connected with https?

Hi, there are force transcoding options in the app now for many formats.

In newer versions there needs to be something in the western folder with an image. it could be a video, or it could be a folder.jpg file.

Hi, we are working on improvements to this. Thanks for the feedback.

Let's separate two different claims, because they're getting mixed together. 1. "HTTP alters the file." This one is testable. Download the file from Emby over HTTP and run a checksum against the source file on disk. They match, bit for bit. Nothing is added, removed or re-encoded — it's a byte-for-byte transfer, the same as any download. And Emby itself tells you what it's doing: the dashboard says "Direct playing", "Remuxing" or "Transcoding". If it says direct play, the server isn't touching the stream, regardless of transport. 2. "It stutters at high bitrate." That's a different problem, and I don't doubt you're seeing it. But it's a buffering/throughput issue on a specific client, network path or player, not evidence that the file was modified. Stuttering means the player isn't getting bytes fast enough or isn't buffering enough of them — the bytes it does get are still the original ones. For reference: I run Blu-ray remuxes at over 120 Mb/s with TrueHD and I've never had an issue. The TrueHD passthrough is the giveaway, actually — my receiver locks onto a genuine TrueHD bitstream. If HTTP were altering anything, that lossless track wouldn't survive intact. So SMB may well work better on your setup, and there are good reasons to prefer it — no argument there. But "HTTP can't do direct play" is a different statement, and it isn't accurate.

Hello Luke i tested Emby on WIndows (more versions) in Virual Machine and version 4.7.14 had collage in Folders view and show Czech names (not folders names) afted this version, this features disappeared ;-( Logs embyserver.txt Screenshots