Roku 4.1.70 receives valid ImageTags but never requests artwork – posters missing only on Roku

[tabenroth 0]

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