[search] Filesize -> exact

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

Moderator: Moderators

Locked
Wisp
Posts: 218
Joined: 2003-04-01 10:58

[search] Filesize -> exact

Post by Wisp » 2003-07-14 11:10

When you search for a file, you can select "at least" and "at most" but can't there be an option "Exact" so i can better search for alternatives?

Example, i want to download terminator.avi (so part 1) but when i search for alternatives i get a huge list of "terminator 2.avi" because it has a bigger filesize

if the option "exact" would be implemented i could fix this

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-07-14 18:37

The problem is backwards compatibility... but some people have added this to their clients. Use the search button to find out whom that was (but it was a while back).

Sarf
---
Wonders never cease, as long as you never cease to wonder.

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2003-07-14 20:44

hmm i can't understand what this option has to do with being backwords compatibel.. :?

Twink
Posts: 436
Joined: 2003-03-31 23:31
Location: New Zealand

Post by Twink » 2003-07-15 03:03

isn't it the person being searched that removes files over/under the specified limit to reduce bw?, if you added an 'exact' search older clients (including nmdc) wouldn't support it

cyberal
Posts: 360
Joined: 2003-05-16 05:42

Post by cyberal » 2003-07-15 03:21

oDC has this feature, but it only resturns correct "exact size" answers from other oDC clients.. (ofcourse)
http://whyrar.omfg.se - Guide to RAR and DC behaviour!
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet

jbyrd
Posts: 255
Joined: 2003-05-10 09:26
Location: no-la-usa-earth
Contact:

Post by jbyrd » 2003-07-15 06:57

The obvious solution is to search using the "at most" option and sorting the results by size (most to least). Then, the exact sizes are at the top.

Easy enough for me :)

cyberal
Posts: 360
Joined: 2003-05-16 05:42

Post by cyberal » 2003-07-15 07:30

yeah, but that way is flawed... since dc++ don't return an endless amount of search results, the ones you want may not be incuded in the response. Could be any file smaller than the one you want..
http://whyrar.omfg.se - Guide to RAR and DC behaviour!
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet

jbyrd
Posts: 255
Joined: 2003-05-10 09:26
Location: no-la-usa-earth
Contact:

Post by jbyrd » 2003-07-15 07:42

Ok, so let's use common sense.

For a small file: Use the "at most" feature and sort by size (from most to least). The exact size will be at the top. There will be a small number of files below the size of your file since it's small.

For a large file: Use the "at least" feature and sort by size (from least to most). The exact size will be at the top. There will be a small number of files above the size of your file since it's big.

I'm not so sure that dc++ doesn't return every file. Sure, it may cut off some, but next time you're on, simply type a period (".") in the search box and see how many files you obtain. Quite a few. :wink:

TheParanoidOne
Forum Moderator
Posts: 1420
Joined: 2003-04-22 14:37

Post by TheParanoidOne » 2003-07-15 07:55

jbyrd wrote:Ok, so let's use common sense.
But then that brings up the issue of how do you define "large" and "small"?

There is also the issue of the feature and the user interface behaving inconsistently (as far as the en user is concerned).
The world is coming to an end. Please log off.

DC++ Guide | Words

cyberal
Posts: 360
Joined: 2003-05-16 05:42

Post by cyberal » 2003-07-15 08:41

jbyrd:
What I mean is that there are no reason that the files you want will be returned in the search, it will any any of the files that fill the criteria set.. hence you won't have any idea of how many that really have the file... I belive that dc++ only returns 5 results per user/hub.

An example.. a guy is sharing 25 .jpgs with "dance in the dark" in the filename and the one that you want is named "dark dance.jpg".. say you search for dance dark .jpg... you will probably get 5 of those 25 files and not the one you want.
http://whyrar.omfg.se - Guide to RAR and DC behaviour!
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet

jbyrd
Posts: 255
Joined: 2003-05-10 09:26
Location: no-la-usa-earth
Contact:

Post by jbyrd » 2003-07-15 10:46

