Unmanic states GPL version 3 and then pastes an MIT notice

The licence section names the GPL and then prints an MIT notice

The last section of the page is where the two statements sit next to each other. It opens by saying the project is licensed under the GPL version 3, with the word projected misspelled in the sentence. Under that line comes a permission notice that is the MIT text: permission is granted free of charge to any person obtaining a copy of the software to deal in it without restriction, including the rights to use, copy, modify, merge, publish, distribute, sublicense and sell, provided the copyright notice is included in all copies. Those are two different licences, and only one of them is the one the project files itself under. The page then adds that the project contains libraries imported from external authors and that you should refer to those sources for their licences, which is an honest admission that the dependency set is not homogeneous. The copyright line reads Josh Sunnex, All Rights Reserved, and the contributing link points at a file inside the `docs/` directory rather than at a contributing guide in the root.

Three screenshot headings carry no images

The table of contents promises three subsections under screen-shots, and all three exist as headings with nothing under them: Dashboard, File metrics and Installed plugins. Those are the three views a new user most wants to see, since the dashboard is where queued work would be visible, the file metrics page is where you would confirm the library was indexed, and the plugins page is where you would see what has been installed. The badge row above them has its own gap: one entry is an empty markdown link with no URL inside the parentheses, and three Docker Hub badges point at exactly the same image address, `josh5/unmanic`. The image lives under a personal Docker Hub account rather than the project organisation, which matches the pattern elsewhere on the page: a donation link, a personal copyright holder and a container published by one person.

Packaging lives in a setup script while pyproject holds lint settings only

The build configuration is split across three files, and the modern one carries nothing about the project. `pyproject.toml` contains four ruff tables and nothing else: a target version of py310, a line length of 120, a formatter configured for double quotes and space indentation, and a lint selection of the pycodestyle, pyflakes and import rules. There is no project table and no build system table in it, so the name, version, dependencies and entry point are not declared there. Those live in `setup.py`, which opens with a docstring dated 04 May 2020, imports setuptools and its build command, and starts with a guard that prints a message and exits if the interpreter is Python 2. `setup.cfg` and a `MANIFEST.in` sit beside it, and `versioninfo.py` holds the version as a separate file. So a project built in 2026 still installs through a script whose first job is to reject Python 2. The version itself lives in a separate file, `versioninfo.py`, rather than in either manifest, and `setup.cfg` and a `MANIFEST.in` sit alongside to carry packaging metadata and file lists that the setup script reads. Nothing in the four ruff tables says anything about the package itself, which means a reader who opens the modern configuration file first learns the line length and nothing about what is being distributed.

The file monitor depends on a package in the optional block

The requirements file separates its entries with comments rather than with extras, and one of the four headline features lands in the optional group. The required block holds the scheduler library, the web server, a schema library, an ORM with its migration tool, a process and CPU information library, an HTTP client with its toolbelt, a CPU information package, a JSON log formatter and a hash library. The optional block holds the file system watcher and an error reporting client. The watcher is what the second main function is built on: the file and directory monitor that notices a modified file or a new file and tests it against the presets again. Since the instructions tell you to install the whole file with `python3 -m pip install -r requirements.txt`, the distinction is documentation rather than packaging, but it does mean a reader scanning for the monitor's dependency has to know that the word optional in that file refers to the code path rather than to the install.

What actually happens to your files once it is running

The description is about three moving parts and one interface. A scheduler scans the whole library for files that do not match the configured file presets and queues the ones that need work. A file and directory monitor does the same test again when a file is modified or added. A handler manages running several file manipulation tasks at a time. A web interface configures all of it and shows the progress. What the queued task does is entirely yours: the examples given are transcoding video or audio into a uniform format with FFmpeg, identifying and optionally removing commercials from DVR recordings shortly after they have finished recording, moving files from one location to another after a configured period, running FileBot renames on files as they arrive, compressing files older than a specified age, and running any custom command against files matching an extension or above a configured size. No preset, filename pattern or command is given on the page, so a first run means configuring everything yourself.

Two ways in, and neither documents the Docker route

The install section does two things. It points at the documentation site for up to date instructions, which is the project's own docs domain, and it gives a from source sequence:

# Ensure the submodules are checked out
git submodule update --init --recursive

# Build and install the project into your home directory
python3 ./setup.py install --user

# Run Unmanic
unmanic

Then you open a browser at `http://localhost:8888/`. So the local interface is a plaintext HTTP port on the loopback address, started by a command installed into a personal bin directory. Meanwhile three badges point at a container image on Docker Hub, and the tree carries both a `docker/` directory and a `devops/` directory, so there is a container path that the page badges but never explains, and the repository's own documentation is where you would find it.

Python is stated four ways and never as a floor

The dependencies section asks for Python 3.x and links the python.org downloads page. The setup script refuses anything below Python 3 at import time. The lint configuration targets py310, so the code is written against a 3.10 baseline even though nothing tells you that is required. And a `.python-version` file sits at the repository root, which is the file version managers read to pin an interpreter for contributors. Four statements, and not one of them is a number a consumer can act on. That matters for a tool whose whole job is to run indefinitely against a large library: the floor decides which Python your host has to be, and here you would have to infer it from a lint setting and a file that only exists for the project's own development.

Editorial conclusion

Unmanic suits a media library owner who wants transcoding, ad removal, ageing and custom file commands driven by a queue and a web interface rather than by hand, and who is willing to give a running process write access to the library. Before adopting it, read the licence section properly, because the page pairs a GPL version 3 statement with an MIT shaped permission notice and points third party licences at their own sources rather than listing them. Check which dependencies you actually need, since the file monitor depends on one that sits in the optional block of the requirements file. And plan for the packaging shape, which is a setup script with a Python 2 guard rather than a project table in pyproject. It runs commands you configure against your own files, so test on a copy of the library first.

Frequently asked questions

Official sources

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