PlxNative: a Plex client that throws away the TV's web browser

The problem was the browser, not the code

PlxNative exists because of a specific frustration, and the README is unusually clear about it. The official Plex app on an older LG television was slow: scrolling a shelf stuttered, opening a poster took a beat too long. The diagnosis is the interesting part, because the app behaves like a web page because it is one, a web application running inside the television's Chromium, and patching it does not help when the ceiling is the browser.

The response was to remove the browser. PlxNative draws straight on the GPU and hands video to the same silicon the built-in applications use, with no Chromium, no JavaScript and no web view. Almost all of it is Rust.

That framing matters for what the project is and is not. It is not a fork of the Plex web client with a different stylesheet; it is a native application that speaks to the same Plex servers and drives the same hardware decoders. The result is a client that behaves like the built-in apps on the set rather than like a website embedded in one.

The project is GPL-3.0 licensed, independent, and explicitly not affiliated with Plex, Inc. or LG. The developer describes using it daily on a 2019 set to watch material from a server in the next room, and nightly builds are published under tags such as v0.9.0-nightly-20261019, with the last push on 2026-10-21.

What the interface actually offers

The screens are captured from the running application rather than mocked up, using a demo library of openly licensed films, and the same code runs on the television and on a desktop simulator.

Home shows a rotating hero built from what you are partway through and what has just landed, with shelves underneath. Library opens on the full poster grid with an A to Z rail down the side and a header row for sorting and filtering, including an unwatched-only filter, alongside a Collections page and a Recommended page. The shelves on Recommended list what you are partway through, with the time remaining shown under the focused card, and what has just arrived. Search runs one query across every server you can reach and groups the results by kind.

Sign-in happens on the television itself, with an on-screen QR code and a choice of Plex Home profile. Browsing covers your own servers and the ones shared with you, and the plex.tv Watchlist appears as its own tab where a title can be added or removed, while search covers servers only.

The player has the transport with chapters and track menus drawn over the video, and the television decodes the video itself. The README notes that in the screenshot the frame under the controls was decoded by the simulator.

Direct play, the codec table and when the server takes over

Playback is decided against the television's own codec table where the set publishes one. Direct play covers H.264 and HEVC including 4K and 10-bit, Dolby Vision profiles 5 and 8, E-AC-3 Atmos, and AV1 or VP9, with 10-bit VP9 limited to webOS 4 sets. Anything the set cannot decode itself is transcoded by the server, and a playback can be switched to Auto to follow a link whose speed changes.

Consulting the codec table rather than a hard-coded list is the decision that makes the client work across model years. A fixed list would either refuse to play formats the set supports or attempt to play formats it cannot, and both failures look like bugs in the client rather than in the hardware.

The watching features are the standard set, and their presence matters more than their novelty: resume, seek and scrub, chapters, audio and subtitle tracks including image subtitles, Skip Intro, Skip Credits, Up Next with auto-advance, and progress reported back to the server so the resume point is correct on the next device.

The performance claim is measured rather than asserted. The README describes frame-rate regression scenes that measure the interface on the television itself, with 60 fps on the 2019 set used for development, instead of trusting a number from a development machine.

Which televisions are supported, and the exceptions

The stated requirement is webOS 4.0 or newer, and then the README gets specific about the edges rather than leaving them to discovery.

A 2016 set running webOS 3.4.3 signs in, browses, searches and plays, including direct play, transcodes, subtitles and seeking, through Developer Mode. A 2018 set on webOS 3.9.3 plays direct play the same way, but only when built from source at or after commit 60f99c7, because the prebuilt v0.8.0 predates that fix. Other 3.x releases are untested, and anything older than 3.4 is unknown.

The reason for the source-build condition is technical and specific. The prebuilt v0.8.0 holds a strong ELF reference to the cxx11 symbol StarfishMediaAPIs::Feed, which the 3.x libplayerAPIs does not export, so on that build the video never starts and no error is reported. The fix resolves Feed with a dual-ABI dlsym, which is the kind of change that cannot be patched into an already published binary. The repository tracks it as issue 249.

