[search] Filesize -> exact
Moderator: Moderators
[search] Filesize -> exact
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
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
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
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
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
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
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.
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.
-
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 14:37
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.
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
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
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.
Anyway, it does raise a good point, but I have never had this problem.
And I never have to search for alternates on .jpegs.
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
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
http://gempond.com/odc
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Because it has to do with the protocol, Wisp.Wisp wrote:hmm i can't understand what this option has to do with being backwords compatibel.[sic]
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.
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).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 let's say I'm searching for a file of 1000 bytesGargoyleMT wrote:Because it has to do with the protocol, Wisp.Wisp wrote:hmm i can't understand what this option has to do with being backwords compatibel.[sic]
The $Search command is only set up in such a way that "less than" or "more than" searches are expected.
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
-
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 14:37
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!TheParanoidOne wrote:You've just doubled the amount of bandwidth used. I'm thinking *someone* will care.
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
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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.Wisp wrote:filter out the matches who were returned during both searches and you're done
In case you haven't picked up on this clue: the programmers here care about the elegance of a solution.
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.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us