All Activity

Hi. I think one of the other image tagging plugins may do what you want but CA does not have customizations for things like this.

great ! Thanks for the feedback

Listen to me, that port that you have open 8096 also 8092 is an open door to your entire network. Just that one computer with 8096 open what they do is gain control of that and use that pc to hack everything else in your house like cell phones tablets whatever, that pc with port 8096 open gave them a key to your house. close all ports never open ports on a modem/router NEVER

FYI you could get to the guide with the channel still playing by just pressing "up" during playback. Will make it even a bit quicker.

Long story short your on windows and your pc is hacked/ratted/pwnt. Your going to eventually need to format that pc wipe it clean so unplug from the net get all your pics family photos etc.... Do yourself a favor download Ubuntu and use linux and put windows behind you

Done. But should I close 8096 off on my router? Or do I really need that for remote play?

All 3 hide them

Hi. We cannot give you permission to use our trademarks. Thanks.

I removed it. Just not sure what Frank means about the hide the ember users. Should I not have the ports open, thought i needed them for remote viewing? Malwarebytes www.malwarebytes.com -Log Details- Protection Event Date: 9/14/2026 Protection Event Time: 12:44 AM Log File: ea7edfd6-aff6-11f1-bbb3-2cf05d390d60.json -Software Information- Version: 5.7.0.328 Components Version: 164.0.5736 Update Package Version: 1.0.114526 License: Trial -System Information- OS: Windows 11 (Build 26200.9445) CPU: x64 File System: NTFS User: System -Blocked Website Details- Malicious Website: 1 , C:\Users\Mkilb\AppData\Roaming\Emby-Server\system\EmbyServer.exe, Blocked, -1, -1, 0.0.0, 17CAE7966BAA7E7AD77BA2215A9C26C5, 3395C5F964031FA55CE126802EB832A246FD6B3D1A4855652AF44422EE4F8994 -Website Data- Category: RiskWare Domain: IP Address: 93.123.109.120 Port: 8096 Type: Inbound File: C:\Users\Mkilb\AppData\Roaming\Emby-Server\system\EmbyServer.exe (end)

Looks like you're using the legacy Emby Theater app which itself is a honey pot of vulnerabilities since it bundles an old version of Electron. I'd recommend using Emby for Windows instead.

Thank you my friend, appreciate you

I'm on Windows. And 8096 is open to remote connect to Emby, yeah. I'm a little jumpy because I had my Discord hacked and some credit card charges made. I can't format the whole system right now so I did a deep clean of everything(99% sure I got rid of it) and have a few different AV running until I have the time to format, as well as changing all my passwords on a separate device that isn't compromised, so when this popped up I just got paranoid. I have 2FA on everything as well, I was just curious because the link above says it's a known malacious actor.

Listen, it's like this bro, if you want to open up ports at least go in and hide your emby users don't have them unHidden so a port scanner guy can attack them.

With the release of the Revamped Home Screen we have the ability to add a large number of sections. From an end user perspective using tags or collections can have a similar result for the home screen which leads me to these questions: Which is more performant when using 10+ sections? What are the tradeoffs, if any, using one over the other? Are there any best practices around either? Which is more maintainable/manageable in the UI? I've seen discussions that touch on some of these topics, but some are 5+ years old and may not be relevant. If any of these questions are already answered and are valid today a link to it would be helpful

Nah he's getting port scanned because he has open ports 8096 & 8092 most likely and they are scanning for them ports setting off his malwarebytes

Hi. It is going to depend on exactly how you created that home screen row. If it were a collection or other defined item in your library, it would use the image for that. If, however, it is dynamic media then there is no direct image anywhere for that item which is automatically generated when there are more items in the collection than show on the home row.

Bro are you on windows ? do you have your modem/router ports open as 8096 & 8092

Hi. "Latest Releases" already does this. It is "Latest Media" that uses the Emby added date. In the library in question, what is this set to?

Luke this is your Jam Bro I wonder does EBR like this Lukes Jam.mp4

Emby. Emby attempted to connect to that IP according to Malware Bytes.

Hi. What is "it" in that sentence? That has to be a false positive...

This is the major clue that something in your network environment has changed. Public IP, port forwarding, firewall rules, router security software... etc.

I know, thats why im waiting for the next beta.. MediaIntelNUC always has that come back Hahaha

