funoteka 0.1.0

package/dist/api/playlist.js

@@ -0,0 +1,311 @@
+import * as store from "../playlist/store.js";
+import { ID, parseId, required, seconds, songChild } from "./browse.js";
+import { ApiError, ERROR } from "./envelope.js";
+import { knownTrackIds, songsOfPlaylist } from "./meta.js";
+/**
+ * Playlists, in the protocol's shapes.
+ *
+ * The one part of this API that is not a reading of the collection. A playlist
+ * is what the listener said about the music rather than what the music is, and
+ * it is the only thing here a client can create — which makes three of these
+ * five routes the only routes in the whole API that write (the writes
+ * themselves are `playlist/store.ts`).
+ *
+ * The protocol's own split of that surface is kept as it is: `getPlaylists` is
+ * the list a client draws a sidebar from and carries no songs, `getPlaylist` is
+ * one playlist with its entries, and `createPlaylist` doubles as the update
+ * when it is handed an id — which is the protocol's design and not a shortcut
+ * taken here.
+ */
+/**
+ * The id a playlist is named by.
+ *
+ * A `pl:` prefix like every other id this API hands out, and deliberately *not*
+ * added to `KINDS` in `browse.ts`: that set is the tree — artists, albums,
+ * tracks, folders, roots — and a playlist is not a branch of it. An id from
+ * here is therefore refused by `getSong` and `getMusicDirectory` as naming
+ * nothing, which is the true answer, while the routes below read it themselves.
+ *
+ * Digits only, rather than whatever `Number` accepts: `pl:1e3` and `pl:0x10`
+ * would otherwise read as ids this server may never have handed out — and the
+ * one thing an id from here is allowed to be is one that was handed out. The
+ * refusals are the same either way; what the strict reading buys is that they
+ * are always true.
+ */
+function playlistIdOf(raw) {
+    // **Both separators are read, and this is where that promise was broken
+    // first.** `parseId` reads a colon and a hyphen; this compared against the
+    // prefix *constant*, so when the constant changed the old spelling stopped
+    // being recognised — and a client holding a playlist id from before was told
+    // there is no such playlist, while the commit that changed the separator said
+    // nothing would be orphaned (found by asking both spellings of a real
+    // playlist, task:2896).
+    const digits = /^pl[-:]/.test(raw) ? raw.slice(3) : '';
+    if (!/^\d+$/.test(digits))
+        throw new ApiError(ERROR.notFound, `No such playlist: ${raw}`);
+    return Number(digits);
+}
+/**
+ * The playlist an id names, or a refusal.
+ *
+ * Every route but the listing has one of these, and all three spell the
+ * protocol's not-found code rather than answering about a playlist that is not
+ * there. An id that was never handed out by this server is the same answer as
+ * one whose playlist was deleted: the client's question has no subject.
+ */
+function requiredPlaylist(db, raw) {
+    const row = store.playlist(db, playlistIdOf(raw));
+    if (row === undefined)
+        throw new ApiError(ERROR.notFound, `No such playlist: ${raw}`);
+    return row;
+}
+/**
+ * A playlist the listener may change — which a file's is not.
+ *
+ * Refused rather than allowed-and-later-undone, and the refusal is the only
+ * honest answer available: the row is re-derived from its `.m3u` on every scan
+ * that re-reads the file, so an edit would last until the next scan and a
+ * deletion would be undone by the scan after it. A client that lost a rename
+ * that way would have no way to tell it from its own bug — and the answer it
+ * gets here says which file owns the list, which is also what it takes to
+ * change it.
+ *
+ * The code is the protocol's "not authorized", which is what this is: the
+ * caller is authenticated, and this particular list is not theirs to change.
+ */
+function requiredEditable(db, raw) {
+    const row = requiredPlaylist(db, raw);
+    if (row.source_file_id !== null) {
+        throw new ApiError(ERROR.notAuthorized, `This playlist is read from a file in the collection, and a scan rebuilds it: ${raw}`);
+    }
+    return row;
+}
+/**
+ * Every value of a repeated parameter, as song ids.
+ *
+ * `songId` and `songIdToAdd` arrive the protocol's way — the name repeated once
+ * per song — so reading only the first would silently build a playlist one song
+ * long. An empty value is dropped rather than refused: `songId=` is a client
+ * with nothing to add, which is not an error.
+ *
+ * The refusal and the existence check below it say the same sentence, and that
+ * is on purpose — from a client's side "that is not a song id" and "that song
+ * is not here" are one answer about one parameter.
+ */
+function trackIdsIn(query, name) {
+    return query
+        .getAll(name)
+        .filter((raw) => raw !== '')
+        .map((raw) => {
+        const parsed = parseId(raw);
+        if (parsed === undefined || parsed.kind !== 'tr') {
+            throw new ApiError(ERROR.notFound, `No such song: ${raw}`);
+        }
+        return parsed.n;
+    });
+}
+/**
+ * Songs that exist, or a refusal naming the first that does not.
+ *
+ * Answered once for the whole call instead of per id, and the refusal is the
+ * point: a playlist quietly shorter than the request is one the client cannot
+ * tell from the playlist it asked for, and the song that went missing would
+ * only surface when somebody played the list through.
+ */
+function requireKnown(db, ids) {
+    const known = knownTrackIds(db, ids);
+    for (const id of ids) {
+        if (!known.has(id))
+            throw new ApiError(ERROR.notFound, `No such song: ${ID.track(id)}`);
+    }
+}
+/**
+ * Positions in a playlist, as the client sent them.
+ *
+ * A position is what the client is holding — it reads them out of the answer to
+ * `getPlaylist` — so a negative one names nothing. It is refused rather than
+ * ignored: a client that computed `-1` has a bug, and the alternative is a
+ * playlist that silently kept a song it was told to drop.
+ *
+ * The code is the generic one, which is what `browse.ts` and `genre.ts` answer
+ * with for a parameter that is not the number it should be — a client reading
+ * the code learns the same thing from either.
+ */
+function positionsIn(query, name) {
+    return query
+        .getAll(name)
+        .filter((raw) => raw !== '')
+        .map((raw) => {
+        const n = Number(raw);
+        if (!Number.isInteger(n) || n < 0) {
+            throw new ApiError(ERROR.generic, `${name} is not a position: ${raw}`);
+        }
+        return n;
+    });
+}
+/** The protocol's booleans, which arrive as `true` or `false`. */
+function booleanish(raw) {
+    const value = raw.toLowerCase();
+    return value === 'true' || value === '1' || value === 'yes';
+}
+/**
+ * A playlist in the protocol's shape, without its songs.
+ *
+ * What `getPlaylists` answers with, and the half `getPlaylist` adds `entry` to.
+ * The two therefore cannot disagree about a name, a length or a timestamp —
+ * they are one object, read once.
+ */
+function asPlaylist(row, config) {
+    return {
+        id: ID.playlist(row.id),
+        name: row.name,
+        ...(row.comment === null ? {} : { comment: row.comment }),
+        // The one account this server has. Kept in the answer because the protocol
+        // makes it a field of a playlist and a client draws it beside the name.
+        owner: config.user,
+        public: row.public === 1,
+        // OpenSubsonic's own field, and the protocol's rule for one of its own
+        // additions: a server that supports it sends it even when it has nothing to
+        // say, so a client can tell "editable" from "this server has never heard of
+        // the question".
+        //
+        // False for the listener's own playlists — the one account here owns those —
+        // and true for one read from a `.m3u` in the collection. That is not a
+        // restriction invented here: the file is what that list *is*, the stage
+        // rewrites the row from it on every scan that re-reads it, and an edit a
+        // client was allowed to make would be undone by a scan nobody asked for.
+        // A client that is told so can grey the controls out instead of losing work.
+        readonly: row.source_file_id !== null,
+        songCount: row.song_count,
+        duration: seconds(row.duration_ms),
+        created: row.created_at,
+        changed: row.changed_at,
+        // The picture is the first song's, in this answer and in the listing alike
+        // — the protocol lets a server name the cover with any id `getCoverArt`
+        // answers to, and an id of the playlist's own would need `getCoverArt`
+        // taught a second kind of subject to say what this says already. An empty
+        // playlist is handed no picture rather than an id for a cover that does not
+        // exist.
+        ...(row.cover_track_id === null
+            ? {}
+            : {
+                coverArt: row.cover_album_id === null ? ID.track(row.cover_track_id) : ID.album(row.cover_album_id),
+            }),
+    };
+}
+/** A playlist and its songs, which is what opening one asks for. */
+function withSongs(row, db, config) {
+    const id = ID.playlist(row.id);
+    return {
+        ...asPlaylist(row, config),
+        entry: songsOfPlaylist(db, row.id).map((song) => songChild(song, id)),
+    };
+}
+/**
+ * The playlists a client lists, without their songs.
+ *
+ * `username` is the protocol's filter, and this server has exactly one account:
+ * the configured one owns every playlist. A name that is not that one is
+ * answered with an empty list rather than an error — the question is "what does
+ * this user have", and the true answer is nothing, since no other user exists
+ * to have anything.
+ */
+export function getPlaylists(db, config, query) {
+    const username = query.get('username');
+    const mine = username === null || username === '' || username === config.user;
+    return {
+        playlists: {
+            playlist: (mine ? store.playlists(db) : []).map((row) => asPlaylist(row, config)),
+        },
+    };
+}
+/** One playlist with its songs, by the id `getPlaylists` handed out. */
+export function getPlaylist(db, config, query) {
+    const raw = required(query, 'id');
+    return { playlist: withSongs(requiredPlaylist(db, raw), db, config) };
+}
+/**
+ * A new playlist — or, handed an id, the replacement of an existing one.
+ *
+ * The protocol folds the two into one method, and the difference is one
+ * parameter — but **what an id does to the songs already there, the
+ * documentation does not say.** "Creates (or updates) a playlist" is the whole
+ * of it, and no client is told which of the two it will get.
+ *
+ * This server replaces them, because that is what the call means to the client
+ * that makes it: a player saving a playlist sends the list it has on screen,
+ * and a server that appended instead would make a song impossible to take out
+ * of a playlist by the one route that saves one. A client adding a single song
+ * has `updatePlaylist` for that, and says so by asking for it.
+ *
+ * **A call that names no songs at all is not a call that names none.** The
+ * protocol's own criterion for this feature tells renaming apart from emptying,
+ * and a client that renames sends an id and a name and nothing else; reading
+ * its silence as "the list is now empty" would throw the listener's songs away
+ * while answering `ok`, and the client would have no way to tell. So the songs
+ * are replaced only when the parameter is there, and a client that means to
+ * empty a playlist says so — `songId=` is that statement, and so is
+ * `updatePlaylist` with every position removed.
+ *
+ * `name` is required only when there is no id — a playlist with no name cannot
+ * be told from another in the sidebar a client draws, and a call that omits it
+ * is refused by name rather than given one. With an id it is optional, and a
+ * name the client did not send stays where it was.
+ */
+export function createPlaylist(db, config, query) {
+    const songs = trackIdsIn(query, 'songId');
+    requireKnown(db, songs);
+    const rawId = query.get('playlistId');
+    if (rawId !== null && rawId !== '') {
+        const row = requiredPlaylist(db, rawId);
+        const asked = query.get('name');
+        const name = asked === null || asked === '' ? row.name : asked;
+        // Only when the client said something about the songs — see above.
+        const written = store.replace(db, row.id, name, query.has('songId') ? songs : undefined);
+        return { playlist: withSongs(written, db, config) };
+    }
+    const name = required(query, 'name');
+    return { playlist: withSongs(store.create(db, name, songs), db, config) };
+}
+/**
+ * A partial edit: rename, re-comment, add songs, drop songs.
+ *
+ * The two song arguments are applied with the removals first, because a
+ * position names a place in the list the client is holding — see `store.edit`
+ * for what the protocol does and does not say about that.
+ *
+ * A field the client did not send is left alone, and an empty one is left alone
+ * too **except for the comment**: a name of nothing is not a name a client can
+ * have meant to give, and neither is a visibility of nothing, while an empty
+ * comment is exactly how a client takes a comment off a playlist. That one is
+ * stored as no comment rather than as a comment that reads empty — the two look
+ * the same in a client's sidebar and only one of them is true.
+ */
+export function updatePlaylist(db, config, query) {
+    const row = requiredEditable(db, required(query, 'playlistId'));
+    const add = trackIdsIn(query, 'songIdToAdd');
+    requireKnown(db, add);
+    const name = query.get('name');
+    const comment = query.get('comment');
+    const isPublic = query.get('public');
+    store.edit(db, row.id, {
+        ...(name === null || name === '' ? {} : { name }),
+        ...(comment === null ? {} : { comment: comment === '' ? null : comment }),
+        ...(isPublic === null || isPublic === '' ? {} : { public: booleanish(isPublic) }),
+        add,
+        remove: positionsIn(query, 'songIndexToRemove'),
+    });
+    return {};
+}
+/**
+ * A playlist, gone — the songs it named are untouched.
+ *
+ * A second call for the same id is refused as naming nothing, for the reason
+ * every other route refuses one: the client is told its question had no
+ * subject, which is truer than an `ok` about a deletion that did not happen.
+ */
+export function deletePlaylist(db, query) {
+    const row = requiredEditable(db, required(query, 'id'));
+    store.remove(db, row.id);
+    return {};
+}

