All Activity

@Luke Hi, Is named as always, Tittle, Yr, Season Number/Ep.. Yesterday when I added + few other Episodes for different series, I saw Emby adding all those and this TV Series was there, then after it finishes updating the info, it flash and all other episodes are there except this TV series it vanish. Under TV Series is not there S01 nor S02, if I do to settings and search to Metadata Folders, is not there. If I do a manual search it comes per episodes but Emby will only provide S01and not S02. If I go to my folders outside Emby, I can see S02 have all the images and metadata added by Emby. I did took out the S02, refresh Emby and added back again, no luck and seems it is not merged to another TV Series as I do not have other named the same except the original Movie.. Hope this helps

My data is backed up. I'm not rich, just paranoid. As a paranoid person I would prefer if Emby took a beat before removing huge swaths of my library before I even have a chance to see that there's a problem. I would prefer Emby throw out an alert that says something like Hey a huge number of files are gone, do you want to continue scanning? Yes, the data is gone for a reason. The reason is an accident occurred. A very common accident. Help me out with a notification and give me a chance to fix things before moving ahead. This is reasonable.

That's a fair point. But left others baffled, like me. Even on wired network with 1 - 5ms pings this happens Why is this afflicting us and why not just remote connections. Emby knows when it a remote connection / different network.

@MAX92I can't seem to replicate settings not being saved. What settings precisely are you having problems with?

Hi Luke, I confirm that the Emby LG App is already in version 1.0.51. I have done à new test and joined a new report. Remark: on this TV 28TN515S-PZ, only 4K videos can't be played, 1080p, 720p etc are OK. embyserver.txt

I might have forgotten to hook up the settings. Will fix asap!

This solved a specific problem for me that I had requested a solution for.

Thanks for the job and the share. Not try yet but when I save settings, it's not saved. I need to start again.

Jep this is really annoying to look at. I know what it's trying to do. But roll it back.....

Yes, I think we actually do agree on this now. And that's exactly how I'm using Emby with Kodi/CoreELEC: Emby manages the library and metadata, while Kodi accesses the original files directly through the shared network paths. I also understand why Emby can't build its entire client architecture around direct file access. For browsers, Chromecast, Smart TV apps and many mobile devices, HTTP is obviously the practical and often the only viable solution. My point was never that HTTP should be removed or replaced for those clients. I would simply like direct file access to remain a first-class option on platforms where it makes sense and where the client is capable of using it. For my setup, that's clearly the better playback path. For somebody else's setup, HTTP Direct Play may be the better choice. So yes — I think we've pretty much beaten this particular horse to death.

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?