Repository navigation
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (5)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughChangesCatalog voice backup handling
Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Bug fix Sequence Diagram(s)sequenceDiagram
participant PiperRun
participant SortCatalogVoices
participant WyomingPiper
PiperRun->>SortCatalogVoices: Sort matching voices before startup
SortCatalogVoices-->>PiperRun: Return moved voice summary
PiperRun->>WyomingPiper: Start with /data and /data/catalog_voices
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 1 files. (4 skipped: 4 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
2.5.2 stopped excluding "*.onnx" from backups, because the new web interface can upload voices and an uploaded voice exists nowhere else. That is right for uploads, but it also put catalog voices back into every backup: a single model is 20-110 MB, and the add-on downloads it again from HuggingFace whenever it is missing. An install with two voices adds over 130 MB to each backup for files that a restore would fetch anyway. wyoming-piper writes downloads and uploads to the same --download-dir, so the two cannot be separated by configuration. Instead, sort them at startup: a voice whose md5 matches what the catalog publishes for that name is moved to /data/catalog_voices, which config.yaml excludes, and that directory is passed as another --data-dir so the voice keeps working and is not downloaded again. After a restore it is simply absent, which is the state of a fresh install, and it is downloaded on demand. Matching on the hash rather than the name keeps a custom voice that reuses a catalog name - a fine-tune exported as en_US-lessac-medium.onnx, say - in /data and in backups. Names are checked before hashing, so a custom voice under a custom name is never read. --download-dir stays /data, so a voice downloaded while the add-on runs is moved only at the next start. That way the failure mode is one larger backup rather than an upload that is missing from one.
b16bb00 to
e362b92
Compare
|
Hi @tronikos, the code for the app your PR was targeting was migrated to home-assistant/app-piper. Please submit a new PR there. Please leave out the version bump and the CHANGELOG.md entry. The version now comes from the GitHub release, and the PR title goes into the release notes. Thank you! |
|
Thanks @sairon! I've submitted a new PR at home-assistant/app-piper#4 (also updated so catalog voices downloaded at runtime go straight to One question: |
|
@tronikos Apparently GH doesn't count people with "Custom" watch settings as a watchers, because I do have monitoring for PRs enabled there and it still shows 0 :) Otherwise it's up those who feel responsible for the app, ideally @synesthesiam should subscribe there (or create |
2.5.2 stopped excluding "*.onnx" from backups, because the new web interface can upload voices and an uploaded voice exists nowhere else. That is right for uploads, but it also put catalog voices back into every backup: a single model is 20-110 MB, and the add-on downloads it again from HuggingFace whenever it is missing. An install with two voices adds over 130 MB to each backup for files that a restore would fetch anyway.
wyoming-piper writes downloads and uploads to the same --download-dir, so the two cannot be separated by configuration. Instead, sort them at startup: a voice whose md5 matches what the catalog publishes for that name is moved to /data/catalog_voices, which config.yaml excludes, and that directory is passed as another --data-dir so the voice keeps working and is not downloaded again. After a restore it is simply absent, which is the state of a fresh install, and it is downloaded on demand.
Matching on the hash rather than the name keeps a custom voice that reuses a catalog name - a fine-tune exported as en_US-lessac-medium.onnx, say - in /data and in backups. Names are checked before hashing, so a custom voice under a custom name is never read.
--download-dir stays /data, so a voice downloaded while the add-on runs is moved only at the next start. That way the failure mode is one larger backup rather than an upload that is missing from one.
Summary by CodeRabbit
Bug Fixes
Documentation