The lost user manual
Mylar
A long time user's operating notes for the parts the README doesn't cover. Everyday use, quiet failure modes, safe changes, and ways back.
Before we start
Thanks to EvilHero
I want to say thanks to EvilHero for creating Mylar and maintaining it for so many years. We don't know where he is now, but I hope he is doing well. This manual is a tribute to his work and the community he built around it.
Setting Expectations
Field notes
Let's clear up some general misconceptions right from the start.
01
Mylar is not a manga downloader
Mylar was written for western comics. Downloading manga is not its primary focus but some publishers do exist that are supported.
02
Install with an exit plan
First run
The decisions worth making before launch, plus the checks that prove the first run is actually healthy.
03
The normal working loop
Daily operations
The repeatable tasks, useful views, and small habits that keep routine work routine.
04
Better defaults and shortcuts
Tips & tricks
Practical refinements learned through use—not a tour of every switch in the settings screen.
05
Symptoms before theories
Common pitfalls
Recognizable failure modes, what usually causes them, and the least destructive place to begin.
06
A calm route back
Recovery & maintenance
How to collect evidence, roll back a bad change, and upgrade without turning one problem into three.
Earned the slow way
Tips worth keeping
Before changing settings
Capture the known-good state
Keep a copy of the configuration and note what success looks like. A useful backup is one you can compare, not just one you can restore.
While troubleshooting
Follow one event end to end
Use one test item and one timestamp. Searching the logs for a single journey produces a much cleaner story than scanning everything at once.
Before upgrading
Separate code from state
Know which files are replaceable application code and which hold configuration or data. Back up the latter and leave yourself a rollback path.
Before opening a new issue
Common pitfalls
Start with the symptom you can observe, then work inward.
01The application starts, but nothing happens
Likely cause
A service can be running while an integration, watched path, or background task is not. “Up” only confirms the process exists.
What to do
Trigger one small test, note the exact time, and trace it through the logs. Check the first boundary where the expected event disappears.
02A path works in the shell but not in the application
Likely cause
The service may run as a different user, inside a container, or with a different view of the filesystem.
What to do
Verify the runtime user and inspect the path from that environment. Check ownership and permissions before broadening access.
03An update fixes one thing and breaks another
Likely cause
Configuration, dependencies, and stored data do not always move forward at the same pace as the application code.
What to do
Read the version notes, compare the old configuration, and restore only from a backup made before the upgrade. Change one layer at a time.
When it is already broken
Use the recovery ladder
- Observe Save the error, timestamp, and relevant log lines.
- Reduce Reproduce it with the smallest possible action.
- Compare Check permissions, paths, config, and the last known-good state.
- Change one thing Test, record the result, and keep an easy rollback.