All Activity

We are still waiting to hear back from them. You guys wanted a native package and so we are doing it right with the SDK they have provided, rather than just another wrapper around docker. But certain things like hardware acceleration are not possible without their support and so we are waiting on that.

So you must go through this on every server update then, right?

OK, would the normal docker install process be sufficient then?

Yes and it isn't just development, it is support. Android devices aren't built for direct network file access generally because it just isn't what they are used for. Only some devices (like the Shield) will even support it. And even then, it requires specific setup on the part of the end user to make it work properly. On top of that, there is only one field for the network path but Android devices will require a different style of value here than, say, a PC meaning now the single field cannot support both Android devices and an HTPC (where it is currently supported and arguably more useful just because of disc formats). All of those factors increase the support requirement for the option AND severely limit the number of people who will undertake the steps necessary to get it working properly and, even then, it could screw up other setups those same people have (an HTPC). Add to that the fact that there is no quality or performance benefit for the vast majority of situations and you end up with a very high cost low benefit feature. Us spending that time (not just development but also support) on it would be a very poor choice of resource use on our part. Okay, now I'm finished

This group is listed in the MusicBrainz database: https://musicbrainz.org/artist/c08ced1f-d248-4368-90e5-bf579b3bf5de Also Discogs: https://www.discogs.com/artist/620368-The-Firm-7 Though, in each case, it looks like there are many other Artists with the exact same name. There are at least 12 on MusicBrainz and at least 20 on Discogs. If you are only fetching from MusicBrainz, you could try adding the correct MusicBrainz ID to your embedded metadata and see if that helps with Emby fetching the correct Artist image? The AudioDB does have an image for The Firm: https://r2.theaudiodb.com/images/media/artist/thumb/wwz8yk1710398329.jpg What do you have here: What do you have here: Perhaps that gives some clues/ideas to check out???

HI, thanks for following up.

Hi, we are working on putting it together. Thanks.

No problem. Thanks for following up.

In the future the intention is to just remove the switch altogether and always have this activated. Thanks.

Hi, the intention is to make folders more obvious, but we will add options to control this. Thanks.

HI, thanks for following up.

Yes. that was recent addition to Folder view.

Hi, can you please show a specific example? Thanks.

Hello, I’m revisiting this topic because I’m having trouble with certain 4K files again; they are stuttering. Here is what I see in the logs. 17:34:14.748 [segment @ 000002234fcca240] Opening 'D:\Transcodage Emby\transcoding-temp\E6D0A3\E6D0A3.m3u8.tmp' for writing 17:34:14.749 SegmentComplete=video:0 Index=388 Start=1164.413222 End=1167.416222 Duration=3.003000 offset_pts=0 start_pts=1164413222 Frames=72 filename=E6D0A3_388.ts 17:34:14.749 [segment @ 000002234fcca240] Opening 'D:\Transcodage Emby\transcoding-temp\E6D0A3\E6D0A3_389.ts.tmp' for writing 17:34:14.749 [hevc @ 000002234fcbb5c0] RPU validation failed: 0 <= el_bit_depth_minus8 = 32 <= 8 17:34:14.749 [hevc @ 000002234fcbb5c0] Error parsing DOVI NAL unit. 17:34:14.752 [hevc @ 000002234fcbb5c0] RPU validation failed: 0 <= el_bit_depth_minus8 = 32 <= 8 17:34:14.752 [hevc @ 000002234fcbb5c0] Error parsing DOVI NAL unit. 17:34:14.755 [hevc @ 000002234fcbb5c0] RPU validation failed: 0 <= el_bit_depth_minus8 = 32 <= 8 17:34:14.755 [hevc @ 000002234fcbb5c0] Error parsing DOVI NAL unit. 17:34:14.755 [hevc @ 000002234fcbb5c0] RPU validation failed: 0 <= el_bit_depth_minus8 = 32 <= 8 17:34:14.755 [hevc @ 000002234fcbb5c0] Error parsing DOVI NAL unit. 17:34:14.760 [hevc @ 000002234fcbb5c0] RPU validation failed: 0 <= el_bit_depth_minus8 = 32 <= 8 17:34:14.760 [hevc @ 000002234fcbb5c0] Error parsing DOVI NAL unit. 17:34:14.763 [hevc @ 000002234fcbb5c0] RPU validation failed: 0 <= el_bit_depth_minus8 = 32 <= 8 17:34:14.763 [hevc @ 000002234fcbb5c0] Error parsing DOVI NAL unit. 17:34:14.764 [hevc @ 000002234fcbb5c0] RPU validation failed: 0 <= el_bit_depth_minus8 = 32 <= 8 17:34:14.764 [hevc @ 000002234fcbb5c0] Error parsing DOVI NAL unit. 17:34:14.767 [hevc @ 000002234fcbb5c0] RPU validation failed: 0 <= el_bit_depth_minus8 = 32 <= 8 17:34:14.767 [hevc @ 000002234fcbb5c0] Error parsing DOVI NAL unit. 17:34:14.768 Too many packets buffered for output stream 1:1. 17:34:14.914 Conversion failed! Any ideas? Thanks. Just to clarify, I installed the very latest version of the server.

