All Activity

Done and wait ... thanks for fast support!

Hi, For some time now, I haven't been getting any theme.mp3 files for my TV shows and movies. It's actually a paid plugin – $8 – but as a premium user, it's supposedly free with full functionality. Has something changed, or am I misunderstanding something? I'm using version 4.10.0.20 beta. Is there any information about this, or is it just not working for me again?

I would ask the plugin dev.

The problem doesn't seem to be resolved yet. I've attached some screenshots in the hope that they might help better pinpoint what's happening. As shown in Figure 1, Emby is running in a floating window on the Samsung DeX desktop. After I click Play, the behavior shown in Figure 2 occurs: the video immediately takes over the entire external display instead of staying inside the Emby window. At this point, it cannot be controlled directly. The only way to interact with playback is through the Emby media controls in the notification panel on the phone. (Alternatively, as I mentioned in my original post, if playback is started from the Emby app on the phone instead of the DeX desktop, the playback controls on the phone can also control the video.) If I press Back (by bluetooth mouse or gesture provided by phone or DeX) at this point, it enters the state shown in Figure 3: the video closed and the Emby floating window becomes a black screen. However, the video is still playing in the background, and the playback controls can still be brought up, as shown in Figure 4. Pressing Back one more time returns to the original state shown in Figure 1 (see Figure 5). I hope these screenshots help narrow down the cause of the issue. Thank you very much for your help!

Hi all, For some time now, I haven't been getting any theme.mp3 files for my TV shows and movies. It's actually a paid plugin – $8 – but as a premium user, it's supposedly free with full functionality. Has something changed, or am I misunderstanding something? I'm using version 4.10.0.20 beta. Is there any information about this, or is it just not working for me again?

Thank you very much! Audio is working fine now.

@TecEmbryo Have a look at the documentation. Plugins Overview | Emby Documentation Emby Server Data Folder | Emby Documentation

Hi, Thanks for taking the time to create such helpful tools. They're exactly what I'm looking for. The "Theme TV Show Songs" in Emby seems to be broken; I haven't been getting any Theme.mp3 files for weeks. Your tool comes in very handy. But I'm already stuck at: "drop it into your Emby plugins folder, then restart the server." - I can barely turn my Synology NAS on and off - I need help with everything else. So how do I get the DLL into a plugin folder that I can't find? Can you help me with that?

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