Option to decide which Filelist-type to download

[Chris]

Hi,

first of all, I´m new to this forum.
I just read lots of threads and the requests on the sourceforge main page, but I didn´t find that subject yet. I hope I didn´t just overlook it.

OK, the hashing is implemented, and I think it´s a mighty good thing, even though I never had any corrupt files yet (*knockonwood*). It also takes away the ability to continue a file, by choosing a larger one after finding out, that the DL´ed one was incomplete. But that seems to be a minor issue to me.

Now to finally come to the point: Is it possible to implement a function (right-click or so), which allows you to decide whether to download the new Filelist-format including the hashes, or just the old one, which is a lot smaller? The point is, what really annoys me, is to search for a 20 kB file, doing an automatic match of the queue, and then having to wait for hours (no kidding) to download that 6 MB file list through a 250 B/s connection.
That just happened to me. OK, I quitted that Filelist download then, and put the file somewhere else, but that´s impossible if absent, and often users are only in a hub for less time than it takes to download their list.

At least I think, that could be helpful...

Cheers,
Chris

[BSOD2600]

Is it possible to implement a function (right-click or so), which allows you to decide whether to download the new Filelist-format including the hashes, or just the old one, which is a lot smaller?

No.
If you did that, how would DC++ know that the file was hashed? That would defeat a large purpose of the hashing now in DC++.

what really annoys me, is to search for a 20 kB file, doing an automatic match of the queue, and then having to wait for hours (no kidding) to download that 6 MB file list through a 250 B/s connection.

that is a entirely seperate issue... either the user is severly limiting their upload or has way too many slots open. Either way, IMO you shouldnt be downloading from them.

[Chris]

Thanx for your answer.
I guess you´re right, but it´s not exactly a different issue.
My own list´s size increased by around 400% (155kB - 607kB).
The biggest list I´ve seen before V 0.401 was around 1.8MB, and this guy´s share was huuuuuge! Also it was uncompressed. Now 2MB is sth quite normal.
That also brings traffic in general up quite a lot, especially because DC++ updates the file-list on every re-entrance of a user to the hub (did it before?) and every new search hit.
There I have another idea: How about checking, if there´s already a local version of the list, e.g not older than 24h?

Anyway, if that´s the price for hashing, I guess it´s worth it. Searching is a lot easier, especially with files like data1.cab, setup.exe or so.

But since we´re at it...
...don´t want to open a new thread, is it possible to hold on to a slot while downloading some under 20kB files?
It recently happened to me, that I added sth to my queue while DL´ing. After that file was finished, DC++ picked all the highest priority stuff (some 20 files), and when it had finished, the slot was gone.
The user hasn´t been back yet.

[Todi]

Biggest XML filelist i've ever seen was 3.86MB, and that was a 3.10TB (yes, TB) share, fully hashed, almost all small files.

Yes, 3.86MB is pretty much for a modem user.. but not very much on an adsl or cable connection.. certainly nothing for a T1 or similar. Besides, modem users can barely download anything anyway without a lot of patience, sad but true.

About your other problem.. DC++ uses something called MiniSlots that allows it to download files that are smaller than 20kb even if there are no actual slots available. You can't download bigger files than that through the minislots, which is why you eventually got the No Slots Available, because there weren't really any available to start with.

[Chris]

Well, I re-opened some file-lists i´ve got in my folder...
List-size 6.17 MB (18.8 MB uncompressed), 201871 files, 72.15 GB
List-size 4.33 MB (12.3 MB uncompressed), 142389 files, 203.46 GB

Just two lists, pretty different but both huuuge, although the share´s not particularly big.
I didn´t make that up; my current session´s file-list folder is about 70 MB.

I´m not a modem user, but high-speed upload connections still are rather rare. If you look for sth unusual, you might not even have a second user to download from, so 1-5 k/s really isn´t that unusual.

But as I said, if that´s the price, then so be it.

About the other thing, you sort of misunderstood me I guess.
The thing is, that DC++ changed WHILE downloading from a normal to a minislot. Isn´t it possible to just keep the slot, even if a minislot would do for some files??

[Todi]

My bad, his list was naturally full of similary named rar's, which would compress very well

Are you sure it switched from a normal slot to a minislot? How can you tell it didn't use a minislot from the beginning, because small files are set to high priority when they're queued.

[GargoyleMT]

It also takes away the ability to continue a file, by choosing a larger one after finding out, that the DL´ed one was incomplete. But that seems to be a minor issue to me.

I was doing this with 0.401 yesterday - trying to resume an incomplete AVI from sources I found in search. Hashing didn't prevent me from doing so.

Now to finally come to the point: Is it possible to implement a function (right-click or so), which allows you to decide whether to download the new Filelist-format including the hashes, or just the old one, which is a lot smaller?

Sooner or later, the .DcLst and .bz2 file lists will go away, and users will only have the rich XML lists to download. Once DC++ or mods start including meta-data like mp3 bitrates, video codec, lengths, I don't particularly think you'll want to go back to the other list format, even if it is smaller.

That just happened to me. OK, I quitted that Filelist download then, and put the file somewhere else, but that´s impossible if absent, and often users are only in a hub for less time than it takes to download their list.

I'm sorry, this paragraph escapes my comprehension.

[Chris]

Todi wrote:

Are you sure it switched from a normal slot to a minislot? How can you tell it didn't use a minislot from the beginning, because small files are set to high priority when they're queued.

Simple! I was on a 30 MB download while I added another folder to download from the user´s file-list.
Because of the priority, DC++ DL´ed, after finishing the 30 MBs, the small files immediately. After those were all fetched, the slot was gone.

GargoyleMT wrote:

I was doing this with 0.401 yesterday - trying to resume an incomplete AVI from sources I found in search. Hashing didn't prevent me from doing so.

Cool!!!

I'm sorry, this paragraph escapes my comprehension.

Doesn´t matter... Pretty confused...
...only meant, that I erased the file-list from my Queue and simply picked the 20 kB file directly.
I doubt that such bad connections could ever finish a 6 MB file-list download.