jellyfin-webos: a Jellyfin client for LG televisions

A wrapper, not a client application

The scope of the project is stated in one sentence and it explains almost everything else. This is a small wrapper around the web interface provided by the server, so most of the development happens in the separate web interface repository rather than here. The consequences of that division are concrete. The user interface you see on the television is the Jellyfin web application, not a television-specific design, which means the remote control navigates a layout designed for a mouse or a touch screen. The behaviour of the client, the login flow, the library browsing and the playback controls are all determined by the server-side web interface, and a bug in those is fixed there. What this repository adds is the part that a browser cannot do, which is reaching the server, telling it the television is there, and handing over to the interface once the connection is established. That is why the repository is small, with a frontend directory, a services directory, a tools directory and a single dev.sh script, and why the readme is mostly about building and testing rather than about features.

How the app finds and hands over to the server

The usage section describes the whole user flow in two sentences and it is worth reading closely. You fill in the hostname, the port and the schema, and then click connect. The app checks for a server by grabbing the manifest and the public server information, and afterwards it hands off control to the hosted web interface. That handshake is the entire function of the wrapper. The manifest is what tells the client what the server supports, and the public server info is the unauthenticated endpoint that confirms something is listening at that address. Doing this in the native app rather than in the page means the client can test the connection and report a failure to the user before it loads a web interface that would otherwise show a connection error from inside a page, which is a better experience on a television with a remote control. The schema setting is worth noting too, since a Jellyfin server can be reached over plain HTTP or over HTTPS and a television will not let you guess wrong quietly.

Installing from the store, and the one conflict to avoid

The download section points at the LG content store, and the note next to it is a practical trap. If you previously installed the app via Homebrew or via developer mode, you must uninstall that before you can use the store version. That is the sort of instruction that sounds obvious once and then costs an hour the first time, because the older install and the store install use the same application id, so the television sees one app with two sources. The badge links to the LG store listing for all versions, and the store route is the one the project treats as the supported path for end users. The repository layout reflects the split between the wrapper and its build tooling, with a frontend directory holding the application sources including the appinfo metadata, a services directory holding the native parts, and a tools directory with scripts for generating the manifest and synchronising the version into the application metadata.

Installation offers three build environments

The development workflow has a fixed shape. You prepare a build environment, you compile an IPK either with the IDE or with the packaging tool, and you test the app on the emulator or on the server, or you install it on a television by following the platform documentation. There are three ways to get the build environment, and the choice is mostly about how much of the vendor tooling you want. The full WebOS SDK installation is the first, the Docker option is second with a prebuilt image that includes the build and deployment dependencies, and the npm route for the ares tools is third, which requires only Node and its package manager. The npm route installs the toolkit with a single install command and then packages the app with a run script:

and and the package scripts in the project metadata show what that means concretely, with the package script building the services and the frontend into a build directory, the deploy script installing the resulting package, the launch script starting it, a manifest script generating the manifest through a node tool, and a version script that syncs the version and stages the application metadata. The dev.sh script is a wrapper around the Docker commands, and the readme notes that if you have installed the SDK directly you can omit that part.

Testing on real hardware, and the devmode dance

Testing on a television needs a vendor developer account and the devmode application installed on the target set, and the readme is explicit about the sequence. You install the devmode app and log in with the developer account, then you turn on the dev mode status and the key server, and the instruction to take a note of the passphrase is in bold, which is a hint that losing it means redoing the setup. The commands that follow are the practical part. Adding the television uses a search flag, with the defaults fine but a name of tv recommended. Setting up the SSH key for the device requires the key server to be running, and there is a separate step that fetches the key, and then a device information command to verify the setup works. After that the app is installed, and there are two ways to launch it, one that also opens the web developer console and one that just launches the app. The build step is a single command to package the app with the services and the frontend, and it is run before the install step, which the readme reminds you of:

# This command installs the app. Remember to build it first.
./dev.sh ares-install -d tv org.jellyfin.webos_*.ipk

The rest of the sequence adds the device, fetches the key, verifies it, installs the package and launches the app, with a variant that also opens the web developer console.

Licensing, maintenance and the state of the repository

The licence arrangement is worth reading because it is not uniform. All the Jellyfin webOS code is licensed under the MPL 2.0 licence, some parts incorporate content licensed under the Apache 2.0 licence, and all the images are taken from and licensed under the same licence as the user interface project. The project metadata agrees on the MPL-2.0 identifier, and the only development dependency is the ares command line tool, which is the vendor's packaging and deployment utility. The maintenance picture is the one point of concern. The tagged releases are v1.2.2 from 2024-04-10, v1.1.0 from 2022 and v1.0.1 from 2022, while the last push was on 2026-07-14 and the version in the project metadata is 1.2.2, which suggests the wrapper changes rarely and the work happens in the interface it wraps. There is a contributors file, a renovate configuration for dependency updates, a changelog and a standard set of GitHub community files, and the default branch is master.

Editorial conclusion

jellyfin-webos is a good fit for someone who wants Jellyfin on an LG television and is happy to accept that the interface is the desktop web app running on the TV, since the project is explicitly a wrapper and most of the development happens in the separate web interface repository. It is the wrong tool if you want a native television interface with a remote control driven layout, because what appears on screen is the browser interface, and it is the wrong tool if you cannot use the app store version, since the store entry is the supported route and sideloading is the development path. It is also the wrong tool if you need to build the interface, because changes to the UI belong upstream rather than here. Before starting, read the download section carefully, since the store version cannot coexist with a Homebrew or developer mode install, and note the release gap, where the most recent tagged release is v1.2.2 from 2024 while the last push was on 2026-07-14. The project is MPL-2.0 licensed, with parts under Apache 2.0.

Frequently asked questions

Official sources

1. jellyfin/jellyfin-webos on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases