Allow moving downloads out of the download directory

[djjeck]

I'm using the Docker version. If I understand correctly, if I move any downloaded album out of the downloaded directory, it will get re-downloaded.

I'd like to be able to treat the downloaded directory as a temporary location instead, but then move the downloads to their final well-organized location. Also nice-to-have: since I own hundreds of releases, and I've already downloaded most of them in the last 10 years, it would be great not having to re-download them all.

I'd be happy to contribute, if we agree on the feature request and how to implement it.

Option A Only download releases purchased since the last time the downloader ran. Implementation:

• We add a new --ignore-before flag to the CLI.
• Docker saves a timestamp to a file, at the end of each execution.
• Docker populates the CLI flag by reading the timestamp from the file.
• I checked, there is a purchased date returned by the bandcamp API, and they appear to be returned in reverse order of purchase.
• Optional: this doubles as a way for new users with large collections not to have to redownload everything. We add a new env variable to docker, to initialize the value if the downloader never ran.

Pros:

• Doesn't even need to paginate the purchases page past the specified date Cons:
• Not granular

Option B Once a release is downloaded, mark it as ignored. Implementation:

• We keep a file with ignored release IDs. Every time we download a release, we save the ID, and maybe add a human readable comment too (e.g. 830349541 # AKANE IN TOKYO / あなたと永遠 (Rainbow Edition)).
• We add a new --ignored-releases CLI flag that accepts such file. Docker passes the file from /config
• Optional: this doubles as a granular API to ignore releases. We add a template file to docker /config with instructions on how to fill it in. We might also support artist or full URL (e.g. akaneintokyo.bandcamp.com/album/rainbow-edition).

Pros:

• Granular ignores
• Lets you easily redownload something
• If we don't use filenames to determine whether something has been already downloaded, it's easier to implement custom file naming schemes Cons:
• Still paginates the whole purchases page

Optiona A+B Do you like both? We could do both

[meeb]

This should already be supported. When a release is downloaded there's a bandcamp_item_id.txt file created in the directory. This file contains the Bandcamp item ID as an integer. You can move any music files out of the directory. Providing the bandcamp_item_id.txt file exists the release won't be downloaded again.

[meeb]

Just to confirm does my suggestion work sufficiently to resolve your initial question?

[djjeck]

I apologize, I had missed the bandcamp_item_id.txt files. Unfortunately no, this still doesn't work for me, as the file is inside each album folder. Maybe I'm trying to solve two issues at once.

My problem Right now I need to download the latest 87 out of my 893 purchased releases. Currently, I'd have to:

• download 10x the files I need (which btw won't fit in my server)
• write a script to figure out what to delete because I already got it (based on purchase date, not trivial)
• write another script to move files out (new ones) or delete them (old ones I don't need) while leaving the bandcamp_item_id.txt files behind

And I can't believe this is an edge case. Users of this tool are people who need a Bandcamp downloader in the first place 😅

My requirements

• I only need to download my most recent releases
• I need to store releases elsewhere, with a specific directory naming format Does this make sense?

Let me amend the options above:

Option A Adding an initial flag for a cutoff date solves my first requirement for me. If the process remembers last time it ran and sets the flag accordingly, it solves the second. I already implemented the flag, but it's still very manual: I need to run the container on demand, and change the flag each time. It's only worth it when I buy a full discography.

Option B Basically I was describing moving the bandcamp_item_id.txt information to a central ignore file inside /config. If we do that, it solves my second requirement. And if we ALSO support the initial flag for a cutoff date, we can auto-generate the file on the first run, and solve my first requirement too. And it's more powerful than Option A because you have an escape hatch to remove lines from the file to redownload individual releases, but it's a significant, possibly breaking, change.

[meeb]

I'm fine with adding an additional --ignore-release-ids-file flag which contains a file with the following format:

123144232 # comment after hash
348924892 # another comment after hash

Which should fulfil your option B suggestion. Option A requires parsing the purchased date from the account releases JSON which, from memory, wasn't always reliably available. I'll check though as it would be easy to add a --download-after-purchase-date flag if it's now reliable.

[djjeck]

The missing purchase dates might be resolved. This is my entire collection, and there is a item.purchased for every item: https://hastebin.com/share/ajejugiyig.graphql

I'll put something together during the weekend.

[djjeck]

Done!

• PR #40 adds support for --ignore-file and creates a template ignore.txt file in docker. But I don't think it's practical to obtain many bandcamp ids.
• PR #41 adds entries to the ignores file, if an ignores file is used (always, if you're on docker), instead of creating bandcamp_item_id.txt. This solves my initial request.
• PR #42 goes all the way in removing bandcamp_item_id.txt, by deleting the old ones and adding them to the ignores file. BUT this switches everyone using the command line to a single ignores.txt file.

Each PR comes with its documentation update, and it's split in smaller commits. When you have time, feel free to approve up to the one you're comfortable with, and/or make requests. Thanks!

[meeb]

Thanks! I'll have time to review these later in the week.