Problem Posters, backdrops, logos, and other artwork do not display in Emby for Roku. Library titles and metadata load normally. The same Emby server and the same Traefik reverse-proxy endpoint display artwork correctly in the Emby Android app. Environment Emby Server: 4.9.5.0 Previously tested server version: 4.10.0.40 Roku Emby client: Roku SG 4.1.70 Roku OS/User-Agent: Roku/DVP-15.3 (15.3.4.2402-E4) Roku device: Roku Express 4K+ Reverse proxy: Traefik 3.7.x External endpoint: HTTPS on port 443 Emby backend: HTTP on port 8096 Roku subnet: 10.0.1.0/24 Roku tested at: 10.0.1.153 Emby backend: 10.10.10.31:8096 Traefik: 10.10.10.10 Network policy intentionally prevents the Roku VLAN from directly accessing the Emby backend. The Roku is permitted to access Emby only through Traefik. Observed behavior The Roku successfully: connects to the Emby server authenticates retrieves user information retrieves library views retrieves Latest and Resume item lists receives HTTP 200 responses for those requests However, after receiving valid item metadata, the Roku makes zero subsequent artwork requests to endpoints such as: /emby/Items/<itemId>/Images/Primary The Android app, through the same Traefik endpoint, immediately makes normal artwork requests and receives HTTP 200 responses. Packet-capture findings A packet capture was taken on the backend connection between Traefik and Emby. The Roku's actual JSON responses were reconstructed and decompressed. The Roku receives fully valid item metadata, including: valid Id valid PrimaryImageAspectRatio valid ImageTags.Primary valid Logo and Thumb image tags valid BackdropImageTags Example returned directly to the Roku: Name: Hoppers Id: 20916 PrimaryImageAspectRatio: 0.6666666666666666 ImageTags.Primary: 6446a5a415fde153a84a899e3cf8ac83 ImageTags.Logo: b7b15e18a0e49a6a19ab8c0e589bd406 ImageTags.Thumb: 9d10c1067748a1b28f3657cd26a1791b BackdropImageTags: [952a7ad8dd847209d522e205f62b2d16] Other returned items show the same valid structure. Despite receiving these fields, the Roku sends no image GET requests afterward. Image endpoint verification A real poster was tested independently. Direct from Emby: HTTP 200 Content-Type: image/jpeg valid JPEG payload Through Traefik: HTTP 200 Content-Type: image/jpeg same valid JPEG payload The Android app also displays the posters correctly through the same Traefik endpoint. This strongly indicates that: artwork files are valid Emby image endpoints are working Traefik routing is working TLS is working HTTP/2 is working CrowdSec is not blocking the requests rate limiting is not the cause Additional comparison Android artwork requests through Traefik look normal, for example: /emby/Items/20916/Images/Primary?... and return HTTP 200. The Roku receives the same item's valid ID and Primary image tag but never attempts that request. Tests already performed Uninstalled and reinstalled Emby on Roku Rebooted Roku between uninstall and reinstall Removed and re-added the server Tested Emby Server 4.10.0.40 Rolled back to Emby Server 4.9.5.0 Corrected Emby public HTTPS port to 443 Added 10.0.1.0/24 to Emby Local Network Subnets Temporarily removed CrowdSec middleware from the Emby Traefik router Verified no Traefik rate limiter is active Verified direct backend image endpoint works Verified proxied image endpoint works Verified Android app artwork works through the same reverse proxy None of these changed the Roku behavior. Historical observation Older Roku sessions from another Roku device on the same network previously generated malformed backdrop URLs such as: /emby/Items//Images/Backdrop/0?... where the item ID was blank. In the current failing session, however, the Roku does not request artwork at all even though valid Id, ImageTags, and BackdropImageTags are present. Conclusion The failure appears to occur inside Emby for Roku 4.1.70 after receiving valid metadata but before constructing or sending image requests. There are no image-related 403, 404, or 429 responses in the failing Roku session because the Roku never sends the image request. Could the Roku developer please check for a regression in Roku SG 4.1.70 involving parsing ImageTags or constructing image URLs? Logs available I have sanitized Emby server and Traefik logs available. Authentication tokens have been removed. I can also provide a sanitized packet-capture-derived summary if requested. I will not post the raw packet capture publicly because it contains authenticated HTTP traffic. Roku debug logging has also been enabled and can be submitted through the Roku app's Send Log function. emby-roku-debug-20260914_093157-sanitized.tar.gz README.txt sanitized-traefik-roku-filtered.log