Leaderboard

Decided to see what Chat GPT could do for some new library icons.

I’ve also been running into this issue for about a month or two now. It seems to happen on some of my mkv files but not others. All of them have their subtitles embedded in the mkv container. All mkv files are direct played over WiFi The subtitles disappear for a short duration before returning to the episode/movie summary page or the Emby app crashes to the Apple TV Home Screen The issue only seems to be occurring on my tvOS app(WiFi), not on my iOS client(WiFi), browser(WiFi/ethernet), or Emby for windows clients(ethernet) running Emby server 4.9.3.0 tvos 26.4 latest Emby app ios 26.4 latest Emby app windows 11 25h2 latest Emby for windows clients

Just wanted to share this Ratings Sync plugin. Seems to work well. I'm not the author nor associated with them. Just thought folks would find it useful.

Hello all, I want to make some observations about the metadata management in Emby. I'm not trying to nit-pick, and I appreciate all the efforts by the developers, and help they provide. I left Plex a long time ago, and never looked back. But I did so because they focused more on becoming a streaming service, than a personal media server. I love Emby, and I don't want to see it make the same mistakes, since they seem to focus a lot of resources on Live TV and DVR features, rather than fixing basic things which are essential to storing and curating your own media. Again, not trying to beat anyone up, I just want to express my opinion because others may share it and I want Emby to succeed long term. I think metadata should be the core focus of a personal media platform. After all, the whole point of putting all your movies, TV, home videos, audio books, family photos, etc... in one place, is to make a single location with all the information about your media. That's content, and metadata... all in one place. Let's take one music example I have been experimenting with, because it's a simple "one artist/album/track" example. I have a CD Single from the group "XTC" called "The Ballad Of Peter Pumpkinhead". The CD has a few songs, but I only ripped the main song because it's all I cared about. So what I have is an artist ("XTC"), with one song off the album ("The Ballad Of Peter Pumpkinhead"). Now first, both TheAudioDB and MusicBrainz has the main genre for the artist as "New Wave", but Emby chose to set the genre as "Alternative", because that's embedded in the one track I have (used Picard long ago, genre may have changed since). So I edited the artist and added all the genres the sites reported. These edits saved to the NFO, but only three show in the GUI. I also added a custom image to the song as you can see in the first screen shot. Now I have two servers, and because Emby does not save or read the changes at the song level, this information is never noticed by the second server. The custom image is not saved alongside the MP3 ("The Ballad Of Peter Pumpkinhead.jpg" for example), so the image is never picked up by the second server. In fact, the edited genres never propagate to the other server either, even after a scan library or refresh metadata. And vice versa. All the genres are in the NFO, but Emby doesn't pull them in on refresh. In fact, a refresh of the metadata on the server with the correct genres, doesn't even create the additional genres in the library. "XTC" should show under all five genres from the screenshot above, but it's still only under the first... "New Wave". There are similar inconsistencies and annoyances all across the different library types... My point with all this is that Emby needs to incorporate metadata all the way, and it doesn't. It covers the average user who drops an album into a folder, and it pulls in the artist and album data. But even then in some cases, it doesn't save the data to the NFO correctly, although @Luke helped me a bit with this and it's better than before. While some of it is API issues, or other things outside the developers control, most of this could be solved if we committed to embracing the idea that "all data makes it to disk". Because aside from the complication of running two servers which most don't, this also affects someone rebuilding a server for whatever reason. All that support cost when people lose what they had because paths are different or whatever. The endless complication THAT creates is fixed if Emby acted like this... The server notices an album a user added. ---> Is there an "album.nfo"? If so, read it and pull in what's there. Use providers to fill missing information. ---> No NFO? Use the providers and write one. ---> Is there a "folder.jpg"? If so, read it and pull in what's there, otherwise get images from providers. ---> Is there an "artist.nfo"? If so, read it and pull in what's there. Use providers to fill missing information. ---> No NFO? Use the providers and write one. ---> Is there a "folder.jpg" and others? If so, read them and pull in what's there, otherwise get artist images from providers. Now for the missing part... ---> Is there a "The Ballad Of Peter Pumpkinhead.nfo"? If so, pull it in, otherwise write one. If no API provides this, write a blank one and we can customize if we want. ---> Is there a "The Ballad Of Peter Pumpkinhead.jpg"? If so, pull it in. If not, write the album image from its parent album. I even think that we should be able to write multiple images for things like movie covers, music album covers, etc... where it makes sense. Just like the backgrounds for movies and television, they can change every so often. Why limit a user to one movie poster when there are so many awesome pieces of artwork you can collect? ---> For movies, "poster1.jpg", "poster2.jpg", "poster3.jpg", etc... ---> Same for TV shows, music albums, etc... Where it makes the most sense. Being complete like this means that any customization we do, stays. On multiple systems, across rebuilds, everywhere... There's so much valuable information we could add to our media, but we can't, or don't because we're afraid we'll just lose it all one day anyway, so why bother? Things like... ---> Custom artwork for movies, TV shows, music tracks, etc... ---> NFO's written from image names in a photo library can store descriptions of what the photo is from, location, dates, etc... ---> Music tracks can contain descriptions of the inspiration of a song, or other interesting facts that can end up in the GUI down the road. ---> Etc... Etc... The TLDR is that EVERY library should be allowed to follow the same guidelines if the appropriate options are selected in the settings. If there's an NFO and images, pull them in. If there's not, write them. Stored permanently, right with your media. Every customization saved, every time. This is a fundamental function for anyone doing more than downloading stuff online and dropping it into a folder. Some of us actually want to curate the family photos so we can do what a media server is supposed to... share it with family and friends. My mother should be able to see the Christmas photos in the family photo album, and have a caption about it explaining things. She should be able to stream the home movies with a caption about what the video is about. And on and on. Now again, I'm not beating anyone up. I know this stuff isn't always simple. But in this particular case, it's FUNDAMENTAL to what a media server is for... presenting your media. If nothing else, your customizations should stick. Consistently. Without fear of them being wiped by accident somehow. I love the project, and I'd be willing to help one-on-one with any of the developers with ideas. I'm not a programmer, so all I can do is report bugs and offer opinions from a user perspective. That's why I'm submitting this... These are real issues for me, and a lot of what I read from feature requests and such, are similar issues. I'd be happy to submit more details and answer questions about it. I'll wrap up by saying that I think the consistency of metadata should be given focus. For me, it's the weak point. Others may not think it's a huge issue, but for me, it does matter. A lot. Thank you, and I appreciate the hard work that goes into everything.

