All Activity

I’m looking for feedback from the Emby community. Currently, about 95% of Ear Wax users are on Plex and 5% are on Emby, and I’d like to better understand what Emby users need. What’s the main thing holding you back from trying Earwax? I hadn’t heard of Earwax. I’m not sure what it does or why I’d use it. I don’t use Alexa for music. Setup seems complicated, or I ran into trouble. It’s missing a feature I need. I have questions about cost or what’s included. I already use Earwax with Emby. If you’ve tried it and stopped, or your reason isn’t listed, please leave a comment. What worked, what didn’t, and what would make it more useful for you? Honest feedback is welcome, it’ll help me decide what to improve next.

You're right about FEL. At the moment, proper FEL playback on these Ugoos devices is a CoreELEC solution, not something available under their stock Android implementation. I do think it would technically be possible under Android with the right hardware, drivers and Dolby implementation, but that would likely involve licensing as well as considerable development effort. But FEL is really a different subject and wasn't the point I was trying to make here. I probably shouldn't have brought it into this discussion in the first place. Yes, that's a fair distinction, and I think we've actually reached agreement on that part. My earlier wording about HTTP altering the file was incorrect. If Emby sends the original file byte-for-byte unchanged, then it is Direct Play regardless of whether the transport is HTTP. What I was really referring to was direct file access, and you've described the distinction pretty much exactly as I mean it: the server is removed from the media data path and the player handles its own I/O, buffering and seeking directly from the share. I'm not claiming that this inherently produces better picture or sound quality. If the same bytes reach the decoder, they're the same bytes. My point is that it gives the player more direct control over the playback path and can therefore be advantageous depending on the player, device and media involved. So on that point, I think we're actually on the same page now

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.