@ebr I don't think it's quite that simple. You say @FrostByte saw no real benefit. What he actually said was that he didn't notice a big difference after Direct File Access was taken away. In the very same post he also said: “I'm sure a lot of people would prefer to use direct access if available. I would and did so when it was available.” If somebody used a feature and would prefer to use it again if it were available, then clearly that feature has value to him — even if losing it didn't make his system unusable. @yocker illustrates the other side of the problem. He's an experienced Emby user and Top Contributor, yet this discussion has only now made him curious about Direct File Access. He doesn't need it, and that's perfectly fine. But it demonstrates something important: low historical usage does not necessarily equal low potential interest. People cannot use, evaluate or request a feature they don't know exists — especially one that hasn't even been available on Android for years. Nobody here can prove that a large number of Android users would use Direct File Access today. But equally, I don't see how Emby can know that they wouldn't if the feature isn't available, isn't exposed to them and most users probably don't even know it ever existed. And that brings me to the “limited resources” argument. When Direct File Access was originally added to the Android TV app, @rbjtech was the one who persuaded you to implement it. If I remember correctly, he said at the time that the actual implementation took you about five minutes. Obviously Android has changed since then. I'm not claiming that restoring it today would take another five minutes. But before “limited resources” becomes the decisive argument, there's an obvious question: has anyone actually assessed how much work restoring Direct File Access on Android would require today? If you've looked at it and concluded that it would require substantial development and ongoing maintenance, that's a concrete resource argument. But if it hasn't been evaluated because the assumption is already that too few users would benefit, then “limited resources” isn't really the reason for not doing it. The prior decision that it isn't worth investigating is. And that creates a rather circular argument: Too few users used it → therefore it isn't worth restoring → therefore current users can't try it → therefore there can never be usage data showing that more users might want it. Perhaps the first step towards finding the “reason to reconsider” you mentioned wouldn't be development at all. It would simply be finding out how many users would actually want Direct File Access if it were available again. A poll or feature vote would cost considerably fewer development resources than either of us has already spent discussing whether there's any demand for it. Limited resources” is a perfectly valid argument — once we know that restoring the feature would actually require significant resources. Has that ever been established?

lol, BigBrother Microsoft won't allow that to work. If you change enough in your PC while running Windows they will make the assumption you are violating the terms of your license by installing Windows on another PC. Then there is the drivers mess just booting into a new hardware. Windows doesn't have the monolithic kernel like Linux, so it will complain a lot. But it can be done. You just might have to call Microsoft to activate the license on the new hardware. And yes, I literally mean call. It is a soul sucking call too. I am not trying to convince you to switch to Linux, obviously you have already dipped your toes into it since you have Kubuntu. But instead of setting aside a couple hours, you might want to set aside a couple days.

