Z-Keeper · how it fits together
Three layers, two doors,
one way back
Z-Keeper keeps three records of your library. Two of them describe a player — what it says now, and what it should say. The third describes your files, and it exists whether or not you own a Zidoo at all.
Where everything lives
Your files sit above; your Zidoos each index a slice of them. Down in Z-Keeper's database, every Zidoo gets its own pair of layers — and underneath them all sits one Master Catalog that knows nothing about devices at all.
The same three layers, in words
The quickest way to tell them apart is to ask where each one's rows come from. Two are built from what a player reported. One is built from your files.
Zidoo copy
One per device
- Answers
- What does this Zidoo hold right now?
- Changes when
- Every sync. It is replaced, not merged — it is a snapshot, not a record.
- Survives a factory reset
- No. It follows the device down and comes back rebuilt.
Blueprint
One per device
- Answers
- What should this Zidoo look like once everything is right?
- Really it is
- The Master Catalog as it applies to one player — the titles that player holds, in that player's own id numbering, plus any settings that are unique to this device, such as a different poster than the Master Catalog's cemented poster.
- Changes when
- Only when you approve or change something. Nothing a device does moves it.
- Survives a factory reset
- No — not usefully. Its rows are keyed on the device's own entry ids, which a rebuild discards wholesale, so it describes a vanished player exactly as the mirror does. Recovery is to clear it along with the mirror, then rebuild the device from the Master Catalog. What that costs is only what this device held differently: its watched and favorite history.
Master Catalog
One, shared by every device
- Answers
- What is in your library, and what each file is — with or without a player attached.
- Changes when
- Only when you approve or change something.
- Survives a factory reset
- Yes. It never referred to the player in the first place, so re-issued ids mean nothing to it.
- Built from
- Your source folders, read straight off disk. A row exists because a file exists — not because a Zidoo mentioned it.
One file, three answers
Suppose you rebuilt a Zidoo's sources, and its own scraper matched a film to the wrong title. Nothing is broken — the three layers simply disagree, which is exactly what they are for.
The file Predator Badlands_t03.mkv is on the shelf, and the Zidoo has just re-scraped it.
The Zidoo copy says it is a different film entirely.
Not a lie — just what the player reported at the last sync.
The Blueprint says this Zidoo should show Predator: Badlands.
Because you approved that once, on this device.
The Master Catalog says the file is Predator: Badlands.
Keyed to the file and its TMDB identity. No device involved, so a reset cannot touch it.
Push fixes closes the gap. It compares one of the two right-hand layers against the Zidoo copy and sends only the differences back to the player — matches, collections, categories, artwork and metadata, each ticked one row at a time.
Two ways in, one way out
Sync and Identify are often confused because both fill the database. They ask completely different things, of completely different sources — and neither of them ever writes to your player.
Only one of them requires you to own a Zidoo.
One approval, three writes
This is the rule that keeps the layers from drifting apart. Change anything, anywhere, on any Zidoo — and Z-Keeper treats it as curated and cements it in all three places at once.
What survives a factory reset
This is the moment the three layers earn their keep. A reset wipes the player's own database and re-issues every id it hands out.
Zidoo copy
Goes with it. The next sync simply records the new, emptier truth.
Blueprint
Cleared too. Keyed on the ids the reset threw away, so it is wiped with the mirror — you lose only this device's watched and favorite history.
Master Catalog
Untouched. Keyed to files and films, so the new ids don't matter.
The player remembers more than you would expect, too: re-adding your sources brings back things it had learned about a title — custom collection membership, for instance — as soon as its scraper matches that title again. What it does not bring back is a correct match; it repeats its original mistakes. So the order of recovery is always the same — fix the matches first, and a great deal of the rest follows on its own.
Z-Keeper