These docs are for MetaTana 2.0, coming soon
UI Looks Stale Or Doesn't Update
You changed something (edited metadata, ran a scan, applied a rename) and the app still shows the old state. Maybe the change was saved but the screen disagrees. Maybe the screen is showing data from a different database entirely. This page walks the checks.
Common causes, in order of likelihood
- Two copies of MetaTana runningTwo MetaTana servers on the same port, each with its own pages and maybe its own database. The browser gets whichever answers first.
- Browser cache holding an old pageMost common right after an update. The page loaded the old JavaScript, and the server can't fix that until you reload.
- Wrong data folderMetaTana is reading one database, but your recent edits went into another (a different Docker volume, a different data folder, a custom
METATANA_DB_PATH). - Work queued, not finishedYou started a rescrape or rename, but it is still waiting or it failed. Activity says which.
- Not refreshed yetSome pages check for changes on a timer. The change is saved; the page hasn't fetched it yet. Hard reload (Cmd+Shift+R or Ctrl+F5).
Diagnose
Check for a second copy
macOS / Linux:
lsof -nP -iTCP:3000 -sTCP:LISTEN
Should show exactly one process. If you see two, kill the older one and reload. On Docker, docker ps should list one MetaTana container per port.
Hard reload the browser
Cmd+Shift+R (macOS) or Ctrl+F5 (Windows and Linux). If the change appears after the hard reload, the browser had an old page. In the desktop app, quitting and reopening it does the same.
Check the data folder
The desktop app shows its data folder under Settings › Maintenance › Data & diagnostics. It should be the folder where your recent work went. If you moved your database or run MetaTana in Docker, check which volume is mounted at /app/data.
Read Activity
Open Activity and search for the title. The most recent row says what happened: applied, waiting, failed, or skipped. If Activity and another page disagree, trust Activity.
Fix
- Old page: hard reload, or quit and reopen the desktop app.
- Second copy: quit the extra copy. In Docker, stop the extra container.
- Wrong data folder: fix the volume mount or
METATANA_DB_PATH, or move the database file. Restart MetaTana. - Failed work: open the failed Activity row, read the error, and select Retry if it offers one.
Restore is waiting
What you see: you scheduled a database restore in Settings › Maintenance › Backups and restarted, but the page still says Restart MetaTana to restore the backup from …, and the library still shows the current data.
MetaTana replaces the database only when nothing else has it open. If another MetaTana process still has it open at startup, the restore waits for the next start and your current database is left as it was.
- Quit every copy of MetaTanaQuit the desktop app fully (not only its window), stop any running
metatanacommand, and check for a second copy using the same data folder, for example a desktop app and a Docker container pointed at one database. - Docker with several containersIf the web and background roles run in separate containers, the restore waits until every container that uses the database has restarted. Stop them all, then start them again.
- Start MetaTana onceAfter the restart, Backups names the backup that was restored and lists a Before restore copy of the database you had.
- Changed your mind?Select Cancel restore. Nothing is replaced.
If the page instead says The restore on … did not run, and the library database was not changed, read the reason after it. MetaTana saves a copy of the current database before it restores, and it stops if that copy cannot be made, for example when the disk is nearly full. Free some space, then select Restore on the backup again.
Going deeper
- Activity: what ran, what failed, and Undo
- Reference: environment variables:
METATANA_DB_PATH, port overrides - Triage what needs your attention: Home shows some of these problems too
- Back up your library: database backups and restore