Oh right! That's a good alternative! Very thanks! If in future updates, developers may add a simple switch on/off in metadata will be cool! For now i will try your solution! Thanks mate

That is what I'm suggesting. If you add "IMAX" as the first genre in the movie it will show right here:

You specifically turned OFF DTS-HD?

Thanks for the reply. Getting 15 years out of the system that just died was awesome so I really don't mind spending a bit of money on a new one. I do/did have two systems in the rack, The current Emby, still running just fine on Win11 Pro, and the one that was the *arr stack, now dead, that was running kubuntu. I will shift the current Emby system to be the *arr stack and reinstall kubuntu, and then use the new parts to build a new, more powerful, Emby system that will still be on Win11 Pro. Fingers crossed there will not be too much issue when I fire up the new system with the exiting OS drive with Win11 Pro installed. I am not sure why I went with kubuntu a bunch of years ago, it has been great for sure, but I might look at just ubuntu for this round. Thanks again

I manually set all my album art via the ID3 tag per track. There is no folder.jpg or cover.jpg file. My file structure is Music\<artist names>\<album name>\<tracks>. The only files are the MP3 files. When I first ripped my CD, the program I used to rip it selected a bad piece of cover art. I manually replaced it with Mp3tag while I added the other information (I do this for ever album). I doubt it matters, but I don't think I have this problem with any other albums (it's possible, but if I do, I haven't noticed it), so maybe it does: the CD is The Firm, from The Firm. One other odd feature, the artist and album image is blank. I only see images for the individual tracks. This is not how it works for any other albums. Everyone else gets an Internet picture of the artist, but shows my manually added album art when looking at the individual tracks. Perhaps the database that Emby is using doesn't have The Firm in it? They may not be super well-known, but they're not that obscure (the other Jimmy Page band after Led Zeppelin and the Yardbirds, with Bad Company's singer), so that seems odd. But if the album is not listed, then where is it getting the wrong image? Is that still cached somewhere from the first scan? I have tried deleting the art from each track in Emby, then Scan Library. The bad art comes back. I have also removed the whole album folder, restarted Emby confirmed the album was gone, restarted the computer running it (a Windows 11 PC), then put the album folder back and again did Scan Library. The album re-appeared, the tracks again all had the old, bad image. I have also tried clicking the 3 dots next to the album and selecting Refresh Metadata, with and without flipping the switch for "Replace existing images." No effect. Under Settings -> Library -> Edit, I have the following settings (maybe one of these is the culprit), where any that I don't list are off/not selected: Import playlist files: On Enable real time monitoring: On Metadata Readers, Enable and rank your preferred local metadata sources in order of priority: Nfo On Album Metadata Downloaders: MusicBrainz On Artist Metadata Downloaders: MusicBrainz On After initial import, automatically refresh metadata from the internet: Never Artist Image Fetchers: FanArt On Song Image Fetchers: Embedded Images On as noted above, everything else is off or unchecked. What could be causing this problem and how would you recommend I fix it? If you need more information, please let me know what else to provide. Thanks for any help.

But you left out the fact the he saw no real benefit from it. We have limited resources and are choosing to work on things that will truly benefit a large number of our users. I've said this over and over again. This will be my last post on this topic until such time as we find a reason to reconsider it. Thanks.

Just chiming in as well. I use Emby for audiobooks daily, and the Android app remembers playback speed between tracks but the web version doesn't. So clearly Emby CAN remember playback speed, which makes me think no one has actually looked into it after 5+ years of requests.

Unless you can reproduce, I'm not sure what else to do here. It sounds like some sort of situation where Emby was still holding the media session in the background and so responded to your remote clicks.

Running ver 4.9.3.0 still and a couple weeks ago I switched out my Rokus and now have 3 Onn 4k streaming boxes (2 pros, 1 plus) and I haven't noticed the skip back anymore. I know others in this thread have reported it on different playback devices but just wanted to update my experiences.