Taiga: a Windows anime tracker that watches your filesystem

What the application does, in the project's own summary

Taiga is described in the repository description as a lightweight anime tracker for Windows, and the README expands that into a fuller sentence. It is an open-source desktop application for Windows that automatically detects the anime videos you watch on your computer and synchronizes your progress with AniList, Kitsu or MyAnimeList. The README adds that it helps you manage your anime library, discover new series, share watched episodes and download new ones.

The automatic detection part is the distinguishing feature, and it is worth being precise about what it means. Taiga is not asking you to log what you watched through a form or a browser extension. It watches the filesystem for local media files and infers what they are. That inference is possible because the same author maintains Anitomy, described in the related projects section as an anime video filename parser, and Anisthesia, described as a media detection library. The filename is the input, and parsing it is a solved problem that has its own repository.

The tracking side of the application is ordinary once detection is solved. Three backends are named in the README, AniList, Kitsu and MyAnimeList, and the repository topics match exactly: anilist, kitsu, myanimelist, anime and windows. Progress recorded locally is synchronised to whichever service you connect, so your watch history lives with the community tracking sites rather than only on your machine.

The repository layout is a CMake project with vendored dependencies

The repository tree is short and tells you the build system without any ambiguity. At the root sit a CMakeLists.txt, a CMakePresets.json, and four files that are pure build configuration: a .clang-format, an .editorconfig, a .gitignore and a .gitmodules.

The presence of CMakePresets.json is the more interesting of the two build files. A presets file lets a project declare named build configurations that a developer selects by name rather than by reconstructing a long command line. For a desktop C++ application that has to compile on several toolchains, that is the difference between a build that is documented and a build that is folklore.

The .gitmodules file marks the project as using git submodules, and the deps/ directory at the root is where those dependencies land. Combined with the setup/ directory, the layout suggests the standard split: dependency acquisition under deps/, project configuration under setup/, and everything the application itself does under src/.

Three other directories complete the picture. cmake/ holds CMake module files, the conventional place for find-modules and helper functions. docs/ holds documentation kept in the repository rather than on the wiki. src/ is the application source.

The default branch is develop, which is worth noting. It means the branch named develop carries the work in progress, and if you are reading source expecting a stable state you would want a tagged release instead.

The release history has a clear shape

There are three releases in the repository, and read together they describe a project that ships deliberately.

The newest is v1.4.1, published in March 2024. Its release body is a single line: a Changelog link pointing at the wiki entry for v1.4.1 dated 22 March 2024. Before that is v1.4.0, published in November 2022, whose body is the same shape, a wiki changelog link for that version. Before that is v1.4.0-beta.2 from June 2020.

The beta release body is the most informative of the three because it carries an actual warning. It states that this is a pre-release version which may include unstable features, advises regular users to wait for a stable release, and tells anyone upgrading anyway to take a backup of the installation directory first, defaulting to %AppData%\Taiga. That path is a useful detail on its own, because it names where the application keeps its data separately from where it installs.

Two observations follow. First, the release notes live in the wiki rather than in the repository, so the tag list alone tells you that something changed but not what. Second, and more consequentially, the last release is from March 2024 while the last recorded push to the repository is in late September 2026. That is a gap of about two and a half years with commits after the newest release. The project is being worked on; it is simply not cutting tagged releases on the same cadence.

Everything a contributor needs lives in the wiki

The README links three wiki pages and nothing else for the contributor path: a Changelog, Contribution guidelines, and a How to Compile page. Each link is aimed at a different question.

The Changelog is where the release notes pointed to by every tag actually live. The Contribution guidelines page is where the expectations for patches live. The How to Compile page is the build documentation, and its absence from the repository is the most significant gap for anyone who wants to build from source, because a CMake project with a presets file, a submodule dependency list and no in-repository build instructions leaves the interesting decisions undocumented where they would be most useful.

The README also links the Discord server through a badge, and the sponsor link points at the maintainer's GitHub sponsors page. Both are the low-friction channels for questions that do not deserve a full issue. For anything that does deserve a record, an issue on the repository is the appropriate place.

Distribution runs through the home page at taiga.moe, which the README links directly on the release badge pointing at a download page. The related projects section lists taiga.moe as the home page of Taiga in its own right, meaning the web presence is a separate repository rather than a static page inside the application repository.

One author, several specialised repositories

The most structurally interesting part of Taiga is the related projects list, because it shows how the application is assembled from pieces that each have their own repository under the same author.

There are four entries. Anime relations is described as episode redirections, which means it maps an episode of one release to the corresponding episode of another, the problem of releases having different numbering for the same show. Anisthesia is a media detection library, the component that watches a directory and reports what media appears. Anitomy is an anime video filename parser, the component that turns a filename into a series name, an episode number and a release group. And taiga.moe is the home page of Taiga, the web front end and download distribution.

Read together, those three libraries draw a clean boundary. Anisthesia knows a file exists and is media. Anitomy knows what that file is. Anime relations knows whether the episode you are on matches the episode someone else is on. Taiga is the application layer that wires them to a tracking service and a user interface.

That decomposition explains a detail of the CMake layout. An application depending on two specialised libraries, one of which is a detection library and one a parser, has a dependency graph worth managing, which is what deps/ and the submodule configuration are for. It also explains the licensing question: Taiga itself is GPL-3.0, and the README links the GNU General Public License version 3 text rather than an MIT or BSD licence, which is the consistent choice for a project whose value is in sharing modifications rather than in permissive reuse.

Editorial conclusion

The concrete next step for anyone building Taiga from source is to read the How to Compile page in the project wiki before touching CMakePresets.json, because the wiki entry is where the dependency submodule and toolchain decisions are recorded, and this repository ships the presets but not the explanations that go with them.

Frequently asked questions

Official sources

1. erengy/taiga on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases