Multiple Instances in Finished Downloads tab

[Osiris2258]

Every File I download is appearing upwards of 50 times in the "finished downloads" area. All of these have timestamps seconds apart. What I think is happening is that the file is registering as done every time a segment finishes.

Windows XP
0.705

[Pietry (pietry)]

In the finished downloads tab, there aren't multiple instances, it's the same file, but each chunk appears there when it's finished. So you have the same filename, but for each chunk ( segment ) , it appears as if it was finished. Look into the downloads tab in the lower frame to see your download in one piece ( with all the segments and users downloading from ).
Anyway you're right about the spamming in the finished downloads tab, so I'm moving this to wishlist and in progress status. ( Hoping that somebody will come up with a solution ).

[Jacek Sieka (arnetheduck)]

In progress means someone is actively working on it (to avoid two people working on the same thing)...afaik noone is fixing this right now so confirmed is a better status...

[Slowmo (slowmo)]

I was just about requesting the same thing, but found this.
An option to log each segment or finished files only would be good.

[Ben (mimenarrator)]

I would just add that this is also an issue in the finished uploads tab, and causes each 350mb file downloaded by someone using DC++ 0.705 to appear 350 times on the list, which is not ideal, to say the least.

[Ac3T (ace-mineg)]

Slowmo - I don't think things like that would be a good idea since things like that tends to consume memory... Not particulay fun if you're downloading an entire, say Windows-directory, as some no0bZ find it fun to share, and you've downloaded 12000 files, and when you're open that log-file, if Windows has'nt crashed yet, it probably will... I mean if DC is to log every downloaded segment.

I'm no developer, but that's what I feel would happen.

Not everyone out there has an über-puter with min. 4 GB's of RAM so...

[Slowmo (slowmo)]

Ac3T - what I meant was ability to chose whether to show each segment in finished downloads or only finished files, although I don't see a point in showing segments. Maybe only for uploads, since you can't really tell that file has been downloaded from you. Maybe it was just a last segment.

[qwertitis (qwertitis-deactivatedaccount)]

I've "fixed" this on my local Linux DC++. This is just a ugly hack though, showing how it could be done. The FinishedManager is kinda out of sync with all the segment stuff being introduced. What I've done here is simply make it listen to QueueManager (knowledge about files be here) instead of DownloadManager (only knows about segments). The QueueItem would have to be extended in order to provide the information needed for the FinishedItem. The "finished uploads" are still being spammed though. That would have to have a different GUI, or a different design of FinishedManager, or both.

Regards
David

[Ben (mimenarrator)]

I've fixed this for the Finished Uploads list by changing a line in FinishedManager.cpp from:

fire(FinishedManagerListener::Added(), true, item);

to:

File* f = new File(u->getPath(), File::READ, File::OPEN);
if(f->getSize() == u->getSize() + u->getStartPos()) {
 item->setSize(f->getSize());
 fire(FinishedManagerListener::Added(), true, item);
}
f->close();

There may well be a cleaner way of doing this, but it seems to be working.

[Big Muscle (bigmuscle)]

Ben: It's not a solution, because when upload finishes at position different from end of file, it won't log anything.

[poy (poy)]

this patch adds 2 tabs in each finished window; "grouped by files" and "grouped by users"; the aggregation happens in dcpp/.

at first i tried to use boost::multi_index which would have allowed to have only one array of finished items that can be accessed in several ways; but in this case, since we have 2 possible unique keys (files and users), this was completely useless. thus there are now 2 arrays (maps), 1 indexed by file, the other by user.
note that the previous finished entries stored users/hubs as strings; now they're stored as pointers to the User class.

misc notes:

- i used a TaskQueue in the finished window because the speaker with its unique lParam didn't quite cut it.

- "grouped by files"/"by users": rename to "files"/"users" ?

- the "time" column actually means "last updated" now; rename it?

- i moved/changed/added/removed columns here and there so sizes may have changed...

- a file is shown as soon as one segment is finished; while this is optimal for uploads, it may be best to not show finished downloaded items in the "files" tab until the file is actually finished. note that we still want to keep track of users so listening to the queue instead of the downloads manager is not an option...

- there are some nice user icons in the "users" tab. :)

- added "enter" key to open the file in the "files" tab.

- added user menu items just like the ones in the search window.

[Jacek Sieka (arnetheduck)]

Some comments:
while a set of users is semantically correct, it is unnecessarily complex and loses order of in which users are added...vectors actually tend to be faster for small datasets as well

the locklists bit would probably be better off with a getCS and a scoped_lock to prevent missing unlocks (this needs fixing in the other parts of dc++ as well)

in transfer, I think there's a good reason why a copy of the user is returned, not a reference (probably a threading thing)...it can still be consitified when returning a copy (it's actually more correct that way)

[poy (poy)]

- i probably used a set because it's made to have unique entries; i'm actually wondering why i used a StringList in FinishedUserItem and not a set of strings, too... anyway, changed to vectors, it actually makes other things easier.

- i haven't changed the lock mechanism, as i'm not sure about it.

- the transfer getUser function has been fixed.

[Jacek Sieka (arnetheduck)]

Ok, I'll have a look at the lock stuff later...

[Pfmk2 (wbsimsjr)]

Is there a work around for the Download & Upload logs? Maybe a fix to just report when the downloaded file is actually completed, if a chunk log is needed, maybe make it a session state log that clears between sessions. It's really becoming a pain in the WhoWho opening up that log, which takes quite a while btw.. to just trim the log?? anyone got a code fix for winXP?

[poy (poy)]

do not hijack old fixed bugs just because you want to post yours which is vaguely related to this one...