Streambert: an Electron shell over m3u8 links, a TMDB token and a separate downloader

First launch stops on a TMDB read access token

The setup wizard is one field, and it is not optional. On first launch the app prompts you to enter your TMDB API key, the project calls it a free TMDB API Read Access Token, and a separate guide file, tmdb-tutorial.md, sits in the repository root to walk you through getting one. The key is saved locally, so the prompt appears once and not again. That token is the only credential the app asks for, and it is the hinge the whole interface turns on: images, info texts, search and the homepage are all fetched from tmdb, which is the reason a title typed into the app resolves to something at all. The screenshots folder reflects how much of the interface is token-shaped, with files named application_tmdb.png, api-settings_tmdb.png, signup_tmdb.png, token_tmdb.png and personal-use_tmdb.png. A second tutorial file, wyzie-tutorial.md, sits next to the TMDB one.

Prebuilt packages come in six formats across three platforms

The install path is a downloads page rather than a package manager, and the format you pick depends on your distribution. On Linux the releases page carries a .deb, a .pacman package and an .AppImage, and each is installed the way that format expects.

# .deb
sudo dpkg -i streambert_*.deb

# Arch Linux (.pacman)
sudo pacman -U streambert-*.pacman

# .AppImage (you can also do it with Gearlever)
chmod +x Streambert-x64.AppImage && ./Streambert-x64.AppImage

Windows takes a different file shape: download the latest `Streambert Setup *.exe` and run it. macOS takes `Streambert-*-universal.dmg`, which you open and drag Streambert into Applications. Two details are worth noting before you download anything. The universal in the macOS filename matches the build script, which passes `--universal` to electron-builder. And the AppImage filename carries an x64 label, so that artifact is named for one architecture. The AppImage route also names Gearlever as an alternative to chmod, which is the desktop integration path for that format. Releases are published on Codeberg, and the project also keeps a GitHub presence with its own releases and issue tracker, so there are two places to look for a given version.

Streaming resolves to m3u8 links, downloading needs another program

Streams come from different hosters and aggregators, listed as PLAYER_SOURCES in src/utils/api.js. When you press Download, the program sources the link to the .m3u8 playlist file for that stream, the same kind of artifact a browser extension called m3u8-link-finder retrieves, and then a separate program does the work. That program is vid-dl-cli-only, published by the same author, and the requirements section is explicit that it must exist somewhere on your PC, together with ffmpeg installed, before downloading works at all. So the download path has three moving parts where the streaming path has one: the app for the link, the external downloader for the transfer, and ffmpeg for the muxing. Once a file lands, you can watch it in the app or take it to any storage medium you like, which is the point of the external downloader being a separate tool.

Anime switches metadata provider and gets mp4 files directly

The anime path is not the movie path with a different filter. The app checks whether a movie or series is anime, and when it is, metadata comes from AniList instead of tmdb, so the token you entered at first launch covers the non-anime catalogue only. Media files for anime are then scraped from AllManga.to, and the project credits the mechanic to ani-cli. The difference that reaches the user is file format: for anime the app gets .mp4 files directly and never shows the AllManga website, and those files can be downloaded the same way as any other content. That is a different pipeline end to end, from a different metadata source to a different file source to a different container, and it means an AniList lookup can succeed where a TMDB lookup would be wrong. The privacy section also concedes the obvious point: the streaming sources may still collect data, so which provider served a given title changes what happens to your request.

Arch Linux needs two extra packages before a build works

Building from source is a two-step process, and the second step is not one command but a choice of eight. Dependencies install with `npm install`, then one of the target scripts runs depending on what you want to produce: `npm run dist:win`, `npm run dist:linux`, `npm run dist:arch` for the Arch package, `npm run dist:appimage`, `npm run dist:deb`, `npm run dist:rpm`, `npm run dist:mac`, or `npm run dist` for every platform at once. Under the hood each one sets ELECTRON_DIST through cross-env, runs a vite build, then hands off to electron-builder with a target list and `--publish never`, so nothing is uploaded from your machine. The Arch caveat is called out as important: on Arch you may hit a libcrypt.so.1 error, answered with `sudo pacman -S libxcrypt-compat`, or an http-parser dependency error, answered with `yay -S http-parser` from the AUR. Node.js is required at 22.12.0 or later, and only if you are not using the prebuilt binaries.

The privacy claim ends where the app's own sources begin

Read the two paragraphs together rather than the headline. Streambert states that it collects no data and that there is no centralized service the app relies on, and it advertises itself as ads and tracker free with built-in tracker and ad blocking. The same disclaimer then says the streaming sources and GitHub, which is where in-app update checks come from, may still collect your data, and adds that the blocking is obviously not perfect. That is an honest description of a client-side aggregator: the app is a thin process between you and providers that are not the project, so its own silence says little about the requests it forwards. The legal section makes a parallel point about content, stating that the app does not host, store or distribute any copyrighted content, that everything comes from third-party providers, and that it functions as a search engine aggregator only, with users responsible for having legal rights to what they access. It is offered for educational and personal use.

The structure diagram disagrees with the repository tree

The project root holds two entry points for the preload bridge, and the diagram in the README does not match what is in the tree. The README's project structure block lists index.html, main.js, package.json, preload.js, vite.config.js, LICENSE and README.md at the top, then public/ with icon.png, installer-sidebar.bmp and logo.svg, then screenshots/, then src/ with App.jsx, main.jsx and components. The actual top level of the repository has no main.js. It has index.js and popout-preload.js instead, alongside preload.js and vite.config.js, plus index.html, package.json, package-lock.json, public/, screenshots/, src/, LICENSE, README.md, CONTRIBUTING.md, tmdb-tutorial.md and wyzie-tutorial.md. The screenshots/ folder in the diagram matches the tree, and the src/ listing in the block stops partway at a components/BlockedStat entry, so it is a partial view. package.json names index.js as main, which is the file that exists, and the private flag is set, so the app is not published to a registry as a library.

Four runtime dependencies and seven build tools

The manifest is small for an app of this size. Runtime dependencies are approve at 0.0.12, hls.js at 1.5.17, react at 18.2.0, react-dom at 18.2.0 and scripts at 0.1.0, so the user interface is React and there is no state library, no router and no UI kit in the list. Development carries the build chain: vite at 7.3.1 with @vitejs/plugin-react at 4.7.0, electron at 45.2.1, electron-builder at 26.18.0, terser at 5.46.0 for minification, and cross-env at 7.0.3 so the ELECTRON_DIST flag behaves the same on Windows and elsewhere. The packaging block sets appId com.truelockmc.streambert, productName Streambert, asar true and compression normal, with build resources pointed at a build directory, and the files list starts from dist. The declared version is 2.7.0, matching the most recent release (v.2.7.0, published 2026-11-01), which is also the date of the last push.

Editorial conclusion

Streambert suits someone who wants a desktop front end that turns a title into a playable stream across Windows, macOS and Linux, and who is comfortable installing a separate downloader and ffmpeg for the offline path. It does not suit someone who needs an Android or mobile build, an offline-first catalogue, or a service with a backend, since there is no centralized service and no mobile target in its build scripts. Before you install, decide whether you want the prebuilt binary or the Node path with its >=22.12.0 requirement, have a free TMDB read access token ready for the first launch prompt, and read the privacy footer, because the app states that its streaming sources and the update check may still collect data.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. truelockmc/streambert on GitHub