Shareaza

I'm running into a problem lately where certain files seem to be being corrupted in transit consistently. By "corrupted in transit", I mean BOTH that the received file has a different hash from the source's hash (notably, the downloaded file doesn't disappear from the search results with "files you have already" filtered, nor does re-downloading it prompt that you have the file already in your library, nor does it turn green, nor does it turn brown if the downloaded file is subsequently deleted) AND that the received file will not play back successfully (it's totally unusable).

This seems to be happening under very specific (and somewhat peculiar) circumstances:

a) The download is via ED2K protocol.
b) The source has lowID.
c) The file name begins with the string "__ARESTRA__".

It's that last bit that's peculiar. I could see a protocol implementation bug being specific to one protocol, and I could see it being specific to push sources (or to non-push sources), but why would it be allergic to a specific filename pattern?

The files themselves are fairly diverse. I've found "ARESTRA" files matching several unrelated searches. All have the problem that they cannot be downloaded intact from ED2K lowID sources using Shareaza -- the received file will not be bit-identical to the source's copy and will not operate. Every single time. It seems to be the filename itself, not the specific source or the specific subject matter (original file's contents), that sets this problem off. Indeed, I've sometimes seen what are presumably near-identical files (same name with minor variations like spaces->underscores or whatever and releaser prefixes/suffixes added/changed/removed, and presumably the same content with slight encoding quality differences, with similar file sizes) that downloaded intact; what makes the difference is not understores, hyphens, the actual subject matter, the actual content, or anything else, just whether or not the name starts with "__ARESTRA__".

And I think I've had "ARESTRA" files download intact from non-ED2K sources in the past (sometimes with minor pre-existing corruption, but none in transit, i.e. the downloaded file matched the source's shared file and the search result disappeared or turned green, etc.)

So: Why does the combo of that filename pattern, ED2K, and a lowID source consistently result in the file being garbled over the wire? I'll emphasize that these days I pretty much never see a file arrive not bit-identical to the source's copy except in this one specific pattern of circumstances. The use of hashes to verify and redownload (parts of) files on every network has made "garbled over the wire" a phenomenon almost never seen any more in a completed file. Except, somehow, for "ARESTRA" files from lowID ED2K sources.

Look at this topic: Some suggestions.

Nothing on that page says anything about files consistently coming through non-bit-identical to the file on the source, thus failing to verify and winding up unusable.

__ARESTRA__ is a prefix for incomplete downloads of Ares.

Because it is incomplete file, temporary file, still downloading file.

Too many words, understand nothing. Anyway Shareaza will ignore any file beginning with "__ARESTRA__" in its Library.

cyco, help
ailurophobe, too. (complecate name, rare seen)
Lanigiro seems to be a really interrested user, like me. When starting.
Maybe he can get some more overview of the project.
Too many words in english, too less in german and too less in russia.
OD: Can you bring up this to german forum ?

It's an implementation issue. I guess ignoring a file in the library alltogether was more easy than implementing the feature differently...

That is true. Note however that in an open source project like this one people use their free time to advance the project. And that fact tends to limit the total development time available, so the way things are done is often determined by finding a balance between advancement and how things are done. If we were a company, Shareaza would have been rewritten from scratch at least once until now to get rid of certain flaws in the core structure that hinder us continuously but are too complicated to fix easily... This in one of the reasons we are currently working on Quazaa - but for obvious reasons, development on Quazaa is slow going.

See this for the development history: http://sourceforge.net/p/quazaa/gitcode/commit_browser

As long as the code is not in beta stage, we won't do much work on the website. Because what is a nice website good for if the product it advertises is not even finished yet?
If you were willing to help out* however, that would be greatly appreciated.

*) Doesn't have to be the website, we also need people helping with the development and lots of other stuff...