managing downloads...

Archived discussion about features (predating the use of Bugzilla as a bug and feature tracker)

Moderator: Moderators

Locked
skeletonized
Posts: 1
Joined: 2005-01-14 12:52
Contact:

managing downloads...

Post by skeletonized » 2005-01-26 13:48

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
================
d a r k b e a t . o r g
================

BSOD2600
Forum Moderator
Posts: 503
Joined: 2003-01-27 18:47
Location: USA
Contact:

Post by BSOD2600 » 2005-01-26 17:23

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)
DC++ Change log wrote:0.669
Added advanced resume that detects and tries to repair rollback inconsistencies using tiger trees

This should help to fix the rollback problem if they do occur.

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.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Re: managing downloads...

Post by GargoyleMT » 2005-01-27 12:21

BSOD seemed to cover the bases pretty well.

skeletonized wrote:+ the ability to override a "error during file decompression" to skip to the next download

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.

BSOD2600 wrote:4) Skipping to the next file would be a smart thing to do, indeed.

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.

Locked