All Activity

Absolutely, no.

I imagine that everyday. Though I know it will not happen

were you able to reproduce the issue?

so, close the topic?

Agree, it's going to be a manually thing if anything plus I'm going to ask the people behind theintrodb before even considering it.

Please try the beta or the standard app. This issue only affects a very small percentage of people and was not picked up by any beta testers.

I posted it yesterday and Google released it last night.

Just my 2c - you gotta be really careful with this because that is basically going to be viewed as sending personal information about the media off of the device to ....wherever. Which is just a really sticky thing these days.

Hi, there's already an open request for this or something functionally equivalent. Please join in and contribute to the existing discussion at:

There is plenty of discussion in this topic of why this is far from a straightforward thing to do in a personal media server environment vs one with centralized, shared media.

I wanted to open a feature request to incorporate ComSkip - the commercial eliminator software for recorded Live-TV into Emby. I did a search and did not find anything like this. I don't even know if this is possible, other than Dispatcharr incorporated it. So maybe it is only possible with Docker? https://github.com/erikkaashoek/Comskip Seems to work pretty well under Dispatcharr.

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, or 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.