feat(libation): strip the Audible intro/outro from downloads #954

2026-09-25T05:38:46Z

claude-bot commented

2026-09-25 05:38:46 +00:00

Enables Libation's StripAudibleBrandAudio ("This is Audible" / "Audible hopes you have enjoyed this program"). Libation cuts it losslessly using Audible's own intro/outro offsets from the license chapter info — no re-encode.

Also sets OverwriteExisting: default false makes a re-downloaded book land as Title (1).m4b next to the original; with true it replaces the file in place. Needed for the retroactive pass.

How: Settings.json on the PVC is seeded once from OpenBao; the image entrypoint copies it into ephemeral /config-internal each run (and already uses jq there for Books/InProgress). The CronJob args now set both flags there with jq before scan/liberate, so the setting lives in git, not as PVC drift.

Scope: only books decrypted after merge. Existing files are untouched until re-liberated (LibationCli liberate <ASIN> or liberate --force) — handled separately, one book first.

Sources: Configuration.PersistentSettings.cs (StripAudibleBrandAudio, OverwriteExisting, both default false), DownloadOptions.Factory.cs stripBranding, FileUtility.GetValidFilename, Docker/liberate.sh @ v14.2.1.

🤖 Generated with Claude Code

Enables Libation's `StripAudibleBrandAudio` ("This is Audible" / "Audible hopes you have enjoyed this program"). Libation cuts it losslessly using Audible's own intro/outro offsets from the license chapter info — no re-encode. Also sets `OverwriteExisting`: default `false` makes a re-downloaded book land as `Title (1).m4b` next to the original; with `true` it replaces the file in place. Needed for the retroactive pass. **How:** Settings.json on the PVC is seeded once from OpenBao; the image entrypoint copies it into ephemeral `/config-internal` each run (and already uses `jq` there for `Books`/`InProgress`). The CronJob args now set both flags there with jq before `scan`/`liberate`, so the setting lives in git, not as PVC drift. **Scope:** only books decrypted after merge. Existing files are untouched until re-liberated (`LibationCli liberate <ASIN>` or `liberate --force`) — handled separately, one book first. Sources: `Configuration.PersistentSettings.cs` (`StripAudibleBrandAudio`, `OverwriteExisting`, both default false), `DownloadOptions.Factory.cs` `stripBranding`, `FileUtility.GetValidFilename`, `Docker/liberate.sh` @ v14.2.1. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit 2026-09-25 05:38:47 +00:00

feat(libation): strip the Audible intro/outro from downloads

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

ci/woodpecker/pr/ci-manifests-test Pipeline was successful

Details

ci/woodpecker/pr/pr-review Pipeline was successful

Details

5bca64898b

Enables StripAudibleBrandAudio (Libation trims the branding using Audible's
own chapter offsets, lossless) and OverwriteExisting, so a re-liberated book
replaces its file instead of landing next to it as 'Title (1)'.

Settings.json on the PVC is seeded once and the entrypoint copies it into
ephemeral /config-internal each run, so the flags are applied there with jq
(already in the image; the entrypoint uses it for Books/InProgress).

Only affects books decrypted from now on; existing files need a re-liberate.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

k.renner merged commit 407c366474 into master

2026-09-25 05:41:57 +00:00

k.renner referenced this issue from a commit

2026-09-25 05:41:57 +00:00

Merge pull request 'feat(libation): strip the Audible intro/outro from downloads' (#954) from feat/libation-strip-branding into master

review-bot reviewed

2026-09-25 05:41:59 +00:00

review-bot left a comment

🤖 Automated review — model CLI default (complexity: unknown), commit 5bca64898b9bafface9525dd9784a901e7f4eaa2.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

Small, well-scoped change: before each scan/liberate pass, jq flips StripAudibleBrandAudio and OverwriteExisting to true in the ephemeral /config-internal/Settings.json, then atomically replaces it via a .tmp + mv. The write-to-temp-then-rename pattern is safe under set -e (a failing jq never touches the real file), and the change is consistent with the existing comments describing how /config-internal is staged per-run. No blocking issues found.

🟡 Suggestions

kubernetes/apps/libation/cronjob.yaml:110-112: this shell runs inside a container args block, which ci-manifests-test.yml's own comments (lines 182-185) call out as not covered by kustomize-build or shellcheck — both only see standalone .sh files under kubernetes/, not exec blocks embedded in manifests. The correctness of this change (in particular, whether jq is actually present in rmcrackan/libation:14.2.1, and whether the entrypoint really populates /config-internal/Settings.json before exec'ing these args) rests entirely on the PR author's out-of-repo reading of liberate.sh/Configuration.PersistentSettings.cs, cited in the PR body — I can't verify either claim from this checkout since the image source isn't vendored here. If jq were missing or the file weren't staged yet, set -e would abort before LibationCli scan/liberate ever run, turning this into a silent full outage of the nightly job (CronJob would just show a failed pod). Worth confirming with the first scheduled run (or a manual kubectl create job --from=cronjob/libation) rather than assuming green-until-3am.

Tests

No automated test exercises this path (by the CI file's own admission, embedded exec-block shell is an acknowledged gap), so verification is necessarily a live run of the CronJob. Given the PR body already scopes a manual retroactive liberate pass separately, folding a check of the next scheduled/triggered run's logs (for jq succeeding and the flags landing) into that same manual step would close the loop cheaply.

Recommendation

Looks reasonable — no blocking issues; comment above is optional but worth a quick live-run check given the change is invisible to existing CI.

🤖 **Automated review** — model `CLI default` (complexity: unknown), commit `5bca64898b9bafface9525dd9784a901e7f4eaa2`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary Small, well-scoped change: before each `scan`/`liberate` pass, `jq` flips `StripAudibleBrandAudio` and `OverwriteExisting` to `true` in the ephemeral `/config-internal/Settings.json`, then atomically replaces it via a `.tmp` + `mv`. The write-to-temp-then-rename pattern is safe under `set -e` (a failing `jq` never touches the real file), and the change is consistent with the existing comments describing how `/config-internal` is staged per-run. No blocking issues found. ## 🟡 Suggestions - `kubernetes/apps/libation/cronjob.yaml:110-112`: this shell runs inside a container `args` block, which `ci-manifests-test.yml`'s own comments (lines 182-185) call out as *not* covered by `kustomize-build` or `shellcheck` — both only see standalone `.sh` files under `kubernetes/`, not exec blocks embedded in manifests. The correctness of this change (in particular, whether `jq` is actually present in `rmcrackan/libation:14.2.1`, and whether the entrypoint really populates `/config-internal/Settings.json` before `exec`'ing these args) rests entirely on the PR author's out-of-repo reading of `liberate.sh`/`Configuration.PersistentSettings.cs`, cited in the PR body — I can't verify either claim from this checkout since the image source isn't vendored here. If `jq` were missing or the file weren't staged yet, `set -e` would abort before `LibationCli scan`/`liberate` ever run, turning this into a silent full outage of the nightly job (CronJob would just show a failed pod). Worth confirming with the first scheduled run (or a manual `kubectl create job --from=cronjob/libation`) rather than assuming green-until-3am. ## Tests No automated test exercises this path (by the CI file's own admission, embedded exec-block shell is an acknowledged gap), so verification is necessarily a live run of the CronJob. Given the PR body already scopes a manual retroactive `liberate` pass separately, folding a check of the next scheduled/triggered run's logs (for `jq` succeeding and the flags landing) into that same manual step would close the loop cheaply. ## Recommendation Looks reasonable — no blocking issues; comment above is optional but worth a quick live-run check given the change is invisible to existing CI.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#954