Hmmm. I don't have dc++ in front of me at the moment, but it would be interesting to see if it returns the largest results first (from a single user) if "at most" is used or vice versa.

Anyway, it does raise a good point, but I have never had this problem.

And I never have to search for alternates on .jpegs. :)

Opera
Programmer
Posts: 15
Joined: 2003-02-21 13:45

Post by Opera » 2003-07-15 16:37

i search with the "normal" size type, But specify a size, and equalize that with "exact size", and it works perfectly. it is backward compatible, even though you'll get "wrong" sizes as well, from those clients not "understanding" this.
it would lower the pressure on hubs drastically due to all the autosearches if more clients would implement this.
it's easily done, and a great feature.
yes, it's a hack, but who cares.

O
Creator of the dc++ fork, oDC found at:
http://gempond.com/odc

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

Post by GargoyleMT » 2003-07-19 14:45

Wisp wrote:hmm i can't understand what this option has to do with being backwords compatibel.[sic]
Because it has to do with the protocol, Wisp.

The $Search command is only set up in such a way that "less than" or "more than" searches are expected.

Opera's worked his way around that, of course.
Opera wrote:it would lower the pressure on hubs drastically due to all the autosearches if more clients would implement this.
it's easily done, and a great feature.
yes, it's a hack, but who cares.
Well, to be fair, the savings for the hub come not in the autosearches (for neither quantity nor timing are changed with this), but the quantity of $SR results that users send over the hub to answer passive search requests... Unless I'm missing something? It's worth doing, probably, but the above overstates the benefit a bit (every bit helps in large hubs, though).

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2003-07-20 13:41

GargoyleMT wrote:
Wisp wrote:hmm i can't understand what this option has to do with being backwords compatibel.[sic]
Because it has to do with the protocol, Wisp.

The $Search command is only set up in such a way that "less than" or "more than" searches are expected.
Well let's say I'm searching for a file of 1000 bytes

first DC can search for the file smaller than 1001 bytes, and then search again for the file bigger than 999 bytes..

filter out the matches who were returned during both searches and you're done

not the most elegant way but who cares

TheParanoidOne
Forum Moderator
Posts: 1420
Joined: 2003-04-22 14:37

Post by TheParanoidOne » 2003-07-20 13:49

Wisp wrote:not the most elegant way but who cares
You've just doubled the amount of bandwidth used. I'm thinking *someone* will care.
The world is coming to an end. Please log off.

DC++ Guide | Words

cyberal
Posts: 360
Joined: 2003-05-16 05:42

Post by cyberal » 2003-07-20 14:16

TheParanoidOne wrote:You've just doubled the amount of bandwidth used. I'm thinking *someone* will care.
No, wrong.. not if the client that resturn the results do that filtering, will take a tiny bit of cpu ofcourse.. but thats better than all that bandwidth!
http://whyrar.omfg.se - Guide to RAR and DC behaviour!
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet

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

Post by GargoyleMT » 2003-07-21 10:44

Wisp wrote:filter out the matches who were returned during both searches and you're done
Ugh, or you could have DC++ search for files at least 999bytes, and filter out the ones that are not 1000 byes long. Jesus, no need to search twice.

In case you haven't picked up on this clue: the programmers here care about the elegance of a solution.

Twink
Posts: 436
Joined: 2003-03-31 23:31
Location: New Zealand

Post by Twink » 2003-07-22 20:32

yeah I agree with Gargoyle, no reason to do two searches, not only would that not be elegant but it would waste alot of bw, obviously the best solution would filter out the smaller and bigger files at the remote computers however as said earlier this would be a compatibility problem. So a simple algorithm that picks smaller or bigger search (depending on the file size) and filters out at the clients end results that aren't equal. Seems like the best solution possible without breaking older clients.

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

Post by GargoyleMT » 2003-07-23 15:54

DC++ blindly trusts remote search results - if anyone ever starts spamming wrong search results - as happens in other networks, DC++ will need to implement this feature anyhow.

Locked