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
ytdy — the YouTube provider
Mounts YouTube at /youtube in the crabidy library.
How it works
Metadata comes from the pure-Rust rustypipe Innertube client:
/youtube/searchworks without any login. Press%to create a search term; the term becomes a persistent child node listing the top video results as tracks. Terms are renamable (e, re-runs the search) and deletable (d). Terms live in memory — a server restart forgets them, but navigating to an old term path recreates it./youtube/playlistsappears when a cookie login is configured and accepted: it lists the account's saved playlists.
Stream URLs are resolved through a minimal yt-dlp sidecar when
the binary is available (one bounded subprocess call per played or
captured track — no other functionality uses it). This is a deliberate
concession: YouTube currently caps tokenless stream URLs at their
leading ~1 MiB, and yt-dlp is the only maintained solver for the
cipher challenges that lift the cap; its URLs stream whole files at a
throttled ~32 KB/s (still ~2× audio bitrate). Without the binary the
provider still works, but playback of a track stops after roughly a
minute. Streams prefer audio/mp4 (AAC), the format the built-in
player decodes; captures therefore store .m4a files.
Search results and playlists are downloadable: W captures them with
audio into /crabidy/<name> (slow under the throttle, but captures
are resumable — re-capture the same name to continue).
Logging in (optional)
Search and playback need no login. A cookie export only adds
/youtube/playlists, the saved playlists of an account:
- Export your YouTube cookies in Netscape
cookies.txtformat — a browser extension like "Get cookies.txt LOCALLY" does it. Doing this from an Incognito window you close afterwards keeps the session from being rotated out from under the file. - Point
cookiesat the file (see below) and restart the server. - The provider caches the rotated session cookie under
~/.config/crabidy/rustypipe/, so the export only has to be valid once.
Rejected or missing cookies degrade to logged-out with a warning; nothing else is affected.
Configuration — ~/.config/crabidy/ytdy.toml
All options with their defaults:
# Netscape cookies.txt export for the logged-in features (saved
# playlists). Export with a browser extension like "Get cookies.txt
# LOCALLY", ideally from an Incognito session you close afterwards.
# The provider caches the rotated session cookie under
# ~/.config/crabidy/rustypipe/, so the export only needs to be valid
# once. Default: unset (logged out; search still works).
# cookies = "/home/me/youtube-cookies.txt"
# Results per search term. Default: 20.
# search_results = 20
# Per-request timeout in seconds (Innertube calls; the yt-dlp sidecar
# gets at least 60 s). Default: 30.
# call_timeout_secs = 30
# The yt-dlp binary used ONLY for stream URLs. A bare name resolves
# via PATH. Default: "yt-dlp". Keep it fresh — a stale yt-dlp is the
# first suspect when YouTube playback breaks.
# binary = "yt-dlp"
# Optional rustypipe-botguard binary for PO-token attestation (also
# auto-detected on PATH). Currently ineffective upstream, but once
# rustypipe's web-client deciphering is fixed this makes streams work
# without yt-dlp. Default: unset.
# botguard_bin = "/home/me/.cargo/bin/rustypipe-botguard"
Secrets: the cookies file and the rustypipe cache grant access to your YouTube session — keep both private. The provider never logs their contents (paths only), and stream URLs are redacted from logs.
Failure behavior
- No network / broken client at startup: only
/youtubeis disabled, the server runs on. - Rejected or missing cookies: degrades to logged-out with a warning.
- Missing
yt-dlp: warning at startup; streams stop after ~1 MiB. 403 Forbiddenon streams in the log: YouTube's per-IP/per-video enforcement fluctuates; usually transient. If it persists, updateyt-dlp.
Build the server without the youtube cargo feature to leave this provider
(and the rustypipe dependency) out of the binary entirely.