Some small proposed improvements#67
Conversation
|
Thanks for the PR. There's already a Given the entire point of bandcampsync is to sync your bandcamp purchases I'm not really sure how in demand a "stop downloading at" cut-off option is likely to be, but if I were to merge one it would probably be the purchased date based stop. With your edge case, this is an item that is listed as an album type that downloads as an uncompressed single track, correct? |
|
Hi, please could you update the issue? |
|
Apologies, I had addressed the comments but failed to push them, here they are, updated (and commit messages). Commit 2 isn't similar to Commit 1 now only has date, not regexp, and I confirm your understanding for commit 3 (which is a bug fix, not a feature). |
|
Fair enough, thanks for the update. I've just been working on this for a new release so if you could tweak those merge conflicts I'll give your PR a full review. Cheers. |
Add CLI and service controls for stopping collection processing at a purchase date, plus dry-run support for previewing downloads. This allows syncing in batches without downloading or writing files during a preview. The cutoff is applied both during pagination and again during sync selection so the date boundary is handled consistently, including physical-only collection entries.
Persist the newest seen collection token and use it on later runs to stop Bandcamp pagination once previously synced items are reached. This is not the same as the existing skip-item-index path: that only avoids building the local media index when ignored IDs make it safe, while the checkpoint limits remote collection pagination and still lazily verifies candidate new items against their expected local path. On my ~1200-item collection, a dry-run benchmark that made the old path maximally favorable with --skip-item-index and an ignore file still fetched 13 collection pages and averaged 12.8s, while the checkpoint path fetched 1 page, saw 2 newer items before the saved token, and averaged 1.2s.
Accept non-zip downloads when Bandcamp returns an audio content type, even if the collection item is not classified as a track. This fixes single-release album downloads that are served as one MP3 or other audio file instead of an archive. Example: https://mala-music.bandcamp.com/album/militant-don
|
Rebased, sorry I should have done it earlier today. |
|
Yep looks fine, thanks. I'm going to tidy the project up a bit before the next release as a few AI-sourced PRs have made the structure a little chaotic, then I'll bundle this into the next release. Thanks for the contribution! |
2 participants
Thanks for the great program. I've implemented two small features (with tests), for my own use, I wonder if they would be of interest for others:
artist - release name, or a purchase date -- I implemented this to make it easier to perform the initial sync in batches, my collection is fairly large. Also adds a dry run mode that was helpful for debuggingIn addition, fixing a small bug: downloading a release that consists in a single file (e.g. the excellent https://mala-music.bandcamp.com/album/militant-don) didn't work, the program was expecting a zip. This caused the second feature to error out and not write its state file in my case.