Downloads.NeverDrop does not function as advertised.

[grey-hame]

Downloads.NeverDrop does not function as advertised.

I still have a file that goes from 1 source to no sources spontaneously within a minute or so of re-adding the one known source.

[ocexyz]

Perhaps this source is just unstable. A hub remeber it but when checks it is unaviable, so reflects it in "no source". Perhaps there is no source for this ay all, just disappeared. Or perhaps source is in defferent time zone and on one single machine of a person, so you would have to leave Shareaza working 24/24 for a time to catch when it is on line. Or perhaps it is on line only on weekends etc.etc. This is problem of rare files. I remeber I have such a file and it has been downloaded after 2 years on "no source" - but I really wanted it so I was waiting. I think this is about source aviability in net not about Shareaza. Sorry.

[grey-hame]

[ocexyz]

[sshanu]

If a source returns a 404 on a file request it will be dropped if .never drop is true.
If a source sends corrupt data same will happen if .never drop is true.
See both those in the System window.
If you right click & "forget" a source Raza won't re-add that source, just ignores it from then on, not sure how to reverse that one.

[grey-hame]

In other words, it's really "sometimes drop" rather than "never drop"?

How do you force it to keep trying no matter what?

[ocexyz]

[sshanu]

I guess you could call it "sometimes drop", it never drops the majority of sources when enabled, only the ones that would be useless anyway.
Manually is the only way force it to keep trying I think.

"Download host xx.xx.xx.xx responded with 404 file not found" I usually see in the System window if a source is dropped with .neverdrop true.
Or "Dropping source xx.x.xx.x for sending corrupt data" or similar to that when the hash check for that chunk fails.

Only time I've seen it refuse to add a source is when that source IP is in the security filter.

[grey-hame]

[ocexyz]

[sshanu]

404 can also be seen when a source removes a file from being shared.
File shows up in search hits, removed in the meantime, 404 returned when the file is requested.
I think it's also returned when Shareaza requests a chunk of an incomplete download from a source that's not sharing partials.

[grey-hame]

[grey-hame]

Manually readding the source for one of the two affected files eventually worked -- I downloaded it late last night.

This proves that whatever was causing Shareaza to give up on that source, it should have kept trying automatically, and therefore that Downloads.NeverDrop should have caused it not to drop the source for that file.

No doubt the other will eventually download too, but it would be faster if I could have Shareaza keep trying automatically; as it is, I have to re-add the source every few minutes, and obviously I can only do that during part of each day, and while I'm not doing that there is zero chance of it downloading the file (unless another source turns up, which seems unlikely).

[ocexyz]

I think this can be true. If Shareaza treat 404 as "forever status", this should be repeated in a time IMHO. 2, 5, 9, 15, 24 hours/minutes?

[ailurophobe]

Actually, if it is a push source, and the push request fails, just trying it again is extremely unlikely to work. Basically even if the source is still valid the route for sending the push request probably is not and trying again will never make it valid again. You must get a new route for the source by finding it again with a new and completely different path. So push sources that fail should be dropped since they can't be useful without a new search anyway.