in my testing depending on protocols, specified ports and domains I got all of those behaviors when using http redirects: * http/https protocol error * generic connection error after timeout * see user list, when click on any user get something along the lines of "access key expired" * fully works besides the library scan button and maybe some others, which fail with some analog if 404 (that one when redirecting from one https domain to another) also, I'm pretty sure that http in server list is just a harmless visual bug and the app actually tries 443 before 80, because http->https redirect is the one that I never made work no matter what. All tested on the same android app

The devs would have to answer this. Apps don't necessarily follow the HTTP redirects the way browsers do. Then you have the challenge of many apps on multiple platforms. Would all of them honor the same method or only specific ones? Would each app flavor need a different way of doing it? If you can get them to enter a URL to include https:// and clear the port then the app will try to connect on 443. At least the Android app does this.

Hi, Just wanted to say thanks for this amazing plugin. This with the new emby spotlight feature really make my home screen so much better.

Yeah, learned that the hard way a couple of years ago

If its for unRaid, remember to get your HBA flashed as IT mode. Other wise you can't use it with your array.

Yeah, it's not in the catalog if that's where you looked.

Tbh i see no reason to spend money on a quadro card when the old card i have does the job. Besides, i'm in the process of moving my Emby server to another small computer with a Intel CPU that can handle the transcodes as well. Doing this so i can do some heavy stuff on the main server without affecting Emby and freeing PCI lanes for a HBA card.

I thought it was pretty clear to be honest. I am using the Stacked option for collections. If collection has 4 or less items in it the first at at the top of the collection image. If collection has more than 4 items in it the first is no longer at the top of the image collection.

This occurs on iPhone 15 Pro Max in the native Emby app too. Dev team is there any reason why this isnt patched already?

HI, yes that is a false positive. good catch.

This is a very old version which does not support the new home screen, you will need to join the beta program, or side load to install the latest. 2.1.46 is the latest: https://emby.media/community/topic/42240-emby-android-tv-release-notes-beta/ Alternatively, you can install the latest standard Android app (also available via the Play Store on the same device) both apps can run side by side, and both latest versions have support for the new home screen enhancements.

Hello, AppleTV app version 2.0.6 (3) has undone the correction that 2.0.5 (3) solved. Is it possible to reimplement the fix from 2.0.5 (3) back into the AppleTV Emby App?

thanks for your patience so technically one is able to build a client app which is able to playback live tv from an Emby Server without coding that in?

No need to apologize. Just AI generated anyway because i was too lazy. Maybe if i wasn't so lazy...

So for music at least, I can confirm that the track level appears to be the key. I know that we could always go in and manually edit the files directly using tagging software, but that is a huge undertaking when we already have a GUI for editing in Emby, and we have thousands and thousands of tracks. I added "Doo-Wop" and "Rock & Roll" as genres to one song ("Blue Moon") using the GUI to the "Grease" album, and the genres did populate upwards for the album, and write to the "album.nfo" file. That also created the corresponding genres on the genre tab. So for music at least, a good start would be to have the metadata scanners do this... ---> No "Song Name.nfo", write the NFO using what's in the tracks tags, as already expected. ---> Existing "Song Name.nfo"? Import that information since it was created previously, and may have been customized by the user. Then treat images the same way... ---> No "Song Name.jpg"? Write the embedded image if present in the file, otherwise write the image from the parent album as "Song Name.jpg". ---> Existing "Song Name.jpg"? Import that image, since it may have been customized. This scenario would make it so that the tags and images were written to disk in an NFO or image file, and anything that gets customized later by a user would be permanently stored. It would fix issues when a server needs to be rebuilt, and allow for the storing of images and metadata outside the internal server database making it easier for being backed up and restored. I already mentioned this here... This seems like a rational place to start for music. Have a great weekend.

I found the BUG! The serie which causes the issue is 'Yakamoz S-245 (2022) [tmdb-195930]'. The scan creates one serie 'NOUVEAUTES' with one episode 245! If i rename the serie to 'Yakamoz (2022) [tmdb-195930]' then the scan works and finds the correct serie! So i guess the issue is caused by 'S-245' in the name of the folder serie.

This shouldn’t be an issue. The server shrinks them as needed.

Your solution worked. Thanks

