Criminey if there's a set of features that needs to be developed further it's this. Currently I'm stuck with absurd amounts of unfinished and error filled downloads and queues. Heres' some ideas:
+ viewing download queue by user, hub, or file
+ true alternative searching...that doesn't give heaps of rollback errors
+ when a rollback inconsistency occurs, the option to override it and download the file to a new location or overwrite
+ the ability to override a "error during file decompression" to skip to the next download
+ ability to view current downloads, downloads by connection
Any of these in any capacity would help me immensely. Thanks
managing downloads...
Moderator: Moderators
-
- Posts: 1
- Joined: 2005-01-14 12:52
- Contact:
managing downloads...
================
d a r k b e a t . o r g
================
d a r k b e a t . o r g
================
1) Since the download queue is a global thing, I doubt it will be broken up by hub. By user would be useful. The current view is by file...
2) Rollback errors are not because of the remote user. Searching by TTH solves the problem of finding true identical alternative sources. You using that?
3)
4) Skipping to the next file would be a smart thing to do, indeed.
5) You can view your current downloads in the Transfers window (ctr+3). Downloads by connection? As in the connection type a user has specified? If so, thats compleatly pointless since what a user sets is arbitrary and often isnt a true reflection of their speed.
2) Rollback errors are not because of the remote user. Searching by TTH solves the problem of finding true identical alternative sources. You using that?
3)
This should help to fix the rollback problem if they do occur.DC++ Change log wrote:0.669
Added advanced resume that detects and tries to repair rollback inconsistencies using tiger trees
4) Skipping to the next file would be a smart thing to do, indeed.
5) You can view your current downloads in the Transfers window (ctr+3). Downloads by connection? As in the connection type a user has specified? If so, thats compleatly pointless since what a user sets is arbitrary and often isnt a true reflection of their speed.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: managing downloads...
BSOD seemed to cover the bases pretty well.
There's a rare bug that causes an erroneous "error during decompression" that is fixed in the next version. If that version doesn't fix it, then something is corrupting your transfer, such as a bad network card, cable, or software firewall.skeletonized wrote:+ the ability to override a "error during file decompression" to skip to the next download
That's not always possible. If DC++ throws a rollback error, it knows that the file isn't compatible with the local temp file, but the remote end is still expecting to send the whole file. Disconnecting, and potentially losing your slot, is the only way you can recover. In that scenario, you wouldn't be able to just skip to the next file. At least in that session. Now, as far as picking a different file from the queue, I thought this was the way it was done - that DC++ wouldn't knowingly get stuck on a retryable error from a single file.BSOD2600 wrote:4) Skipping to the next file would be a smart thing to do, indeed.