Leaderboard

I think there might be an issue with the themoviedb.org API key in this version. 2026-05-19 22:12:38.397 Info HttpClient: GET https://api.themoviedb.org/3/person/886?api_key=‌f6bd687ffa63cd282b6ff2c6877f2669‌&append_to_response=credits,images,external_ids&language=en-US 2026-05-19 22:12:38.500 Info HttpClient: Http response 200 from https://api.themoviedb.org/3/person/886?api_key=‌f6bd687ffa63cd282b6ff2c6877f2669‌&append_to_response=credits,images,external_ids&language=en-US after 103ms 2026-05-19 22:12:38.501 Error App: Error in TheMovieDb *** Error Report *** Version: 4.9.5.0 Command line: C:\Program Files\EmbyServer\system\EmbyServer.dll Operating system: Microsoft Windows 10.0.26100 OS/Process: x64/x64 Framework: .NET 8.0.27 Runtime: C:/Program Files/EmbyServer/system/System.Private.CoreLib.dll Processor count: 20 Data path: C:\Program Files\EmbyServer\programdata Application path: C:\Program Files\EmbyServer\system System.Runtime.Serialization.SerializationException: System.Runtime.Serialization.SerializationException: Type definitions should start with a '{', expecting serialized type 'PersonResult', got string starting with: � ���n�Z�&x�O��Q�� �J��,y�<�s탍ErQ��A� Y>H at ServiceStack.Text.Common.DeserializeTypeRefJson.StringToType(ReadOnlySpan`1 strType, TypeConfig typeConfig, EmptyCtorDelegate ctorFn, KeyValuePair`2[] typeAccessors) in /home/runner/work/ServiceStack/ServiceStack/ServiceStack.Text/src/ServiceStack.Text/Common/DeserializeTypeRefJson.cs:line 28 at ServiceStack.Text.NetCoreMemory.Deserialize(MemoryStream memoryStream, Boolean fromPool, Type type, DeserializeStringSpanDelegate deserializer) in /home/runner/work/ServiceStack/ServiceStack/ServiceStack.Text/src/ServiceStack.Text/NetCoreMemory.cs:line 178 at ServiceStack.Text.NetCoreMemory.DeserializeAsync(Stream stream, Type type, DeserializeStringSpanDelegate deserializer) in /home/runner/work/ServiceStack/ServiceStack/ServiceStack.Text/src/ServiceStack.Text/NetCoreMemory.cs:line 173 at ServiceStack.Text.JsonSerializer.DeserializeFromStreamAsync[T](Stream stream) in /home/runner/work/ServiceStack/ServiceStack/ServiceStack.Text/src/ServiceStack.Text/JsonSerializer.cs:line 238 at Emby.Common.Implementations.Serialization.JsonSerializer.DeserializeFromStreamAsync[T](Stream stream) at MovieDb.MovieDbPersonProvider.FetchPersonResult(String id, String language, CancellationToken cancellationToken) at MovieDb.MovieDbPersonProvider.EnsurePersonInfo(String id, String language, IDirectoryService directoryService, CancellationToken cancellationToken) at MovieDb.MovieDbPersonProvider.GetMetadata(RemoteMetadataFetchOptions`1 options, CancellationToken cancellationToken) at Emby.Providers.Manager.MetadataService`2.ExecuteRemoteProviders(MetadataResult`1 temp, LibraryOptions libraryOptions, String logName, TIdType id, IRemoteMetadataProvider`2[] providers, MetadataRefreshOptions options, CancellationToken cancellationToken) Source: ServiceStack.Text TargetSite: System.Object StringToType(System.ReadOnlySpan`1[System.Char], ServiceStack.Text.TypeConfig, ServiceStack.EmptyCtorDelegate, System.Collections.Generic.KeyValuePair`2[System.String,ServiceStack.Text.Common.TypeAccessor][])

It's because of double compression: https://www.themoviedb.org/talk/6a0cf9a5dd8f54b8836a3750

@Lukeappears there's an issue with TheMovieDB fetcher. Multiple reports: https://emby.media/community/topic/147829-person-metadata-failing-to-identify-refresh/ https://emby.media/community/topic/147798-new-emby-server-release-4950/#findComment-1521535 Also confirmed it's happening on both stable and beta server versions.

Reading the Plex reddit there are lots of "So what? I already got the pass!" Yeah well.. Soon they will be Introducing Plex V2 mark my words! Better yet, it will no longer have any private server function and be a fully Netflix alternative where they just use private peoples computeres as servers. That price is nothing more than Plex phasing out the lifetime pass.

Remote Access Pass Price increase : PleX

These google streamers did have an inherit chipset flaw when it came to certain HEVC profiles. Adding a GTX 970 won't help as it can not handle HEVC either. What you might need to do is change your transcoding settings so that all HEVC content is transcoded to H264 or convert all your current HEVC content to H264 and stop grabbing HEVC content for now. If you do want to add a card, a Quadro P1000 would be ideal and it's cheaper than replacing your ancient server.

Server: 4.9.5.0 OS: WIN 11 Web Browser Is there something new with the search? was the Url always like this: /web/index.html#!/list/list.html?type=search because it looks different now: i don't get what i am looking for, i just get recommendations, and only if i scroll down i get the categories where i can filter what i am looking for: after scrolling down: but it is not showing anything, only if i click on tv shows, it is appearing: this is not really how the search worked and not really how i want it to work. Is there a way to remove this "list" view or get the cathegories back to the top? I think this is not how it should be right? Thanks

I love music visualizations. I was thinking that a unique way to integrate visualizations in Emby would be to encode the audio with the video output of a visualizer like Milkdrop or ProjectM. The mux can then be streamed to clients as video (if the client has enabled music visualizations). Wouldn't that be cool? Sure, you sacrifice a little quality in the transcode but it would still be acceptable and by offloading the visualization to the server, even underpowered clients could potentially support visualizations that would be impossible given their hardware.

Works like a charm! Sorry for the ruckus, the cache did the job, or better the emptying of it.

+1

Mostly realtime sync. ie kodi was online. Yesterday I turned on the theater box and saw it there too. tbh I did not specifically test offline Edit: Yesterday it could be that the library scan was long

Both. I noticed it with the boxes that were online at first. Yesterday I saw it in my theater which was off before.

Do you mean disconnecting from the incoming phone/fibre line, or cycling the mains power? As you mentioned Plex working, I should just mention that in situations where your internet setup is restricted, Plex may instead send your data via its own servers - you should be aware of this if privacy matters to you. Paul

I disagree that Emby setup should cover basic TCP/IP Networking its not their responsbility.

If you don't understand basic TCP/IP Networking you have no business trying to setup & maintain a home media server. I suggest you just pay for Netflix, Disney+, etc

A lot of work was done and I think the first mcp version can be used. https://github.com/Oratorian/emby-mcp-server it is highly optimized for smaller context models that are locally hostable for up to 12b. Models like Claude or other shouldn't have a problem either. Full readme with all tools available https://github.com/Oratorian/emby-mcp-server/blob/main/README.md

Looks like the root cause was/is at TMDB itself. API returning corrupted data instead of JSON - Talk — The Movie Database (TMDB)

There seems to be an issue with the Emby TMDB API key right now, stay tuned.

I said the same thing a year ago: For some reason, it didn't happen. Forum member Yocker nailed it when he said that people are willing to take a lot of abuse to stay with what is familiar. That's why Microsoft and Google keep eroding personal privacy and freedom. Plex is just taking a page from their playbook. I would love for Plex to collapse and go under because of this move. Not because I care about the company itself, but I want these type of business practices to fail.

Also can confirm after upgrading to Windows Server 4.9.5.0 I cannot Identify any new Movie or TV Show. I tried through IMDB and TMDB with correct paths that should have easily identified the Movie and or Television Show.

Same isue here, tmdb not fetching any data. System.Runtime.Serialization.SerializationException: System.Runtime.Serialization.SerializationException: Type definitions should start with a '{', expecting serialized type 'CompleteMovieData', got string starting with: ��}Ko�J��_a�u/������ۖ��eK��.A2(���|H� at ServiceStack.Text.Common.DeserializeTypeRefJson.StringToType(ReadOnlySpan`1 strType, TypeConfig typeConfig, EmptyCtorDelegate ctorFn, KeyValuePair`2[] typeAccessors) in /home/runner/work/ServiceStack/ServiceStack/ServiceStack.Text/src/ServiceStack.Text/Common/DeserializeTypeRefJson.cs:line 28 at ServiceStack.Text.JsonSerializer.DeserializeFromSpan(Type type, ReadOnlySpan`1 value) in /home/runner/work/ServiceStack/ServiceStack/ServiceStack.Text/src/ServiceStack.Text/JsonSerializer.cs:line 61 at ServiceStack.Text.NetCoreMemory.Deserialize(MemoryStream memoryStream, Boolean fromPool, Type type, DeserializeStringSpanDelegate deserializer) in /home/runner/work/ServiceStack/ServiceStack/ServiceStack.Text/src/ServiceStack.Text/NetCoreMemory.cs:line 184 at ServiceStack.Text.NetCoreMemory.DeserializeAsync(Stream stream, Type type, DeserializeStringSpanDelegate deserializer) in /home/runner/work/ServiceStack/ServiceStack/ServiceStack.Text/src/ServiceStack.Text/NetCoreMemory.cs:line 173 at ServiceStack.Text.JsonSerializer.DeserializeFromStreamAsync[T](Stream stream) in /home/runner/work/ServiceStack/ServiceStack/ServiceStack.Text/src/ServiceStack.Text/JsonSerializer.cs:line 238 at Emby.Common.Implementations.Serialization.JsonSerializer.DeserializeFromStreamAsync[T](Stream stream) at MovieDb.MovieDbProvider.FetchMainResult(String id, Boolean isTmdbId, String language, CancellationToken cancellationToken) at MovieDb.MovieDbImageProvider.GetMovieInfo(BaseItem item, String language, IJsonSerializer jsonSerializer, CancellationToken cancellationToken) at MovieDb.MovieDbImageProvider.GetImages(RemoteImageFetchOptions options, CancellationToken cancellationToken) at Emby.Providers.Manager.ProviderManager.GetImages(RemoteImageFetchOptions options, CancellationToken cancellationToken, IRemoteImageProvider provider, Int32 providerIndex)

The extracted subtitles are cached on the server, so it is probably still reading the version from the previous server version. Try deleting the subfolders in the server 'cache/subtitles' folder to force it to re-extract the subtitles and retest.

yep, it seems after the update tmdb cant work anymore, tvdb works fine

Hey, on Synology 7.2 updated from 4.9.3.0 to 4.9.5.0. After the update Emby rescanned the entire "Movies" library and did not identify the majority of the movies. I manually went to each movie to "Identify" the movie but it says "no items matching your search criteria were found"

Might be an update needed for TheMovieDB plugin with 4.9.5, or they're having issues with their service... These errors are definitely odd, even my text editor complained about weird characters. I can refresh metadata just fine on movies I added before, but I added a new one tonight (Double Dragon) and seeing errors like this when refreshing metadata or trying to view images for people. I'm in the process of ripping another movie, I'll see if that also shows the same errors on import. EDIT: Added another new movie and saw the same type of errors. It's like binary data isn't being converted properly. embyserver - 2026-05-20T003009.873.txt

HI, yes it is certainly a possibility. Thanks.

@Bob1969are you still having an issue with this?

Hi, can you try using Emby Server 4.9.5 and Emby for Android 3.5.36 ? Try downloading new content into the app. Thanks.

https://support.plex.tv/articles/sales-tax-information/ That 749.99 is also taxed. Plex taxes the lifetime license. In California for example it is $804 at the cheapest county and $815 in the most expensive. This is their way of saying, so long, and thanks for all the fish. They do not want to support older Plex pass users. Now people with a Plex pass already will feel more value for their previous purchase since they got such a discount earlier, while Plex themselves knows those people who didn't pay full price are now less entitled to their opinion. Whilst those who pay full price for the Plex pass at that ridiculous 749.99 earn some kind of reward for doing so. Where you get some extra something because you actually paid more. Expect that to happen too. The old Plex pass holders aren't entitled to that new something so aren't getting it. Get ready for it.

I bought a lifetime plex pass a LONG time ago for something around $200.00. I have no desire to downgrade to Plex but I do wonder if my old Plex Pass is still viable. They said it will never expire or lose functionality but Plex has been known to go back on promises or to change something so people have to make repeat purchases. As I said I have no desire to use Plex again but it does occur to me that, if they really do screw long time Plex Pass owners that just might dive some of their long time users away. While the price increase itself will not make long time users switch the failure to honor the implied agreements just might. However I believe that Plex only attracts the people that do not do any research when they desire a media manager. But Plex is always making a good living by adhering to H. L. Mencken's principal of "No One in This World Has Ever Lost Money by Underestimating the Intelligence of the Great Masses of the Plain People." This is the principal by which people from P.T. Barnum to Trump have amassed great fortunes. Plex is simply following in the footsteps of the great con artists. I can't really fault them for this as it is what has made America great. We are a country that rewards the con man better than we award our heroes. Of course a lot of our heroes are little more than con men (and women).

Im - however - still waiting...

Adding my vote to this as well

This price increase by Plex is freaking insane. I guess the millionaires that gave them money are demanding a return. Remember, they did get $50 million quite some time ago and were not exactly turning a profit.

Holy.. I thought Adobe were nuts! Next Plex announcement will be "We hear you about the price! Now you can get it for 45$ a month!!" Tricking people into thinking that will be cheaper. How can any one willingly start out with Plex today? Emby devs: You need to market Emby a bit more!

New Emby server Stable release, v4.9.5.0.

Hello ! i waited a ;long time before replying because i wanted to be sure, but it seems to be resolved !!! we didn't have the problem again since i deleted the weather addon ! !!!!!!!!!!! Thank you very much !!!!!!!!!

Lookeed like that worked. Content is playing what guide specified.... TY....

I agree. Everybody should be able to find their best compromise. Sometimes you feel it landed a bit one sided. Like your side got nothing, and the other side got their way. That is why I choose to avoid making decisions that way and find a way to code in something that pleases both sides. Having it card style spotlight diminishes the spotlight. Its just a card. Having the spotlight as fullscreen removes that card. Then you see the full image as expected. The bottom portion might be shaded a bit. But otherwise you should get a cleaner look without having other stuff in the view. With card style other cards to the left and right are there. Small slices of those other cards. The fullscreen style that isn't happening. It just provides a very clean way to show the spotlight. Allowing the image of the card style spotlight to also get changed to a different style would also be interesting. Because then the style of the card would dictate more the size of the card. You would need several sizes of the larger hero card to fit each different type of image. Since you wouldn't want that placeholder to show. Even then you couldn't predict some oddball images which would produce the placeholder effect. The zoom eliminates the oddball images and placeholder effect. That is why it was done. Because it was easier? Sure. Because it was the best way to do it? Sure. Because it isn't finished yet? Sure.. You can say that too. That is likely what happened. It just isn't finished yet and we are blaming it for things that haven't had time to be incorporated yet? Maybe? Probably? I am guessing so. I know lots of stuff has to get worked on at once and at the end of the day you only can do so much. So only so much time can be spent on certain things without other stuff falling behind. Lots of moving parts and you have to move with them. Eventually the spotlight will get something better and even I am unsure of what that may be. The future will tell us what that is. User demand will too. Your posts will help decide too. Thank you for the input.

I did (thank god) and every movie went into the right position. I still had to edit artwork and collections, but I managed everything in a few hours. When I used to have to start over it took 5 or 6 days! God bless nfo!

My issues have all been resolved. So far so good. And no, I have always been Trekdriver

I remember having a few metadata issues with older episodes of The 100 as well. Sometimes refreshing the library or replacing the episode file name with the exact TVDB format fixes it. Episode 13 was a really memorable finale though, so hopefully you got it working eventually.

I think the possibility is there for use if it actually worked. Maybe not worth the trouble to make it workable.

Yeah I think the settings were added in 2.0.5 so it hasn't been out for too long.

It's a third Playstate so that Shows, Movies, etc. no longer show on screen (when filtered). Most of us already filter to "Unplayed" on our servers so that we can easily choose what to watch next. By introducing "Not Interested" (), it would also remove these items from the Main Screen, such as Latest and Suggestions. If you ever wanted to see them again, you just filter back to "Any." There is no need for bickering or comments back and forth about deleting media or talking to your users. If you like the idea of hiding media with a new icon/playstate, please like the original post on Page 1. If you don't, please move on.

So I believe the real issue is the metadata associated with the file. Sometimes if you have moved data or changed PCs, this can occur. I deleted all .nfo files in all folders this was occurring and Emby immediately found them and recreated the meta data

Hey Emby community, I just released an update for Embywatch which will be available in 24-72 hours. Here are the changes: ## New - **Lidarr** just joined the crew to take care of your music libraries - **Downarr** is here to handle downloads so you don’t have to - Media playback is now unlocked for everyone (yes, really) - Remote session controls added (start, pause, stop, next, preview… you’re in control) - Fresh new options available for **Bazarr** --- ## Enhancement ### Fixes - Fixed the torrent loader spinner that sometimes forgot what it was doing - Fixed text alignment in the Discord verification screen (no more awkward centering) - Fixed titles and descriptions in the shop - Fixed validation issues for Seer/Jellyseerr requests in the dashboard widget - Fixed some quirks with Seer support requests

Hi, this is resolved for the next release of Emby Server and Emby for Samsung. Thanks.

HI, we are working on improving this. Thanks for the feedback.

Thanks... I will add this, and the real emby devs can correct me if I'm wrong, all HTTP MPEGTS streams will take AT LEAST 3.5 seconds to tune. That's where you start from. In the real world you can at a second or 2 for it to show up on a client best case scenario (I average about 8 total). There almost certainly seems to be a hardcoded 3.5 second buffer in there. And, oddly, from my testing, seems like HLS channel streams can be worse. This is because it *appears* emby will buffer X segments. If segments are 2 seconds long and it buffers 3 of them etc... it takes even longer. What I've learned (which I could be wrong), is that HLS segments split on i-frames and the intervals of those vary by broadcasters. So it's certainly going to be 3-6 seconds from a 'cold tune' to get legit HLS segments from OTA channels. Bottom line is, ANY media server that is "proxying" a stream from TVH, must buffer it so it can figure out what the stream is (video/audio codec etc) to send it to clients. And ffmpeg needs a solid 1-2 seconds at a minimum (IMO). If you want super fast tuning, you have to go after the mpegts stream directly via direct http connection to tvheadend... i.e. the "VLC player" way. The trade off there is you lose all the cool features of emby :-). The only other alternative I can think of is predictive or "cached" tuning. Keep multiple streams constantly connected/tuned to tvheadend - dumping the video data if no user is requesting the channel. Maintain an LRU buffer of channel streams and hand them out if a user requests it and you have it..... otherwise make TVH tune it and spin up a new stream (easier said than done ).The tvheadend plugin for Kodi seems to do something like this, I'm currently exploring that option. I'm also exploring if I could extend/create a tvh plugin based upon the old TVH plugin Luke has out there on github to try to do this stream cache/predictive tuning thing - but I would guess no matter what is done inside the plug in, the http stream would go through sharedhttppipelinesource - making the effort moot. All in all, it's a challenging technical problem and given the breadth of hardware&platforms emby supports - it can be daunting. I'll also say Emby's live tv implementation is the #1 reason I moved to it from plex and bought a lifetime pass. So I hope the devs that live and breathe this stuff have alot of great ideas in the dev pipeline to make quantum leap improvements :-).

This is the Nth time this issue is brought up here but has yet to be fixed by the Emby Team - it affects more than just Android, the Shuffle "randomization" is fundamentally flawed and makes it unusable, especially for large music libraries as it seems to "randomly" pick between Titles starting with 1 and Titles starting with A - its infuriating. How come this is still a thing @Luke? What is the reasoning behind "pseudo-random" Shuffle that only picks a minuscule subset of options? Please finally have a look into this, it affects all platforms and all players and all media types! further example posts of this BUG fix proposed a year ago by @visproduction "We are looking into this" has been commented by Luke for at least 2 years - so far ZILCH