Leaderboard

Download page shows this. Users in the USA, UK, and Ireland can install Emby in Samsung App Store. Users outside the USA, UK and Ireland can Install from USB.

This isn't even me trying to be snitty. I'm genuinely aasking for a pause to focus on quality of life improvements and maybe listing out a few bugs. Previously I mis-spoke when I said "Feature Requests". * QOL ENHANCEMENT: Downloads need to be updated for 2022: I think this could be improved by having a unified interface / set of functionality for the apps where all that is presented to you is you server as it is when you're connected, and if you're not connected the same interface is shown only with the media that is downloaded to the device. Basically implement a local-media fallback for the connected server interface. * QOL ENHANCEMENT: please facilitate media sync in Emby theater. * QOL ENHANCEMENT: share links for multi-user servers - I have a MASSIVE collection of music, it'd be a NICE TO HAVE (i admit) to have share links so i can send my users links to songs and episodes directly. cause at least in my use case we actually talk about movies and music. * BUG / SOMETHING OF NOTE: Cache media descriptions / synopsis locally. I notice these are changing. * POSSIBLE BUG: Collections are broken, Some movies group appropriately some times they dont. For example I have the James bond bluray box set. I started digitizing them and realized there was an audio sync issue on all but two so I deleted all but those, the collection freaked out and disappeared, 9 correct re-encodes later, the already played movies wont add themselves to the collection, but all the new, unplayed ones will. All of these movies have original metadata that was gathered when the movies were added to the server, and I don't know why the collection would delete itself when there are still 2+ titles from the collection that have stayed on the server the whole time, with their meta data. * On my tablet recently, Emby correctly downloaded the movies i asked for to my SD card, but then were "not available" in the app so I had to play them from android's built in media player.

Hi, i actually caught this earlier today. There is something in the database query related to the parental rating that is sometimes causing it to be a little slower than it should. We'll look at backporting this fix into a new 4.7.X release if we can. Thanks.

In the meantime, start typing on keyboard, it'll get you there a bit faster. Edit: Related:

Another good place to restrict users to domain-names/IPs would be a field in the user-settings, in conjunction with the "allow remote connections"-tick. Probably even a better place now that I think about it.

Thanks!

Can you try using the Identify feature and see if that helps? Thanks.

I don't have an ETA, sorry, but it's certainly possible.

Ah ok - I haven't followed too closely tbh, I'm still using .64 haha. But as long as the latest release is tested and confirmed by a few people - then Cheese can just exclude the bad release and allow all the others imo. @Cheesegeezer

It's this one, at least on my destroyed files.

Ah, perfect. Thanks for the hint. Was still on Emby.Server.Core 4.6.x, where this didn't existed... Now see it in 4.7.x Merci!

Hey, sorry for the extra effort regarding the genres. The mistake is mine. I saw last night that obviously some children's films also have the tag Films, so it looks mixed to me. I don't know when or how this happened, as I remember maintaining the tags that way. Thanks for explaining, especially with the overview, then I checked the tags. Many greetings Seger

Very soon. It is in Alpha testing.

Worked, switching from users is not that easy compares to the tv app... but looks a lot like the tv app... will keep it thanks Could the switching from users improved?

Did you even read this topic? I mean - it's not a long one. Maybe the last 3 posts at least - no?

I renamed nothing only that my new movies added emby takes them correctly no matter how they are renamed

I am good on disk performance as I am a really big fan of Seagate Exos 18TB X18 Enterprise and they can read and write faster than 280 MB/s. The shares that I don't have cached to my 3500MB/s SSD's still write directly at around 284MB/s they could be faster I don't know because 2.5G is the max for the network I have set up. Not to mention I don't waste my time with parity drives to slow down my system write speed because every component and disk inside my machine is new I think there is less than a .00001 percent chance of failure on these disks they are soo good.

Very cool. Also, you can use the 'Extra Type Banner Options' under the 'Style's section of the UI to move the colored banners to the bottom of your images, if you want to move them out of the way of your CoverArt icons.

HI, yes I think i vaguely recall this idea coming up once before.

Don't underestimate the interest in getting HWA if/when Emby introduces that feature-set. Right now it's just not needed to think about getting a card into the server, but as soon as emby can do AV1, to, for example, generate higher quality low-bandwith-streams, or can target HDR-live-transcoding, including fancy stuff like DV5 to HDR10, this might change. All that being said, there are good reasons here for why it's not rushed into the code to just have an interesting name-drop in the changelog.

Take a look at https://github.com/towel42-com/MediaManager its free, and is designed to work with emby to name your media correctly. Let me know if you have any issues.

By Google Tradutor..... ok. But I have problems with the native player running as a client on the Emby Android TV on the Mii Box S from xiaomi. Is weird. Using other players, if you leave HW active, the same happens. In them, if you set SW, it works normally. Another weird thing, it's not in all movies. Only in some that this happens. I've already contacted the support of the server I subscribe to, but they didn't help me at all. I'm very sad about this situation that I can't solve. VID_20220206_192141194.mp4

I guess we can never do it right: For many years, the extraction process took a long time under high CPU load: => Users complained about long library scans and the CPU load (one of the reasons to introduce throttling) Since two years, we have the new lightweight extraction which is 5 to 30 times faster without much CPU load => Now, users are concerned that the extraction process does not use all CPU processing resources...

Ah, now I understand - the alternative (fixed schedule at night) is just not very attractive and I'd agree to that. My primary point it that it should be decoupled from library scan - so instead of doing; Add Item >> 10 min extraction >> Add Item >> 10 min extraction >> Add Item >> 10 min extraction Rather do: >> Add Item >> Add Item >> Add Item || Check system usage || when idle, do: 10 min extraction >> 10 min extraction >> 10 min extraction ...when checking whether the system is in use or not (idle detection), there's no need for a late night task schedule But let's get back on topic: Image extraction is something that needs to happen in the background in the most efficient way that is possible and should not affect the users' system operations. This is not mean to be a benchmark or load-test for your many-core CPUs. There's not much CPU involved anyway (in case of quick extraction): We're mostly reading out the key frames and only when there are no suitable matches at a point in time, we're going into decoding a few frames in sequence. You should be much more concerned about your network usage when the media isn't local. ffmpeg threads parameter: You can completely forget about that. This is not some kind of global setting. When you specify that parameter, it will be matched to the closest component that supports multi-threading. And only applied to that one. So it might affect the audio deccoder at one time, and when you have a different audio-decoder next time, that doesn't support multi-threadiing, it might be applied to the video encoder instead. That setting shouldn't even exist in Emby and the parameter should not be used as long as you aren't hand-tuning a specific command line. But for us - supporting thousands of command line variations, it's impossible to manage the threads parameter. Eventually it will do more harm than anything else. You must scratch that idea once and for all. Parallel extractions would be a realistic option, but as mentioned above, there are other resources than CPU cores and Emby would surely not do something that could lead to a negative user experience. So I say "realistic" but probably "not reasonable". Maybe @Luke will share his thoughts about that..