jellyfin-tizen-builds: nightly Samsung TV packages for Jellyfin

A build pipeline, not the application

The purpose of this repository is stated in one sentence, to automatically build the most up-to-date version of jellyfin-tizen. That is the whole scope, and the README is unusually clear about the boundary.

The related projects table names the two upstream repositories that are responsible for the actual implementation. The jellyfin/jellyfin-tizen project is the Samsung Tizen wrapper app that this repository builds, and jellyfin/jellyfin-web is the Jellyfin web client bundled inside the app.

And then comes the note that shapes every interaction with the project. If you experience runtime issues with the app itself, playback problems, UI bugs or missing features, you should check and report those issues in the relevant upstream repository rather than here. This repository only produces the build artifacts and is not the right place to address such issues.

That is a deliberate separation of concerns and it is worth respecting, because a build pipeline that also carries the application code is a repository where every upstream bug report and every packaging question compete for the same tracker. Here, the tracker is about the pipeline.

The releases show how often it runs. The three most recent are named by timestamp, 2026-10-15-2019, 2026-10-15-1656 and 2026-10-15-1122, which means several builds on the same afternoon, and the last push to the repository was on 2026-10-15. The licence is MPL-2.0.

The build matrix, and what each channel contains

The versions table is the most useful part of the README, because the choice of file is the only decision a user really has to make.

The file named Jellyfin.wgt is built with the latest stable release of jellyfin-web, and that is the one most people want. The 10.11.z file is built with the bleeding edge of the branch for the 10.11.z releases, and 10.10.z is the same idea for the previous release line, so a file is the combination of a web client channel and a naming convention that keeps the older line reachable.

The master file is built with the latest potentially unstable changes to the jellyfin-web code, and the description is blunt that it will always be the newest possible version. That is the channel to try when a bug in the stable web client is what you are waiting on.

The secondary file is the one with an idea behind it. It is built with the latest stable release of jellyfin-web and a different app ID, to allow having a second account signed in. Since a Tizen application has one identity and one storage, two accounts on one television is otherwise awkward, and the different app ID is how the build solves that.

So the naming is a small vocabulary. The file name tells you the web client channel, and the suffix tells you what else was changed.

The special builds for specific televisions

The rest of the table is a list of workarounds, and each one points at the upstream issue that motivated it, which is the most useful thing in the row.

OblongIcon uses an oblong type icon for televisions that require it, and the reader is pointed to the relevant issue in the Tizen wrapper repository. GrayFix potentially fixes an issue where the bars over and under the video are gray, again with a link to the issue. These are the kind of fixes that are device specific and that no amount of configuration on the television would solve.

SmartHub adds the Samsung Smart Hub Preview integration. OSA combines the OblongIcon and SmartHub builds with experimental support for the AVPlay player for improved codec support, so it is the kitchen sink variant for the older and more awkward sets, with the caveat that the codec support is experimental.

TrailerFix is the most specific of them, fixing YouTube trailer playback, error 153, on newer Tizen operating system versions, and the table credits the source of the fix as an adaptation from another project, Apps2Samsung, by a named contributor.

That last credit is the kind of detail that tells you how this repository actually works. It is not the upstream project, it is a build pipeline that carries patches and packaging variations for devices that the upstream does not support, and it says where the patches came from.

There is also a note about older televisions, and it is honest rather than reassuring. The author says they do not have many success stories with TVs older than 2018, but that a few people in the Discord server have reported it working for their 2015 and 2016 televisions with the 10.8.z version, which is not included in new releases but can be found in an older release.

Installing on a television

The installation path is the standard Tizen one, and the prerequisites are specific.

You need Tizen Studio with the command line interface, the Visual C++ Redistributable packages for Visual Studio 2013 for both x86 and amd64, and one of the .wgt files from a release. The getting started section is blunt about the setup being just the prerequisites and nothing else.

The deployment to the television has three steps. You activate developer mode on the TV, you connect to the TV with Device Manager from Tizen Studio, and you install the package.

c:\tizen-studio\tools\ide\bin\tizen.bat install -n Jellyfin.wgt -t <the name of your tv>

On a Mac the command differs only in the path and the shell.

$HOME/tizen-studio/tools/ide/bin/tizen install -n Jellyfin.wgt -t <the name of your tv>

The comment above the command notes that it assumes the file is called Jellyfin.wgt, and that you can change it to the prerelease name or simply rename the file. The television name comes from Device Manager or from the sdb devices command.

There are two third party installers mentioned for people who would rather not do this by hand. A graphical one that automates most of the process, and a one step Docker based install guide. The author states plainly that they have no affiliation with these installers and cannot provide support for them, while noting that both of them use the builds provided here.

The compatibility list, and where to file what

Two community practices keep this repository useful, and both are worth understanding before you install anything.

The first is COMPATIBILITY.md, a markdown file whose purpose is to create a list of televisions that are known to either work or not work. The list is intended to be community maintained, and anyone is free to add to it as they discover new televisions that do or do not work.

That is a more valuable artefact than it sounds. Tizen support is scattered across television models and years, and a list of confirmed working sets saves a lot of trial and error for the next person. It is also honest about its own nature, since a list of failures is as useful as a list of successes and much easier for the community to contribute to.

The second is the issue routing, which the common issues section sets out carefully. This repository is only responsible for building and packaging the app, it does not control the app's behaviour or the web client, with the exception of the features mentioned in the specialty builds.

So issues with the Tizen wrapper, which means crashes, app level bugs and Tizen specific behaviour, go to the wrapper repository. Issues with the web client, which means UI bugs, playback issues and missing features, go to the web client repository.

That split is the practical shape of working with this project. The pipeline is small and mechanical, and it is the upstream repositories that carry the behaviour of the application.

The automation behind the builds

The repository layout shows how the pipeline is wired, and it is a small collection of configuration and scripts rather than an application.

There are three JSON files at the root that describe the build. matrix-definition.json defines the matrix, matrix.json holds its current state, and versions.json records the versions. Alongside them are a patches directory, which is where the modifications that produce the specialty variants live, and a scripts directory that drives the build.

The remaining root files explain the packaging side. There is a tizencert.p12, which is the signing certificate the packages are signed with, since a Tizen package has to be signed to install on a television, and the two icon files, icon2.png and iconoblong.png, which correspond to the standard and oblong icon builds in the versions table.

The primary language of the repository is recorded as JavaScript, and there is a package.exp file. The GitHub directory holds the workflows that run the builds and the release publishing.

The result is a release pipeline that produces a signed package per channel, several times a day, from an upstream app and an upstream web client, with the local differences expressed as patches and build options rather than as forks. That structure is why the project can carry a variant for a 2015 television and a variant for the Smart Hub without maintaining a codebase of its own.

Editorial conclusion

Adopt the builds from this repository if you run Jellyfin on a Samsung television and want a package built from the current web client rather than whatever the store last carried, because the pipeline rebuilds several times a day and offers prerelease and second account channels. Do not use it as a place to file application bugs, since the project is explicit that runtime issues belong in the upstream wrapper or web client repositories. Before you pick a variant, read COMPATIBILITY.md, because the community maintained list of televisions that work is the only guidance on whether a given set is supported.

Frequently asked questions

Official sources

1. Issues
2. jeppevinkel/jellyfin-tizen-builds on GitHub
3. License: MPL-2.0
4. README
5. Releases