All Activity

@soderlundOne issue that prevents me from using the "Add to home screen section" is the plugin's form fields don't align with Emby's form fields so the sync causes side effects. For example, the "view type" is configured in Emby as Spotlight, but when the plugin updates the section it changes it to cards. I think there are 1 or 2 other similar cases with dynamic media vs single collection.

Good morning & happy Hump Day Emby nerds

@roakuwhile I get that 4.10 beta was not supported, how about 4.11? What I see happening on my install on the latest beta is basically an image-processing storm. Iconic 2.8.2 generated 2,707 image-processing exceptions in one minute. A 50,000-line sample contained: - 2,717 Iconic image errors - Thousands of full NullReferenceException stack traces - Repeated failures inside Iconic.Services.LibrariesService.GetLibraryId This happens when Emby loads images for a screen. Iconic fails repeatedly, Emby writes enormous exception logs to disk, image processing backs up, and the interface becomes sluggish. When image requests stop, logging and the disk activity immediately fall again. When Emby requests an image: Iconic checks whether the item is a supported type. It calls Emby 4.11's GetCollectionFolders(item) to determine the item's library. Emby sometimes returns null. Iconic assumes it always receives an array and immediately iterates it. That throws the NullReferenceException in LibrariesService.GetLibraryId. Emby catches the failure, logs it, and repeats the same process for every affected image. That produced 2,707 failures in one minute on Emby. This is the same coding defect previously documented by you (I think): the method does not handle a null result from GetCollectionFolders. I'd be much obliged if you could mitigate this by a very small compatibility patch: var folders = _libraryManager.GetCollectionFolders(item); if (folders == null) return null; That should make Iconic safely bypass items for which Emby 4.11 cannot return a library. It preserves all supported Iconic behaviour and should stop the exception storm.

I really like the animated look of this, kodi does this, I'm going to make a coffee & read through this thread.

Every time I click on a plugin I want to install I get a spinning wheel of death and they never load, when I check the logs there is a 401 unauthorised error when attempting to connect to emboss servers to load the plugins. I have removed my Emby Premier key multiple times restarted the server and added it back, doesn't fix it, I have also cleared the cache that also doesn't fix it. Anyone else getting this? embyserver(2).txt

And that's the whole purpose of this plugin! You can already do that except you wont get the numbers on the posters. Here is a list I have made that you could use for 30 trending shows. https://mdblist.com/lists/soderlund91/trending_shows

I was coming on right now to post the exact same issue Just updated to 4.10.1.0 hoping it would resolve it. I'm not sure what logs would be helpful to provide. CFC

Hi Leute, ich benutze Emby seit ein paar Wochen und habe aber bisher noch keinen funktionierenden Windows Player gefunden. Die offizielle App funktioniert einfach nicht richtig sodass ich gezwungen bin via Browser zu schauen. Mich würde interessieren wie ihr das macht. Am Iphone und Apple funktioniert die App halbwegs gut. Grüße Lato

As said, it's not just limited to transcoding (or any playback in general) but is what seems to be the worst offender. Real puzzle for me if why Media library scan frees most of the memory when used. Anyway.. Not the biggest problem for now as a scheduled task set every 24 hours keeps it at bay for now.

New beta (v2.9.1.2) in the catalog. Plugin has been simplified a lot. On first install without any settings set, the plugin now just uses auto detection with Chroma/Hash detection on libraries assigned as TV shows or Mixed. That way less technical people can still use the plugin without having to worry about settings. Scheduled task is per default disabled. Settings have been pruned a lot to improve user friendliness. Would like some feed back on if scheduled task should only work on newly added videos or run through everything (as it is now it works like Embys intro skipper and just runs through everything). Not sure what would be best for people not very technical.

The only playback memory usage issue I have looked into is the Dashboard issue with not -in-view tab being suspended and the websocket playback update messages get queued using up a lot of memory after x hours - it is in this thread and there was a circumvention posted https://emby.media/community/topic/143699-memory-leak-49180/page/2/#findComment-1483968

What about the problem i have with memory usage rising with only a scheduled media library scan freeing that memory again? It seems almost the opposite of the others as a library scan actually frees the memory instead of using more. It's not limited to transcoding but that does seem to cause most of the memory "leak".

Reading from Emby's cache would be impossible as there's no way to know where precisely the images are stored by Emby and what they are called. The plugin only reacts and draws on what Emby hands over to it, basically Emby is in charge of what is happening. Disk access with the plugin is mostly up to how Emby hands over the poster. If a new poster has to be drawn, because someone browses the library, the disk should only wake in case Emby doesn't already have the drawn image. Two things that would wake the HDDs in your scenario. Posters haven't been drawn yet, then Emby it self will have to access to artwork for the videos on the HDDs. You use custom icons for EmbyIcons that are placed on the HDD. Many versions ago i tried making a scheduled task that could "warm up the cache" for Emby and EmbyIcons by going through all libraries and scanning for anything that wasn't already in the cache and then draw the posters. Maybe i could add something like that back. How ever, i never added it because it was a heavy operation that depending on the library sizes could take a long time.

Same for me too. Just a spinning circle

Your help on this helped me a lot in setting and preparing the case for the development team. Greatly appreciated The issue is in the queue for extensive development time to be available. I have been running tests using stubs media files based on user databases - users who encountered the issue. In my tests, these large databases do cause OOM crashes on NAS servers with limited memory. A test on ubuntu laptop with repeated scans is not showing a serious issue - memory usage reaching only 1Gb RSS after a month of continuous scanning. The platforms I have for testing with the stubs media at the moment are limited to Windows, Synology and Ubuntu.

Update : My test instance metadata were apparently not as clean as I thought, I regenerated them and I got chapters back on the same movie. I know now because I found some movies with chapters. Forget my previous post and thanks @kandiman

Thanks for a great plugin. I have an issue I was wondering if it's possible to fix. I have this enabled for all of my libraries so Emby clients can read from the SSD drive where I have Emby Server installed without waking my HDD array while browsing/searching etc while still keeping images in each of the media folders: With the EmbyIcons plugin enabled, searching/browsing wakes my drives: it reads the original images stored on my HDD array instead of the cached copies in the server's metadata folder on my SSD (Emby's "Cache images" library option keeps them in `/config/metadata/library/…/imagecache/`) as far as I can tell. Would it be possible to add an option to read all images from the server's cached metadata folder instead? Not sure if it's possible, but thought I'd ask, as it would stop drives from spinning up whenever I search for something that isn't already cached Running: Emby 4.10.1.0 in a docker container on Unraid, EmbyIcons 5.61.0.0

@Luke

This has been happening for a while for me now, ive waited a few Emby Windows updates to happen to see if it disappers, but hasnt, so rasing it here, Below is a good example of where its hapeing, all the broken image icons you can see. Everything else is working fine, all the guide data is coming in from XML TV net, all the channels icons are working ok.Emby Windows 2.317.2.0 Server: 4.10.1.0 Thanks for your help

On my LG and Samsung TV's chapter view is still there I can also see it on web.

Hello ^^, I am experiencing the same issue on a TCL C935 (Google TV) and a Sony XR-55A95K (Google TV) when switching between Emby for Android TV and Emby for Android. embyserver-63926356251.txt embyserver.txt hardware_detection-63926356255.txt

Readded Awards. But now just Oscar and Emmy wins from OMDB instead of unreliably, slow and throttled Wikidata API. Total wins and nominations are shown when hovering over the award section. Just replace the dll in plugin folder and restart server. Note: Just tested with Chromium based browsers. FF may be a bit misaligned. Emby.SpotlightWebMod.dll

Thank you! Loving it. It would be perfect if we could then link to a movie or series if it's in our library.

Hi there, I've just noticed in v 4.10.1.0, the "chapter" view is gone (web + Android app at least) On web, I tested it in an incognito tab and tested both of my instances in there, in 4.10.0.0, it is there, in 4.10.1.0 it's gone. Can anybody confirm that? Should not be a new feature for a "bug fix" version bump IMHO 4.10.0.0: 4.10.1.0:

A little more news, because I know several of you have been following this from the beginning. XCstream has reached the point where I’m comfortable saying that there will be a standalone public beta. What started as an Emby-focused watchdog has evolved into something much narrower and, I think, much more useful: a dedicated MPEG-TS live-stream continuity engine. The biggest change along the way has been pass-through. Earlier in development I expected hardware transcoding to be the safest default. Real-world testing changed my mind. XCstream can now remux, buffer, validate, monitor and recover a live stream while preserving the original video and audio whenever possible. A dedicated GPU is no longer required for normal operation. That is a pretty significant shift from where this project started. I also want to give a big thank-you to Nick (Fyb3roptik) and the Kernel Media Server project. Nick has been incredibly open to testing XCstream, challenging the integration, and helping turn the direct handoff model from an idea into something running against a real media server. He’s also been very supportive of XCstream continuing as an independent project, which I genuinely appreciate. That work helped prove something important: XCstream does not need to own the media server. A media server can simply select the source and hand it to XCstream at tune time. From there, the responsibilities become very clean: Media server: users, lineup, EPG, scheduling, DVR and playback XCstream: source connection, buffering, validation, outage containment, recovery and MPEG-TS continuity That model is now working, and I think it creates a very interesting opportunity for Emby as well. Rather than requiring an Emby-specific plugin or asking Emby to take responsibility for unreliable upstream IPTV behavior, Emby could choose the source at tune time and hand it directly to XCstream. XCstream would return one stable MPEG-TS session while Emby continues doing what it already does best. So I’d like to extend an open invitation to @Luke, @ebrand the Emby team: if that architecture is interesting to you, I’d genuinely like to work together on a native direct integration. To be clear, XCstream will also remain usable independently. Nobody will need to wait for a media-server integration in order to use it. The original goal of this thread hasn’t changed: A bad IPTV source should not automatically mean a failed playback session or a ruined recording. What has changed is how much simpler the answer has become. Keep the original media when it’s good. Intervene only when it isn’t. Keep the session alive. Let the media server be the media server. That’s where XCstream is heading. And yes—I’m looking forward to finally getting this into some of your hands.