Join GitHub today
[220.127.116.11] Append new download tasks into active batch process, if running #41
If you add a batch job for a gallery download and start it, then go back to the member processor and add a few more, these added tasks show up only as "queued" in the batch list, and will not start if there are free task slots open, or when the first job finishes. So it appears to only actually queue the files in the list at the time the button is pressed.
FileZilla FTP does that as well. It's tough to say whether it adds functionality (creating up to two distinct "queues" within the download list, with a pause built in before activating the second) or just makes it so I can't start my downloading until I've created the queue that I want in full (or resuming).
I end up using it the way it behaves (like to test download one file but leave the rest "on deck"), but I don't think that's very useful for NijieDownloader; the images are visible in the member and image viewers, and the content is small enough that it seems more convenient to program for the generation of a "continual" download list that lets you browse while the (rather slow) downloading occurs (more like DownThemAll, and probably most downloading programs).
It's also awkward to not know which items I added before and then after I started the batch, since tasks in both of these queue states simply say "Queued."
Obviously low-priority, and perhaps something you designed intentionally because that makes sense to your thinking/workflow. Either way, just a minor observation while I noticed it again ^^
changed the title from
Append new searches into active download batch, if running?
[18.104.22.168] Append new download tasks into active batch process, if running
Mar 24, 2017
referenced this issue
Mar 24, 2017
I forgot I segued into this in another issue (#23) about the batch queue. I didn't mean to get pushy about it, lol...but as a distinct behavior/option it technically belongs by itself anyway (and #23 can be closed).
Labeled this with the current version, though it has been this way probably back into the 1.0.6x's (unless the aforementioned batch freezing error prevented the behavior).