All Activity

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?

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

LOL you got ripped off it's what happens when you pay people you don't know for an emby login it's what happens. I bet that emby server you used for the time it did work I bet it belonged to someone other than the person who used it to scam you. I bet they used a vps with nzbdav and their indexer ran out so they shut it down LOL Bad thing is I bet they used a hacked emby sub I'm not even sure the point anymore when you can setup a downloader client on the other end exactly like a news group running an arr stack, only difference is emby works better than an arr stack and no need for any maintenance as it's automated

That im waiting for the next beta, wich will then be the newest version.. I know, thats why im waiting for the next beta..

I have active Emby Premium licenses, but when I refresh the license, it says I need to pay for a Premier license—could this be due to the update? The licenses appear active with available devices, yet when I try to use the service, it asks me to pay for a Premier license. What could be happening?

You are all good yes

Yes.

thank u that work

I used EPG and downloaded the data. First test appears successful as it got the show name and the show time https://github.com/iptv-org/epg

For Matt and Mollie - wait for the Gracenote changes At the moment, I am in discussion with Gracenote on this. Also raising it with the Emby development team to see if there is any changes we can make. Meanwhile, If you can find an xmltv source for the schedules for the radio channels that is precise for the aired episode, then look into that and map these channels to the xmltv source. Removing the check on the library for existing episodes for just these radio channel recordings would allow you to keep multiple days recordings and view by date added