The docs drifted behind three changes: the /queues + /bookmarks + /captures split folding into one /crabidy provider, three providers arriving (soundcloud, jamendo, abs) with nothing written about them, and the spectrum toggle moving off v to f when library visual mode took v/V. - The book gains a page per undocumented provider — /soundcloud, /jamendo, /abs — each with its tree, its playback path, every config option, and how to log in. The providers index and intro list all nine roots in the order the server actually serves them. - Every provider now documents its login: Tidal's device flow (and that a broken tidaly.toml is the one fatal provider config), audiobookshelf API keys, the optional SoundCloud token and where to read it out of a browser, YouTube cookie exports, Jamendo's shipped key, and "nothing to do" for fyyd and /fs. - fsdy's README described three server-managed mounts under ~/.config/crabidy that have not existed for a while; it now describes /crabidy over the state dir plus the shared content store, and how deletes there never touch store audio. - Stale /captures/<name> save paths in the tidaldy and ytdy READMEs are /crabidy/<name>. The TUI key table, the README walkthrough, and the spectrum section use f, and visual mode (v/V) is documented. - config.md and the README list all seven provider config files, say plainly that credentials are stored in cleartext, and cover the audio output device; the CLI page documents audio-devices and features. - No README or docs page references architecture/, quality/, or plan/ any more: the book describes the system as it is, and points at the crate READMEs for usage and config. - devenv-docs.nix was never committed even though devenv.nix imports it, so a fresh clone could not enter the shell at all. It is in now, which also makes the README's `devenv shell -- docs` work. Also fixes two ./store.md links in providers/fs.md that pointed one directory too shallow. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
README.md
fsdy — the filesystem provider
Mounts a local directory at /fs in the crabidy library. The same
engine also powers the server-managed /crabidy mount (saved queues,
bookmarks, and captures), so everything below applies to its on-disk format
too.
No login: the provider only reads a directory you point it at.
How it works
The provider walks one configured root directory. Every directory
becomes a queueable library node; every file ending in
.cbd-track.toml becomes a track; everything else (audio files,
covers, hidden entries) is invisible to the library. Listing order is
case-insensitive by file name — prefix files with numbers to fix an
order (the save writers use 0001-style prefixes for exactly this
reason).
A track file carries the track's metadata plus a reference to the playable thing:
title = "We Will Rock You" # required
artist = "Queen" # optional
duration = 122 # optional, seconds
[album] # optional
title = "News of the World"
release_date = "1977-10-28"
# Exactly ONE of the following four:
[playable]
file = "we-will-rock-you.flac" # local audio; absolute, or relative to
# this file's directory (relocatable)
# url = "https://example.org/radio.mp3" # http(s) stream
# link = "/tidal/artists/1/2/3" # another provider's track
# skipped = true # no audio: a capture recorded its
# source as uncapturable; shown red,
# skipped by playback
Malformed track files are skipped with a warning; they never break the
listing. link playables resolve exactly one hop (a link to a link
fails at play time), which keeps cycles impossible.
Configuration — ~/.config/crabidy/fsdy.toml
# Absolute path of the directory to expose under /fs.
# Default: the platform music directory (e.g. ~/Music). When neither is
# available the /fs mount is disabled — the rest of the server runs on.
# root = "/home/me/music"
The server-managed /crabidy instance
/crabidy is a second instance of this same provider, over the server's
state directory ~/.local/state/crabidy/, written by the server (queue
persistence, w, W) and readable with any file manager — it is just
folders of the track files described above.
- Each top-level folder is one save. It can be renamed (
e) and deleted (d) from a client. currentis the continuously persisted play queue and is protected: you cannot save over that name.- A captured track's
[playable]is astoreentry naming a file in the content store at~/.local/share/crabidy/, which is shared and de-duplicated across every save. - Deleting inside
/crabidyremoves only the metadata toml, never the shared store audio — other saves may point at the same file. Audio that ends up referenced by nothing shows up under/orphans, where you can delete it for real.
The scan subcommand writes exactly these track files for a folder of audio,
so an existing music collection browses under /fs without any manual work:
crabidy-server scan ~/Music # index in place
crabidy-server scan ~/Downloads --capture # copy the audio into the store
Building the server without the fs cargo feature drops this provider, the
content store, /crabidy, /orphans, queue persistence, and scan — they
all share the same on-disk machinery.