webOS: gray screen when attempting playback of any video

[nagisa]

I am encountering a weird issue where I get a gray screen with no way to do anything else once I invoke playback of any video on my LG OLED77C21LA at firmwareVersion 13.30.85 and sdkVersion 8.3.0. Once I pick some content to play, I see a very brief spinner as the metadata is getting fetched and then the display immediately switches to gray. The only action I can do at that point is to press the "back" button on the remote and kill the app. The jellyfin app otherwise appears to be working perfectly fine up to that point.

I'm pretty sure this is not related to transcoding problems: if I access jellyfin through the TV's built-in web browser, jellyfin and playback work just fine. Furthermore, I believe the app fails even before it initiates the playback session proper. The only difference between these two contexts is that the app's jellyfin is inside an iframe.

I have tried debugging the app with the inspector and I am not seeing any errors at all when this occurs. One thing that I do see, however, is that the iframe's #document becomes empty. I don't see any javascript errors, and no breakpoints are triggered when I ask the debugger to break on uncaught exceptions. The inspector is somewhat funky, though, so I'm not sure how reliable this is. More curious is that I also don't see the app getting to the point where the usual http requests for playback are initiated. There's the bitrate test, fetch for some styles (e.g. GET /web/htmlVideoPlayer-style-scss.css), the app opens a /socket and then its gone.

I have considered that this might be a memory consumption problem, but restart the TV by pulling out power and plugging it back in does not help, unfortunately.

I'm not sure when the problem started -- I'm not using jellyfin on the TV very often. First I noticed this problem is with 10.9.7, but 10.9.11 also has this problem. The app itself is at 1.2.2 from homebrew store.

Has anybody seen anything of a similar sort?

[TheDreadPirate]

Can you share your full jellyfin log via pastebin? Also, do you have "Prefer fMP4-HLS Media Container" enabled in the WebOS app?

Also, is the content HDR? Does this only happen with some content or with any content?

[nagisa]

> Can you share your full jellyfin log via pastebin?

There isn't anything especially revealing in there unfortunately. I restarted JF, went to TV (192.168.130.2) to reproduce the issue and came back to get this log: https://gist.github.com/nagisa/54528f36d...8a0e3c6448. You can see here that it doesn't even get to spawning ffmpeg or anything of the sort that which is what would be the usual behaviour when using the web browser on the TV. The client behaves as if the user exit the app. (Which jibes with my observation that the iframe becomes empty, effectively unloading the client.)

> Also, do you have "Prefer fMP4-HLS Media Container" enabled in the WebOS app?

Setting this option either way changes nothing.

> Also, is the content HDR? Does this only happen with some content or with any content?

My particular test files are not HDR. Happens with any video or audio file for me. Photos work fine.

[TheDreadPirate]

Actually the log is revealing.

Code:

[2024-09-18 21:51:26.902 +03:00] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Filtered interface addresses: ["127.0.0.1"]
[2024-09-18 21:51:26.902 +03:00] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Bind Addresses ["127.0.0.1"]
......
[2024-09-18 21:51:46.295 +03:00] [INF] [12] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "192.168.130.2" request
[2024-09-18 21:51:53.515 +03:00] [INF] [34] Jellyfin.Api.Helpers.MediaInfoHelper: User policy for "g". EnablePlaybackRemuxing: True EnableVideoPlaybackTranscoding: True EnableAudioPlaybackTranscoding: True
[2024-09-18 21:51:54.677 +03:00] [INF] [12] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "192.168.130.2" closed
[2024-09-18 21:52:12.345 +03:00] [WRN] [10] Jellyfin.Networking.Manager.NetworkManager: "100.64.0.7": Only loopback "127.0.0.1" returned, using that as bind address.
[2024-09-18 21:52:12.347 +03:00] [INF] [12] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "100.64.0.7" request

It looks like you manually configured Jellyfin to only bind to the local loopback? Was that intentional?

[nagisa]

Yes, this is fronted by an nginx, for HTTPS and similar such reasons. Besides, if this was the fault, using JF via TV's web browser would not work either. For posterity this is my current nginx config:


server {
listen 127.0.0.1:443 ssl ;
listen 127.0.0.1:80 ;
listen 100.64.0.8:443 ssl ;
listen 100.64.0.8:80 ;
listen 192.168.100.1:443 ssl ;
listen 192.168.100.1:80 ;
listen 192.168.130.1:443 ssl ;
listen 192.168.130.1:80 ;
server_name jellyfin.domain ;
http2 on;
ssl_certificate /tmp/jf.crt;
ssl_certificate_key /tmp/jf.key;
location / {
proxy_pass http://127.0.0.1:8096;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Protocol $scheme;
proxy_set_header X-Forwarded-Host $http_host;
proxy_buffering off;
}
client_max_body_size 100M;

# Tell browsers to use per-origin process isolation
add_header Origin-Agent-Cluster "?1" always;
add_header X-XSS-Protection "0";
add_header X-Content-Type-Options "nosniff";
# Permissions policy. May cause issues with some clients
add_header Permissions-Policy "accelerometer=(), ambient-light-sensor=(), battery=(), bluetooth=(), camera=(), clipboard-read=(), display-capture=(), document-domain=(), encrypted-media=(), gamepad=(), geolocation=(), gyroscope=(), hid=(), idle-detection=(), interest-cohort=(), keyboard-map=(), local-fonts=(), magnetometer=(), microphone=(), payment=(), publickey-credentials-get=(), serial=(), sync-xhr=(), usb=(), xr-spatial-tracking=()" always;
add_header Cross-Origin-Resource-Policy "cross-origin" always;
}


