Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make DownloadMaxTries configurable #13

Closed
beatcracker opened this issue Nov 16, 2016 · 9 comments
Closed

Make DownloadMaxTries configurable #13

beatcracker opened this issue Nov 16, 2016 · 9 comments
Labels
feature-request New feature or request

Comments

@beatcracker
Copy link

Default 10 in the release version is too low. Out of curiosity, I've patched it with Reflexil to int32.MaxValue and found that it needed ~80 retries to complete download in my case. Plus, could we have infinite retries?

Oh, and thanks! This tool is very convenient for those who don't want to keep Bandcamp open in the browser all the time.

@Otiel
Copy link
Owner

Otiel commented Nov 18, 2016

I could add that as an option. I don't feel confident setting infinite retries by default because that would induce a lot of network requests for nothing if for some reason you let the program work and Bandcamp is blocking you.

@beatcracker
Copy link
Author

Thanks!

P.S> Something like exponential backoff could be used for infinite retires, so we don't flood Bandcamp with requests.

@Otiel
Copy link
Owner

Otiel commented Nov 18, 2016

The thing is, I don't know how the Bandcamp anti-spam filter works. I'll have to do some tests in order to see if waiting between retries would be enough (maybe they're blocking the download of the particular song until you try to download another one... there's a lot of possibilities here).

@beatcracker
Copy link
Author

If you could provide me with test case (request log or something), I probably could make simple PowerShell script that will d/l files with configurable delays. This'll make it easier to run tests with reproducible results.

@ajsnyde
Copy link
Contributor

ajsnyde commented Dec 18, 2016

@Otiel Mind if I give this feature a go? I'd use a spinner for retries, with a combobox for exponential backoff strategy. Alternatively, I can create a little option bar/window on the top rail if needed.

@Otiel
Copy link
Owner

Otiel commented Dec 19, 2016

@ajsnyde If you can work something out, be my guest.

@ajsnyde
Copy link
Contributor

ajsnyde commented Dec 20, 2016

I've created a partial workaround here:
25bb3e9
In summary, you can change the number of retries indirectly through the json settings file. Good luck, and let me know if that works.
I'm plan to add the retry strategy soon.

@ajsnyde
Copy link
Contributor

ajsnyde commented Dec 20, 2016

See comments and changes here: ajsnyde@73bc604

"Added retry cooldown settings. DownloadRetryCooldown can be set, which puts the application to sleep after each failed attempt to download (in seconds). DownloadRetryExponential Can be set to increase the cooldown with each successive failed attempt. Default values of 0.0 and 1.0 should leave the application running as it does without this commit. After a little experimentation, I found that using 0.2 seconds and 2.0 exponential factor, and 7 DownloaddMaxTries prevents all failures. I am unable to "spam out" the service and not get my album/songs. All of these settings must be set using the json settings file. master"

I've added two more properties to the settings file. As a quick reminder, you will need to re-save your settings file and then edit the values for these changes to take effect.

@Otiel
Copy link
Owner

Otiel commented Jan 3, 2017

I've released a new version with @ajsnyde changes.

@Otiel Otiel closed this as completed Jan 3, 2017
@Otiel Otiel added feature-request New feature or request and removed enhancement labels Dec 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants