All Activity

I have been looking into the diagnostics from @DiabboVerdde The issue with memory climbing when scans are very frequent - like in this case being every 30 minutes is a known issue and the advice for now is to have long gap between scans - like 24 hours What I was looking into is to see if there are clues as to why these repeated scans do not always lead to memory shooting up. The specific case I looked into where debug logging was enabled throughout the period was this Memory started climbing on scan 19 - so the first 18 scans memory usage was ok Unfortunately the logs do not show anything different between period when scan 18 ran and when scan 19 resulted in memory shooting up I have referred it to the development team and will see if we can replicate with a copy of the database and dummy media stubs

@ebr, I noticed v2.1.50g has been released via Play Store that seems to have fixed it. I'm assuming you figured out the issue? Thank you.

AV1 really is a shit show compatibility wise. No one seems to want to support it, out at least be seen doing it, other than Intel.

As I have said, internal works fine so that section of the linked article is a Tick. I have also confirmed that Remote Access is enabled both in the Networks tab and for 2 users. Enable automatic port mapping is enabled. I have tried it disabled as well as the article says turn off if it doesn't work and a manual port forward is defined. It doesn't work either way. UPnP is enabled on the router. Server IP is static (and as a precaution also reserved in the router). I only have one router. FYI I have a static public WAN address. I am not running a VPN. Remote access fails on Windows machines with firewall turned off, and on my phone (which used to work). Tracert to google DNS servers shows no 172.x.x.x/24 devices in the route. I cannot find my EmbyConbect ID - its not shown anywhere I can see when I log in yo emby.media (which just brings me to the foruns).

OH, I see that I asked that 2023, still waiting for an answer

Server and client - Emby Server: 4.9.5.0 - Client: Emby for Android 3.5.37 - Device: Amazon Fire TV (Android 7.1.2) - Content: Live TV, direct stream (MPEG-TS) - Date: 17 July 2026 - Reported block: approximately 12:05 CEST (10:05 UTC) Description During Live TV playback, Emby for Android entered what appears to be a request/retry loop. The client requested the same item endpoint approximately once per second: GET /emby/Users/USER_ID/Items/ITEM_ID The sanitized reverse-proxy log contains 238 requests for this endpoint in the supplied extract. The continuous burst runs from 10:00:00 through 10:03:55 UTC (12:00:00 through 12:03:55 CEST). Requests that reached the origin received HTTP 200 with the same response size (mostly 1321 bytes) and normally completed in 1-2 ms. After this burst, our IDS/security script blocked matching requests as a protective reaction to the unusual request rate. Requests rejected by this security layer do not appear in the origin reverse-proxy or Emby logs. The security block is a consequence of the request loop, not the issue being reported. At the same time, POST /emby/Sessions/Playing/Progress from the same device continued to reach Emby every approximately ten seconds and returned HTTP 204, including at 12:05:06 CEST. Therefore the Emby session and authentication remained active while the visible problem occurred. The existing video request remained open until 12:11:00 CEST. The Emby server log then reports "Response completed after client disconnected", followed by Pause and Playing/Stopped from the Android client. Important logging limitation The normal Emby server log does not contain the repeated GET /emby/Users/USER_ID/Items/ITEM_ID requests at all. It contains the PlaybackInfo calls and the Playing/Progress calls, but this particular item endpoint is apparently not written at the normal log level. For that reason, the request loop is demonstrated by the attached reverse-proxy access log rather than by the Emby server log. Expected behavior The Android client should not continuously request the same item endpoint once per second during normal Live TV playback, and it should not remain in a retry loop until an upstream rate limit is triggered. Actual behavior The same item was requested approximately once per second for almost four minutes. The UI/playback appeared blocked at approximately 12:05 CEST. Playstate heartbeats continued successfully, and the client finally disconnected the media request at 12:11 CEST. Attachments - 01-reverse-proxy-access-sanitized.log: affected-client requests in chronological order - 02-emby-server-sanitized.log: playback start, progress around the incident, and disconnect - 03-log-correlation.txt: timeline and explanation of the different time zones I would like to know why the Android client repeatedly polls the same /Users/{UserId}/Items/{ItemId} endpoint during playback. 01-reverse-proxy-access-sanitized.log 02-emby-server-sanitized.log 03-log-correlation.txt

Any solution?

For the LAN, yes, but that's still the same default port and didn't change when implementing the reverse proxy. The WAN only shows my domain and no port at all.

+1 on this issue. Infuriating that this software would be released without thorough testing. Nvidia Shield Emby app Emby server running in Docker

Agree with the others. That soundbar is very good as far as soundbars go and should support everything you have for sound as long as you hook it up like we suggested. I've got mine setup like that with my Shield and Xbox going into my Samsung soundbar and e-ARC out to the TV. My soundbar displays the ATMOS or DTSX symbols for all my movies/series even my Atmos music files work. And definitely get the Shield Pro 2019. The tube is only 32 bit, has less memory, etc and will struggle at times. I've seen a lot of people in the forum return the tube style because they were unhappy and then get the Pro. As long as you stay away from anything compressed with AV1 you will most likely never see any transcoding again either.

For some reason, I can't reproduce it anymore. On the evening I tested it, it was still reproducible. So that's settled.

Log files attached. I was testing various files on the TV between 12-1pm yesterday embyserver.txt hardware_detection-63919805713.txt

This last link posted by user xyk0 works, I just checked it.

Canada has over 800 fires burning, if you are in the USA stay 6 feet apart and get the smoke vaccine Stay safe.

Then let me explain. Im a stickler for my library setup when it comes to visual metadata, so i have come to the solution that there are only a few Emby plugins that i feel can add to this, @yockerEmbyIcons is one example of a plugin that i find AWESOME when it comes to this and that i always use. I use solutions outside of Emby, often in Docker, beacause they offer options that Emby and/or plugins cant, these are for example Posterizarr and TCM (pics attached of examples) first and foremost and for scraping i use Mediaelch and TMM beacause they offer both a large degree of manual control of what to scrape and the use of overlays that i can create and control on season posters, posters, titlecards etc.. I do feel that Emby Metadata scraping is somewhat flaky and some settings, once made, for some reason gets reversed and i havent figured out why, the "padlock" function is one example. Thats no diss towards Emby as a mediaserver, i pay, and keep paying, for the service for a reason but when it comes to this part i just like to be in 100% control and limiting Emby to basically reading NFO files for correct metadata so these services can do what they do is a solution that suits me, thats all, and Emby gives me the option of implementing these services. A couple of years of daily use has landed me there. Hope that cleared it up. /N.

New Emby server Beta release, v4.10.0.20.

Windows Server 2019 Essentials

Hi, what version of windows are you on?

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

Is this option available yet? or any update ? infuse can also do direct play av1 from same emby server with no hardware support.

I think people need to be more transparent on full hardware specs. Clearly you aren't using 50 of those drives SN850x to get to your storages capacity. If you are just saying the db location matters... Maybe it doesn't. My db is on a single nvme enterprise drive. VR000480KXLXF at any rate a nvme with a db should be plenty fast to not crash like people say it is. my point is people need to give 100% specs to ther sys who have this issue. ------------------ the zero response from emby in the last month is garbage.

Aliens in Alaska

Me and my 2TB SN850x are definitely triggered.... No but honestly it's been really hard to nail down a correlation between the Emby instance and if the person is having this issue. Either things are perfect, or their server melts down on every search. If anything, the content type might be a possible hint. I don't think movies/shows have nearly as many tags to index/search compared to music. In my case I have ~2 million songs that are all run through MusicBrainz, so a single track can have a bunch of performer/composer/artist tags to read and index. My library size is barely double yours, but my database size is 8x.

I agree and it's the reason I got more hard drives while some people like newsgroups I like to copy 4k discs to my computer even though the file size is big the quality is good and emby plays them perfectly. I think eventually they may stop making dvd's but I hope they don't.

Dev's will need logs.