This is, for the most part, based on https://jellyfin.org/docs/general/networking/nginx/. I had to make some changes to the suggested configuration in the past, especially with regards to CSP headers in order to make the webOS app able to load jellyfin interface at all, but as things stand right now, using jellyfin.domain on the TV's web browser works, as does using every other client that's not the webOS app.

---

FWIW I tried various changes to the nginx config as well, such as removing the Permissions-Policy header, the X-content-type-options header, bringing the location /socket config in from the sample configuration and such. None of that has helped, unfortunately.

[TheDreadPirate]

What's the point of manually listening on every IP? And what is the point of binding to local host only (in jellyfin)?

And definitely bring the socket into the same server block.

For testing, can you remove the explicit address bind in Jellyfin, restart Jellyfin, and try again? We need to remove that as a possible factor.

My nginx config for reference.

Code:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name jellyfin.domain.tld;

    ## The default `client_max_body_size` is 1M, this might not be enough for some posters, etc.
    client_max_body_size 20M;

    # use a variable to store the upstream proxy
    # in this example we are using a hostname which is resolved via DNS
    # (if you aren't using DNS remove the resolver line and change the variable to point to an IP address e.g `set $jellyfin 127.0.0.1`)
    set $jellyfin 127.0.0.1;

    ssl_certificate /etc/letsencrypt/live/domain.tld-0002/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/domain.tld-0002/privkey.pem; # managed by Certbot
    ssl_trusted_certificate /etc/letsencrypt/live/domain.tld-0002/chain.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    # Security / XSS Mitigation Headers
    # NOTE: X-Frame-Options may cause issues with the webOS app
    add_header X-XSS-Protection "0"; # Do NOT enable. This is obsolete/dangerous
    add_header X-Content-Type-Options "nosniff";

    # Permissions policy. May cause issues on some clients
    add_header Permissions-Policy "accelerometer=(), ambient-light-sensor=(), battery=(), bluetooth=(), camera=(), clipboard-read=(), display-capture=(), document-domain=(), encrypted-media=(), gamepad=(), geolocation=(), gyroscope=(), hid=(), idle-detection=(), interest-cohort=(), keyboard-map=(), local-fonts=(), magnetometer=(), microphone=(), payment=(), publickey-credentials-get=(), serial=(), sync-xhr=(), usb=(), xr-spatial-tracking=()" always;

    # Tell browsers to use per-origin process isolation
    add_header Origin-Agent-Cluster "?1" always;

    # Content Security Policy
    # See: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
    # Enforces https content and restricts JS/CSS to origin
    # External Javascript (such as cast_sender.js for Chromecast) must be whitelisted.
    # NOTE: The default CSP headers may cause issues with the webOS app
    add_header Content-Security-Policy "default-src https: data: blob: ; img-src 'self' https://* ; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' https://www.gstatic.com https://www.youtube.com blob:; worker-src 'self' blob:; connect-src 'self'; object-src 'none'; frame-ancestors 'self'";


    location / {
        # Proxy main Jellyfin traffic
        proxy_pass http://$jellyfin:8096;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;

        # Disable buffering when the nginx proxy gets very resource heavy upon streaming
        proxy_buffering off;
    }

    location /socket {
        # Proxy Jellyfin Websockets traffic
        proxy_pass http://$jellyfin:8096;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
    }

    # Cache images
    location ~ /Items/(.*)/Images {
        proxy_pass http://$jellyfin:8096;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;

        proxy_cache jellyfin;
        proxy_cache_revalidate on;
        proxy_cache_lock on;
    }
}

[nagisa]

> What's the point of manually listening on every IP?

That's because this nginx server is running on a machine that has NICs to the public internet and has other server blocks that are serving content to the public internet. Binding 0.0.0.0/:: would expose jellyfin to "out there" which is something I definitely don't want to do.

> And what is the point of binding to local host only (in jellyfin)?

Same idea as above. Since nginx is running on the same machine, there also seemed to be no real point to to bind addresses outside of what's strictly necessary for the reverse proxy to access jellyfin. That said I do have a firewall and I can try pointing TV directly at jellyfin without going through nginx middleman.

---

So here are the things I tried:

1. Bind jellyfin to 0.0.0.0, and have webOS connect directly to http://192.168.130.1:8096 ==> playback works correctly;
2. Have webOS connect to http://jellyfin.my.tld proxying through nginx ==> playback works correctly;
3. Have webOS connect to https://jellyfin.my.tld proxying through nginx ==> playback does not work.

The certificate is from LetsEncrypt and is valid. The TV also understands this certificate, seeing that it works fine when used in the regular browser.

For now using http as a workaround is sufficient to me, but I still have a suspicion that this has something to do with how iframe security contexts work...

[nagisa]

By the way, thanks a lot for engaging with me!

[TheDreadPirate]

Try adding ssl_trusted_certificate to your config.

Code:

ssl_certificate /etc/letsencrypt/live/domain.tld-0002/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/domain.tld-0002/privkey.pem; # managed by Certbot
    ssl_trusted_certificate /etc/letsencrypt/live/domain.tld-0002/chain.pem; # managed by Certbot

This often helps with older Android clients with kind of the same circumstances. Chrome works fine, but the Jellyfin Android app doesn't like the cert.

Perhaps having ssl_trusted_certificate in your config will help with this in WebOS.