package/dist/api/rescan.js

@@ -0,0 +1,196 @@
+import { watch } from 'node:fs';
+import { dueAt, quiet, staleReadings, watchable } from "../scan/schedule.js";
+import { SETTLE_MS } from "../scan/settle.js";
+/**
+ * How often to look at the clock, when the interval does not ask for finer.
+ *
+ * Five minutes costs two counts and a row, which is nothing — but a tick coarser
+ * than the interval would make the interval a lie: a deployment that asked for a
+ * scan every minute and got one every five would be a deployment whose setting
+ * does not mean what it says. So the tick is a quarter of the interval whenever
+ * that is finer, and five minutes otherwise.
+ */
+const TICK_MS = 5 * 60_000;
+export function tickFor(schedule) {
+    if (schedule.intervalMinutes <= 0)
+        return TICK_MS;
+    return Math.max(1_000, Math.min(TICK_MS, (schedule.intervalMinutes * 60_000) / 4));
+}
+/**
+ * How long the disk must be silent before a change is followed by a scan.
+ *
+ * **This is the watcher's half of the half-write gate, and the number belongs to
+ * the other half too.** The interval scan faces the same problem with no events
+ * to wait on, so it looks at a recently-written file twice instead — same rule,
+ * same window, and the constant lives with that rule in `scan/settle.ts` rather
+ * than here. Two numbers for one contract clause would be two rules written down
+ * as agreement.
+ *
+ * Waiting for silence is what the watcher owes and cannot avoid: it is told
+ * about an event, not about a file, so the torrent stopping is the only thing it
+ * can wait for. Five seconds rather than one, because a copy over the network
+ * pauses — and a pause longer than the window is the one case neither path
+ * catches, which `settle.ts` states rather than hides.
+ */
+export function rescan(deps) {
+    const now = deps.now ?? (() => new Date());
+    const tick = deps.tickMs ?? tickFor(deps.schedule);
+    const settle = deps.settleMs ?? SETTLE_MS;
+    let stopped = false;
+    /**
+     * Whether the operator has already been told there is nothing to read.
+     *
+     * Said once rather than on every tick: a server with no roots is a server
+     * somebody is about to configure, and a line every five minutes for a week is
+     * a log that teaches its reader to skip lines. Said again if roots come and
+     * go, because then it is news again.
+     */
+    let saidNoRoots = false;
+    let timer = null;
+    let settling = null;
+    const start = (mode, why) => {
+        const started = deps.scanner.start(mode);
+        deps.log(started.ok
+            ? `funoteka: scanning (${why})`
+            : // Not an error: a scan that is already running is a scan, and the
+                // reason this one was asked for is worth saying anyway — it is how
+                // somebody finds out their interval is shorter than their scan.
+                `funoteka: not scanning (${why}): ${started.reason}`);
+    };
+    /**
+     * The roots as they were when the watchers were last reconciled, so that a
+     * tick which finds them unchanged does nothing at all.
+     */
+    let watched = [];
+    const check = () => {
+        if (stopped)
+            return;
+        if (deps.watch) {
+            const now = deps.roots();
+            if (now.join('\u0000') !== watched.join('\u0000')) {
+                watched = now;
+                reconcileWatchers();
+            }
+        }
+        // A scan already on is the answer to every reason to start one.
+        if (deps.scanner.status().running !== null)
+            return;
+        if (deps.roots().length === 0) {
+            if (!saidNoRoots) {
+                deps.log('funoteka: nothing to scan — no roots are configured');
+                saidNoRoots = true;
+            }
+            return;
+        }
+        saidNoRoots = false;
+        const stale = staleReadings(deps.db);
+        // **The quiet hours hold here too.** They are a rule about when a scan may
+        // *start*, and an upgraded deployment whose files are read by an older method
+        // is not urgent enough to be the exception: the tick asks again, and when the
+        // window closes it scans. The review found this trigger walking past the
+        // window that the interval beside it respects.
+        if ((stale.tags > 0 || stale.probes > 0) && !quiet(now(), deps.schedule)) {
+            start('incremental', `${stale.tags} file(s) and ${stale.probes} probe(s) read by an older method — this build reads them again`);
+            return;
+        }
+        const last = deps.scanner.status().last?.startedAt ?? null;
+        const due = dueAt(last, now(), deps.schedule);
+        if (due === null)
+            return;
+        if (due.getTime() > now().getTime())
+            return;
+        start('incremental', last === null ? 'this library has never been read' : `its interval elapsed at ${due.toISOString()}`);
+    };
+    /**
+     * Something changed under a root; scan once the disk has stopped changing.
+     *
+     * The timer is reset by every event, which is the whole of the gate: what is
+     * waited for is silence, and a copy that is still running keeps pushing it
+     * away.
+     */
+    const touched = () => {
+        if (settling !== null)
+            clearTimeout(settling);
+        settling = setTimeout(() => {
+            settling = null;
+            if (stopped)
+                return;
+            // Silent when a scan is already on, and deliberately: the change is either
+            // picked up by the scan that is running or by the next one, and a line per
+            // event would be a log full of a copy that is still going on.
+            if (deps.scanner.status().running !== null)
+                return;
+            if (deps.roots().length === 0)
+                return;
+            start('incremental', `something changed under a root and the disk has been quiet for ${settle / 1000}s`);
+        }, settle);
+        settling.unref?.();
+    };
+    /**
+     * Watch what is configured *now*.
+     *
+     * **Called whenever the roots change, and that is the point.** The first
+     * version built the watcher set once, when the engine was created — so a shelf
+     * added afterwards with `POST /roots` was never watched, while the field beside
+     * it promised "a shelf added a minute ago is watched too". A watcher nobody
+     * notices is missing is the failure this option is careful about everywhere
+     * else, and it was the one place it was not.
+     */
+    const watching = new Map();
+    const reconcileWatchers = () => {
+        const wanted = new Set(deps.roots());
+        for (const [root, watcher] of watching) {
+            if (wanted.has(root))
+                continue;
+            watcher.close();
+            watching.delete(root);
+            deps.log(`funoteka: stopped watching ${root} — it is no longer a root`);
+        }
+        for (const root of wanted) {
+            if (watching.has(root))
+                continue;
+            const can = watchable(root);
+            if (!can.ok) {
+                // Said out loud, and the interval carries on: a watcher that is silently
+                // deaf is worse than no watcher, because the deployment believes it has
+                // one.
+                deps.log(`funoteka: not watching ${root} — ${can.why}; the interval still scans`);
+                continue;
+            }
+            try {
+                // Recursive where the platform has it. Linux does not, and this is the
+                // honest handling of that: one line, and the interval is what scans.
+                const watcher = watch(root, { recursive: true }, touched);
+                watcher.on('error', (err) => {
+                    deps.log(`funoteka: watching ${root} failed (${err.message}) — the interval still scans`);
+                });
+                watching.set(root, watcher);
+                deps.log(`funoteka: watching ${root} for changes`);
+            }
+            catch (err) {
+                deps.log(`funoteka: cannot watch ${root} (${err.message}) — the interval still scans`);
+            }
+        }
+    };
+    if (deps.watch) {
+        watched = deps.roots();
+        reconcileWatchers();
+    }
+    timer = setInterval(check, tick);
+    timer.unref?.();
+    if (deps.startup !== false)
+        check();
+    return {
+        check,
+        stop: () => {
+            stopped = true;
+            if (timer !== null)
+                clearInterval(timer);
+            if (settling !== null)
+                clearTimeout(settling);
+            for (const watcher of watching.values())
+                watcher.close();
+            watching.clear();
+        },
+    };
+}

package/dist/api/roots.js

@@ -0,0 +1,161 @@
+import { statSync } from 'node:fs';
+import { resolve } from 'node:path';
+import { rootKey } from "../scan/scan.js";
+import { parseRoots } from "./scanner.js";
+/**
+ * Every root, with what is under it.
+ *
+ * The counts are per root rather than a total, because the question the listing
+ * answers is "where did my library come from" — a root with nothing under it is
+ * either a shelf that has not been scanned yet or a path that leads somewhere
+ * empty, and those want different answers from whoever is reading.
+ */
+export function listRoots(db) {
+    const rows = db
+        .prepare('SELECT id, path, alias, created_at FROM root ORDER BY path')
+        .all();
+    const runs = recentRuns(db);
+    return rows.map((row) => {
+        // Found once: the two fields below are one run read twice, and asking for it
+        // twice walked the fifty runs twice for every root.
+        const last = lastRunFor(runs, rootKey(row.path));
+        return {
+            id: row.id,
+            path: row.path,
+            alias: row.alias,
+            createdAt: row.created_at,
+            folders: countOf(db, 'folder', row.id),
+            files: countOf(db, 'file', row.id, "AND kind = 'audio'"),
+            albums: countOf(db, 'album', row.id),
+            lastScannedAt: last?.finished_at ?? null,
+            lastScanStatus: last?.status ?? null,
+        };
+    });
+}
+/**
+ * Configure a directory as a root.
+ *
+ * **It has to be there.** A root naming a directory that does not exist is a
+ * deployment that will scan nothing and report success — the classic shape of a
+ * mistyped path — so the path is checked while the operator is still looking at
+ * the answer. The check is a `stat` and not a walk: what is under it is the
+ * scan's business.
+ *
+ * Adding one that is already a root is not an error and not a second row. It is
+ * the same directory, whoever says so — and the answer says it was already
+ * there, because an operator who thought they were adding a shelf should know
+ * they did not.
+ */
+export function addRoot(db, given) {
+    const path = resolve(given);
+    let isDirectory = false;
+    try {
+        isDirectory = statSync(path).isDirectory();
+    }
+    catch {
+        // The sentence below covers both a path that is not there and one that
+        // cannot be read, and the second is rarer than the first by a long way.
+        isDirectory = false;
+    }
+    if (!isDirectory)
+        throw new Error(`not a directory on this machine: ${path}`);
+    const rows = db.prepare('SELECT id, path, alias, created_at FROM root').all();
+    const key = rootKey(path);
+    const known = rows.find((row) => rootKey(row.path) === key);
+    if (known !== undefined) {
+        // The row is kept as it is, and the stored spelling is left alone: it is
+        // what the operator typed when they configured it, and a listing that
+        // silently rewrote it would be reporting a path nobody chose. A scan
+        // canonicalises it, which is the place that has the filesystem's answer.
+        return { root: view(db, known.id), already: true };
+    }
+    const inserted = db
+        .prepare('INSERT INTO root (path, created_at) VALUES (?, ?)')
+        .run(path, new Date().toISOString());
+    return { root: view(db, Number(inserted.lastInsertRowid)), already: false };
+}
+/**
+ * Stop serving a directory, and take what came from it with it.
+ *
+ * **This is the destructive verb, and the cascade is deliberate.** Every folder,
+ * file, album and track under this root is derived from it — `scan.ts` says so
+ * in the schema, `ON DELETE CASCADE` all the way down — so a root that stayed
+ * while its rows did would be a library still serving music from a shelf the
+ * operator had removed from the deployment. The files on disk are untouched:
+ * this is a statement about what this server reads, not about the disk.
+ *
+ * The answer carries the count, because "removed" and "removed a third of your
+ * library" are the same word and not the same event.
+ */
+export function removeRoot(db, given) {
+    const key = rootKey(resolve(given));
+    const rows = db.prepare('SELECT id, path FROM root').all();
+    const doomed = rows.find((row) => rootKey(row.path) === key);
+    if (doomed === undefined)
+        return null;
+    const before = view(db, doomed.id);
+    // One transaction, and `IMMEDIATE` like every other write here: a cascade
+    // that unwound halfway would leave a root whose rows are some of what it had.
+    db.exec('BEGIN IMMEDIATE');
+    try {
+        db.prepare('DELETE FROM root WHERE id = ?').run(doomed.id);
+        db.exec('COMMIT');
+    }
+    catch (err) {
+        try {
+            db.exec('ROLLBACK');
+        }
+        catch {
+            // Already unwound; the original error is what matters.
+        }
+        throw err;
+    }
+    return { root: before, songs: before.files, albums: before.albums };
+}
+/** One root, counted the way the listing counts them. */
+function view(db, id) {
+    const row = db.prepare('SELECT id, path, alias, created_at FROM root WHERE id = ?').get(id);
+    const runs = recentRuns(db);
+    const last = lastRunFor(runs, rootKey(row.path));
+    return {
+        id: row.id,
+        path: row.path,
+        alias: row.alias,
+        createdAt: row.created_at,
+        folders: countOf(db, 'folder', row.id),
+        files: countOf(db, 'file', row.id, "AND kind = 'audio'"),
+        albums: countOf(db, 'album', row.id),
+        lastScannedAt: last?.finished_at ?? null,
+        lastScanStatus: last?.status ?? null,
+    };
+}
+function countOf(db, table, rootId, extra = '') {
+    const row = db
+        .prepare(`SELECT COUNT(*) AS n FROM ${table} WHERE root_id = ? ${extra}`)
+        .get(rootId);
+    return row.n;
+}
+function recentRuns(db) {
+    const rows = db
+        .prepare('SELECT status, finished_at, roots_json FROM scan_run ORDER BY id DESC LIMIT 50')
+        .all();
+    // The same two or three shelves appear in every one of the fifty runs, so the
+    // answer for a path is asked for once and kept.
+    const keys = new Map();
+    const keyOf = (path) => {
+        const known = keys.get(path);
+        if (known !== undefined)
+            return known;
+        const key = rootKey(path);
+        keys.set(path, key);
+        return key;
+    };
+    return rows.map((row) => ({
+        status: row.status,
+        finished_at: row.finished_at,
+        keys: parseRoots(row.roots_json).map(keyOf),
+    }));
+}
+function lastRunFor(runs, key) {
+    return runs.find((run) => run.keys.includes(key));
+}