All Activity

I download albums (maybe 10 or so at any one time) and playlists (2 or 3 with 100 ish songs). Then when I go into downloads there are 310 Albums and no playlists. So for me, if I've downloaded a playlist I'd like to see that playlist available to play\shuffle. And some sort of filter or way of showing only albums that are fully downloaded.

But if the hard drive is dead. The data is too. Unless you backed it up. Given the prices of drives today. Likely no backup and the data is gone. Most users data is just gone. Poof. When people want to force an update of a library it is suggested to move that library out and scan. Then moving it back in and scan. This behavior is why that happens. It is expected when the drive isn't there that it isn't there for a reason and likely it will be shortly and can get scanned again. If you want the OS to notify you the moment the drive becomes unmounted you can do that. But why would Emby need to? The issue has never been mentioned before. There is one person having the problem. This is cause and effect. The cause is unmounting the hard drive. The effect is it gets removed as a library during the scan. But figure out the cause and there is no effect. What is the cause?

Don't hard drives die? Wouldn't that cause the exact issue OP is on about? It's reasonable to expect Emby to deal gracefully with unfortunate situations that happen from time to time in the real world.

Thanks a lot

I guess devs need logs to see the issue.

One more thought, and I think this is where we actually agree. Emby does support the concept — libraries have a shared network folder field precisely so a client can be pointed at the original path, and that's what Kodi and a few other players use. But the number of clients that can actually make use of it is small. The browser can't. Chromecast can't. Samsung and LG TV apps have no SMB stack and no way to store share credentials. iOS is heavily restricted. And none of it works away from home without a VPN. So you end up with a feature that only pays off for a specific setup: a player capable of network file I/O, on a wired LAN, with the share reachable. That's not a knock on it — for that setup it's clearly the better path, and your results show it. It just explains why it stays a niche option rather than something the apps are built around. Developers are going to put their effort into the path that works for the other 95% of clients, and keep direct file access as the hook it already is for the players that can use it.

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 Ear Wax? I hadn’t heard of Ear Wax. 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.