Shareaza

Ryo,
what you committed in r9401 fails if there are 2 hashes of the same type in a magnet. If you have for instance "magnet:xt.1=sha1:<a>&xt.2=sha1:<b>" where <a> and <b> are some sha1 hashes, then your code will first extract <a> and then overwrite it in the second iteration with <b>. So at the end, the loop only extracts <b> from that magnet. In order to extract all of them, you probably need to use a list or map to store the files you extract.

PS.: Thanks for making me reread the Quazaa Magnet code, a bug was hiding there, too.

It's impossible, only one of kind must exist in URI i.e. "magnet:xt.1=sha1:<a>&xt.2=md5:<b>"

No. A magnet link with these numbers specifies multiple files. If each file has an sha1, then there are n sha1 hashes for n files in a magnet link - all of them with a different number, of course. It is true that there may not be multiple sha1 hashes for the same file, though.

You are right but it's a bit confusing since "tr.x" just defines several trackers for one file...

But I added "tr.*" to Shareaza after I found several torrents with one hash and many "tr.*" keys...

Well, that's just erroneous decoding. Maybe we could support those as a kind of error compatibility with a message box warning the user about the encoding error?

It's easy, just count how many hashes in the magnet and if only one so all trackers goes to the single torrent.

Yes, that's probably the best thing we can do to stay compatible with all possible variants... Too bad there is no real spec for the magnet link tracker extension.

As far as I can see you are basically ignoring the numbered part for trackers but not for anything else. So I guess it's fine concerning that part. What still needs to be done however is to make sure to extract the parts you are currently missing (all parts where nNumber != the first occurrence of nNumber, e.g. all but the first file in a multi file magnet).