Oh, I get it... You gotta be careful not to break all the random setups out there. I'm posting this with all due respect. You guys are always helpful. And I see you don't sleep either. LOL I would say that for music, the server would be starting with an album getting added. We don't create the artists on our own. So the server would see an album get added. I think it just comes down to the order the refresh of metadata takes. ---> Read the individual tracks (MP3, FLAC...) and extract the artist/album information. Write the NFO's for artist/album as you do currently (with updated plugin)... ---> Write the "The Ballad Of Peter Pumpkinhead.nfo" using what Emby already does a great job of extracting and compiling. But as I was discussing, in this case a "Soundtrack" album has caused all the songs on this album to be "Soundtrack" for a genre. No problem. Nothing would change from how you do it now INITIALLY, because the API's probably aren't pulling that detail anyhow. The tracks first get written with "Soundtrack" as a genre. That's fine. What I'm saying is that any information I add from the GUI for the track (genres, descriptions, etc...), should be respected by Emby. This album has songs which are "Rock & Roll", "Doo-Wop", "Instrumental", etc... If I go into the track metadata in the GUI and add those genres, the respective songs should appear in the genre categories. As it is now, if I shuffled, say, the Disco genre... no Disco songs from a soundtrack album would be included. The most detail is always going to come from the most granular item, which is a track for the case of a music library. In the above album, playing "Beauty School Dropout" should display "Various Artists" as the performer. It should show "Frankie Avalon". I hope I'm making sense... I did just confirm that if I add genres at the track level in the GUI, the genre gets created/respected in the genre category screen. The issue is that the information is not written to "track_name.nfo" to be preserved. A server failure, and I'm at the mercy of restoring somehow to get all those customizations back. That's why I'm proposing extending NFO and JPG support at the track level. Custom metadata and images needs to be saved to the disk, not just in an enormous database on the server. Also, the second server still doesn't pull in the genres on the item page from the existing NFO. On the second server, those 5 genres don't display on the artist screen, even though the "artist.nfo" file has them all. In that case, a metadata refresh doesn't pull in what's there. It's all inconsistent, which is the reason I'm starting a discussion about it. I'm calling it a night. Have a good night, and thanks.

Don't know how I missed that. Now they all show on the item, but I was more concerned that even with 5 genres for that artist, the genres aren't being created here... I went through on one server and set custom artwork, because as I mentioned in another post, the automatically generated collages weren't happening for some, or updating on all of them. This is much better than the missing art on some.

Hi, this is exactly how the server behaves with nfo files. Albums and artists are an exception but we've covered that elsewhere. You just have to use the provided nfo plugin build. However, tracks can have embedded information about the album as well and this is where things can get messy because users expect that to be utilized.

What do you mean by that? Example images and OP's explanation make it quite clear IMHO: Collection primary image does not show first item poster/primary image as first image in the stack if collection has 4+ items; collections with 4 items or less do display it properly.

Okay an update to fix this will go out early next week (that is the fastest we can go with the Roku store - they don't work weekends). At that time you can go back to your original setup but I strongly suggest you investigate some of the other home screen row options we have available. They can vastly improve your Emby experience IMO. This will especially be true with the next server release. Thanks for the troubleshooting. It helped get this solved quickly.

@wixwonkityuntil we can push a fix out, you can make your home screen load by adding any other section to it. Put a "Continue Watching" section below your My Media and everything should load for you. Everyone else - do you all have this exact same setup? Nothing on home except "My Media"?

Hi, it has been a long while. I understand the frustration. I will send the same message here that I have been trying to send to users of this plugin. Due to unforeseen life circumstances, I haven't be able to be part of this amazing community for many years now. Boy, do I miss writing code for Emby, what a great time it was, and I look back on it fondly as a high point in my life. Meeting great people, and writing code that people actually liked. I'll make this plugin repo public on my GitHub, for anyone who would like to take it on, or any of the emby plugins posted there. Thank you again to all for an absolutely amazing decade of writing code, and allowing me to take part. It really was a great ride! Thank you. chefbennyj.

Any updates since December last year ? First M1 has been released 6 years ago and still no proper support of hardware acceleration on the Mac Mini which is probably the best suited machine to host an Emby server.

Very good plugin, using it for about a month already. Recommended for everyone who wants to resolve ratings updates once for all....

With the increase in tag use in the latest stable version, can we now get bulk editing for metadata? I'd like to tag channels, but I have no interest in individually setting tags for 30+ channels.

Community has done more engineering effort on hardware acceleration in the past few days than Emby has done in the past 5 years.

Hi. A fix will be out early this week. Thanks.

Plex claims to support Apple Silicon hardware acceleration, but it's still a work-in-progress. While the feature isn’t smoke and mirrors, it’s not fully reliable yet. The checkbox may give the impression of working support, but the reality is that it’s still in beta, with mixed results depending on your setup. If stability is a priority, it might be best to wait for more mature support or stick with Intel-based solutions for now.