LG WebOs “Unexpected Playback error” when transcoding

Plex Players Smart TVs
1

Server Version#: 1.42.2.10156
Player Version#: Client-Version 5.93.2 Platform Version 10.2.2

I have to LG Smart TV’s a older OLED55C97LA running LG OS 5.50.00 and Plex Client-Version 5.93.2 / Platform Version 4.10.0 and a newer OLED42C47LA with LG OS 33.22.85 and Plex Client-Version 5.93.2 / Platform Version 10.2.2 . When a media is transcoded I get a error on the OLED42C47LA saying “Unexpected Playback error” but on the older TC it is played without error. When cheeking the logs I can see that I get a “Unable to find client profile for device;“ for both TV’s. But only for the effected device I see this errors.

eb 08, 2026 12:41:10.014 [134577696521016] DEBUG - Request: [192.168.11.17:44364 (WAN)] GET /video/:/transcode/universal/session/ttm1brb7e4l0qb50okcqce3u/base/index.m3u8 (10 live) #8c2 Signed-in
Feb 08, 2026 12:41:10.014 [134577696521016] ERROR - Error parsing HTTP request: %3Dvideo.height%26value%3D2160)%2Badd-limitation(scope%3DvideoTranscodeTarget%26scopeName%3Dmpeg2video%26scopeType%3DvideoCodec%26context%3Dall%26protocol%3Dhls%26type%3DupperBound%26name%3Dvideo.bitDepth%26value%3D8)%2Badd-limitation(scope%3DvideoTranscodeTarget%26scopeName%3Dmpeg2video%26scopeType%3DvideoCodec%26context%3Dall%26protocol%3Dhls%26type%3DupperBound%26name%3Dvideo.width%26value%3D1920)%2Badd-limitation(scope%3DvideoTranscodeTarget%26scopeName%3Dmpeg2video%26scopeType%3DvideoCodec%26context%3Dall%26protocol%3Dhls%26type%3DupperBound%26name%3Dvideo.height%26value%3D1080)%2Badd-limitation(scope%3DvideoTranscodeTarget%26scopeName%3Dmpeg4%26scopeType%3DvideoCodec%26context%3Dall%26protocol%3Dhls%26type%3DupperBound%26name%3Dvideo.bitDepth%26value%3D8)%2Badd-limitation(scope%3DvideoTranscodeTarget%26scopeName%3Dmpeg4%26scopeType%3DvideoCodec%26context%3Dall%26protocol%3Dhls%26type%3DupperBound%26name%3Dvideo.width%26value%3D1920)%2Badd-limitation(scope%3DvideoTranscodeTarget%26scopeName%3Dmpeg4%26scopeType%3DvideoCodec%26context%3Dall%26protocol%3Dhls%26type%3DupperBound%26name%3Dvideo.height%26value%3D1080)%2Badd-transcode-target(type%3DsubtitleProfile%26protocol%3Dhttp%26context%3Dall%26subtitleCodec%3Dass%26container%3Dass)%2Badd-transcode-target-settings(type%3DvideoProfile%26context%3Dall%26protocol%3Dhls%26ForceZeroByteEmptySegment%3Dtrue)&X-Plex-Client-Profile-Name=Generic
User-Agent: Mozilla/5.0 (Web0S; Lin
Feb 08, 2026 12:41:10.014 [134577696521016] DEBUG - Completed: [192.168.11.17:44364] 400 GET /video/:/transcode/universal/session/ttm1brb7e4l0qb50okcqce3u/base/index.m3u8 (10 live) #8c2 0ms 265 bytes
Feb 08, 2026 12:41:10.016 [134577694411576] DEBUG - Request: [192.168.11.17:44366 (WAN)] GET /video/:/transcode/universal/session/ttm1brb7e4l0qb50okcqce3u/base/index.m3u8 (10 live) #8c6 Signed-in
Feb 08, 2026 12:41:10.016 [134577694411576] ERROR - Error parsing HTTP request: %3Dvideo.height%26value%3D2160)%2Badd-limitation(scope%3DvideoTranscodeTarget%26scopeName%3Dmpeg2video%26scopeType%3DvideoCodec%26context%3Dall%26protocol%3Dhls%26type%3DupperBound%26name%3Dvideo.bitDepth%26value%3D8)%2Badd-limitation(scope%3DvideoTranscodeTarget%26scopeName%3Dmpeg2video%26scopeType%3DvideoCodec%26context%3Dall%26protocol%3Dhls%26type%3DupperBound%26name%3Dvideo.width%26value%3D1920)%2Badd-limitation(scope%3DvideoTranscodeTarget%26scopeName%3Dmpeg2video%26scopeType%3DvideoCodec%26context%3Dall%26protocol%3Dhls%26type%3DupperBound%26name%3Dvideo.height%26value%3D1080)%2Badd-limitation(scope%3DvideoTranscodeTarget%26scopeName%3Dmpeg4%26scopeType%3DvideoCodec%26context%3Dall%26protocol%3Dhls%26type%3DupperBound%26name%3Dvideo.bitDepth%26value%3D8)%2Badd-limitation(scope%3DvideoTranscodeTarget%26scopeName%3Dmpeg4%26scopeType%3DvideoCodec%26context%3Dall%26protocol%3Dhls%26type%3DupperBound%26name%3Dvideo.width%26value%3D1920)%2Badd-limitation(scope%3DvideoTranscodeTarget%26scopeName%3Dmpeg4%26scopeType%3DvideoCodec%26context%3Dall%26protocol%3Dhls%26type%3DupperBound%26name%3Dvideo.height%26value%3D1080)%2Badd-transcode-target(type%3DsubtitleProfile%26protocol%3Dhttp%26context%3Dall%26subtitleCodec%3Dass%26container%3Dass)%2Badd-transcode-target-settings(type%3DvideoProfile%26context%3Dall%26protocol%3Dhls%26ForceZeroByteEmptySegment%3Dtrue)&X-Plex-Client-Profile-Name=Generic
User-Agent: Mozilla/5.0 (Web0S; Lin

Not sure if this is the route cause so I attached the log file.

Plex Media Server.log (1.1 MB)

2

I’m experiencing the exact same issue on my LG OLED48A26LA after it updated to webOS 10.2.2 (Plex for LG 5.94.1, PMS 1.43.1.10561 Plex Pass). I spent several hours doing deep debugging on this and can share detailed findings. Disclaimer - LLM was heavily used during debugging and for compiling this summary, I have too little subject matter expertise to accurately judge if the conclusions are correct.

Summary

After the webOS firmware updated to 10.2.2, all video playback fails with “Unexpected playback error.” Playback works fine from the Plex web interface on a computer hitting the same server. The issue affects all content, not specific titles.

Environment

  • TV: LG OLED48A26LA, webOS 10.2.2
  • Plex for LG: 5.94.1
  • PMS: 1.43.1.10561-69cc2fd8d (latest Plex Pass, Ubuntu 20.04 LTS on LXC)
  • Hardware transcoding: Intel Quick Sync VAAPI on i5-7500T (works fine — verified with other clients)
  • Network: Wired LAN, same subnet, no firewalls between TV and PMS
  • Content tested: Multiple titles, MKV containers, H.264/1080p, various audio codecs (EAC3, AAC)

Log files
Raw logs pms-raw-logs.log (405.6 KB)
Annotated logs pms-log-webos-10.2.2.log (11.8 KB)

Root cause

There are two problems:

1. Missing client profile

PMS logs show:

ERROR - Unable to find client profile for device; platform=webOS, platformVersion=10.2.2, device=webOS 10.2.2, model=OLED48A26LA

The server falls back to the Generic profile (which is an empty XML), and the client’s augmentation data uses container=mpegts with ForceZeroByteEmptySegment=true. For comparison, a previously working client on the same network used container=mkv with CopyMatroskaAttachments=true — a much more capable profile.

2. webOS 10.2.2 HLS player can’t reliably fetch segments over TLS

This is the critical issue. I traced the full playback flow through server logs:

Step 1 — Decision cascade (client-side fallback chain):

The TV first tries directPlay=1&directStream=1&subtitles=sidecar. The server returns 200 OK with a direct play decision. The TV fails to use it (~5 seconds), then retries with directPlay=0&directStream=0&subtitles=burn, forcing a full transcode. Sometimes it retries a third time with directStreamAudio=0.

Step 2 — HLS manifest fetched successfully:

The TV successfully fetches start.m3u8 (master playlist, ~335 bytes) and sometimes session/<id>/base/index.m3u8 (variant playlist). Both return 200 OK over TLS. These requests are made by the Plex app’s own HTTP client.

Step 3 — Segment fetch fails:

The native webOS HLS media player (which is separate from the Plex app’s HTTP client) then needs to fetch .ts segments. This is where it breaks. In most attempts, it fetches zero segments and stalls until timeout (timeStalled=5, playbackTime=0). In one attempt it fetched exactly one segment (6.3MB, 304ms response time), played 48ms of video, then never requested another segment — stalling for 36 seconds before giving up.

Throughout all of this, the Plex app’s own API calls continue working fine over TLS — timeline updates, session pings, transcode stop requests all succeed. The failure is specifically in the webOS system HLS player that handles segment fetching.

Evidence it’s a TLS issue

All connections to PMS go through HTTPS (Plex always serves TLS on port 32400 when certificates are available). I confirmed:

  • curl http://192.168.1.190:32400/identity → connection refused (HTTP not served)

  • curl -k https://192.168.1.190:32400/identity → 200 OK

The Plex app’s HTTP client handles the *.plex.direct certificate fine for API calls. But the webOS native HLS player uses a different TLS stack that appears broken in 10.2.2. It either fails the TLS handshake entirely (no segments fetched) or drops the connection after one segment.

What I tried (nothing worked)

Attempt Result
Reinstall Plex for LG from Content Store No change — same failure pattern
Sign out/in on TV No change
Force-close and restart app No change
secureConnections=0 in PMS PMS still only serves HTTPS on port 32400, setting only affects URL advertisement to plex.tv
customConnections=https://plex.mydomain.com (Traefik reverse proxy with valid LE cert) TV ignores it, still connects directly to PMS
Custom server-side XML device profile for webOS Modern Plex apps use client-side augmentation, server XML profiles are ignored
Disable hardware transcoding (force libx264 instead of h264_vaapi) Same failure — rules out VAAPI-specific encoding issue
Change “Burn subtitles” setting on TV App still sends `subtitles=burn` in requests
AirPlay from iPhone Still uses TV’s broken native HLS player

Comparison: working vs broken

Before the webOS 10.2.2 update, the same TV played content fine (same server, same content, same network). The key differences in the client behavior:

- Before update (working) After update (broken)
Profile Matched (no error) Unable to find client profile → Generic
Augmentation container mkv mpegts
Augmentation features CopyMatroskaAttachments=true ForceZeroByteEmptySegment=true
Codec support h264, vp8, vp9, hevc, av1, + many audio h264, hevc, mpeg2video, mpeg4 only
Direct play Worked Server returns 200 OK, TV fails to use it
HLS segment fetch Worked over TLS Fails — 0 or 1 segments, then stalls
3

same issue on my lg c5. out of 100 tries it works just once, no format of the video is working, they used to work great until my tv updated and also updated plex app to 5.94.1.

Any workarounds at least?

Thanks

4

@markus101 what were the bug fixes and enhancements in 5.94.1?