Beyond the 2019 set used for development, opt-in usage reports show video playing on sets from 2018 through the newest, on webOS 11, with both direct play and server transcodes, Developer Mode installs included.

Per-chipset failures and what a rooted television adds

The known issues table is the most valuable section of the README, because it maps failures to hardware.

On some 2019 sets with LG's k5lp or k3lp chip, installed through Developer Mode, video will not play. The explanation is that LG's Developer Mode sandbox can withhold a device the video path needs, and Kodi and Moonlight hit the same wall, so it is a platform restriction rather than a bug in this client. The application checks for the situation and says so instead of crashing, and other sets on the same chip play normally. On a rooted television with Homebrew Channel, the failure screen offers a Repair option that applies the Homebrew Channel fix to the sandbox; the README is careful to say that one owner fixed it that way from a root shell and that the button itself has not been run on an affected set. Without root there is no fix.

There is also a crash reported on sets with LG's k6hp chip, seen in opt-in crash reports and not reproduced by the developer because they do not own such a set, tracked as issue 174.

On webOS 3.x, seeking restarts the stream at the new position instead of jumping in place, so each seek takes a moment longer, because in-place seeking depends on the internal layout of LG's 4.x media player. Menus can drop frames at 1920x1080 on those sets, and the interface resolution setting trades sharper text for smoother menus.

Developer Mode, rooting and the expiry nobody mentions first

No root is needed for normal use. A television in Developer Mode runs everything except the k5lp and k3lp repair described above.

What Developer Mode costs is renewal. If the session lapses, LG removes the applications installed through it, and the installation guide has a section on how to keep them. A rooted television with Homebrew Channel has no expiry, which is the practical difference between the two routes.

The README also asks for reports from people who own the affected sets, noting that a set working is as useful a report as a set failing. That is the right instinct for a project whose hardware coverage is uneven, and the opt-in usage reports are what turned the compatibility statement into something specific rather than optimistic.

The install guide is in the repository as docs/install-and-verify.md, with troubleshooting in docs/troubleshooting.md, and the project site carries the same guides at plxnative.com.

The build: cross-compiled Rust and a SONAME strategy

The Makefile documents the toolchain in unusual detail, and the comment at the top explains why. The build uses the webosbrew native-toolchain buildroot SDK with GCC 12, glibc 2.12 and armv7-a soft float, installed once with make setup-env, with the location overridable through WEBOS_SDK. The SDK ships a real sysroot containing the television's own SONAME'd libraries for SDL2, GLESv2, wayland, glib, luna-service2 and LG's libplayerAPIs and libpf, so the binary links against the real thing rather than a reimplementation.

The targets are the usual ones for this kind of project: build produces the package, deploy copies the binary and appinfo to a rooted television over scp, run launches it and fetches the event log, test builds, deploys and runs, kill closes the app, and ipk repackages the release archive.

make setup-env
make test

The most instructive part of the file is a comment about a technique that was removed. A stub shared library trick once let FFmpeg and libcurl be named in DT_NEEDED and resolved to the television's real libraries at runtime. But a DT_NEEDED entry is a hard requirement for one exact SONAME, and those names move between webOS releases, with FFmpeg stepping through several major versions, curl changing its soname and one library being deleted outright in webOS 5. The trick therefore pinned the binary to webOS 4.x, and on anything newer the loader killed it before main, before a log existed. Those libraries are now opened dynamically by SONAME candidate list, and a tool grades the result against 14 real firmware inventories.

Editorial conclusion

PlxNative suits an LG television owner whose set runs webOS 4 or newer, who finds the official client sluggish and is willing to install a homebrew application that LG may remove when a Developer Mode session lapses. It is the wrong choice if you need a product with support and updates on a schedule, since the releases are nightly builds from an independent developer, and it is the wrong choice for a 2018 set unless you build from source. Verify first that your set's chipset is not one of the k5lp, k3lp or k6hp cases listed as broken, that your codec table lists the formats you want to play directly, and that you accept having to reinstall after a Developer Mode renewal.

Frequently asked questions

Official sources

1. GLinnik21/plx-native on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases