[BUG] back from eMule
Posted: 02 Dec 2009 04:57I moved back to using Shareaza and noticed some minor things...
1. Importing eMule partials works great in theory, not so well in practice.
The basic problem is that while the file merge method used is pretty much foolproof and works great when it works, it fails without any feedback when no hashset is retrieved. It took me several minutes to figure out why only one of my downloads was imported correctly. An actual new user who had never used "assume complete" or "merge" would IMHO been lost. The merge needs to be modified so it does "assume complete and verify" after Shareaza gets hashset. So instead of failing silently or telling that a hashset is required, it would notify that the operation will be complete after a hashset is acquired. As it is I am stuck waiting for hashset, so I can then manually merge with the eMule partials. While the import is probably pretty rare operation, the flaw here is in the merge logic which is used quite a lot in troubleshooting, so this would be worth fixing.
2. Global search works, but didn't.
The problem is that while there are enough good servers, by default Shareaza will be overwhelmed by bad ones unless you only use a static list, which makes you vulnerable to server changes hiding large parts of the network. The problem went away once I enabled learning new servers and started adding bad server addresses to the security list manually. I think Shareaza should be more aggressive about the global search so it doesn't get stuck on the fakes not responding. Also enabling learning and using a block list seems to work better than using a static list, but I am not sure if there is a good way to implement an updatable blocklist that would cover bad servers. I guess it would require updating the security manager.
3. Adding a torrent still needs work...
I started downloading a torrent of a file I was download from ed2k. This failed because while Shareaza recognized I was already downloading the same file and rejected (correctly) starting a new download, it did not use the tracker data in the torrent. So I was was stuck with "already downloading a torrent" that was not really working as a torrent. I canceled the old download, started the torrent, and merged the old partial to it. (I really love this merge feature...) But this shouldn't be necessary. Shareaza should just add the the torrent info to the download when it actually recognizes it as the same file. In general while Shareaza supports downloads having all possible data, it seems to set the type of the download at the beginning and refuse to add info belonging to another type. Something to do with the way Shareaza links to the torrent info maybe?
1. Importing eMule partials works great in theory, not so well in practice.
The basic problem is that while the file merge method used is pretty much foolproof and works great when it works, it fails without any feedback when no hashset is retrieved. It took me several minutes to figure out why only one of my downloads was imported correctly. An actual new user who had never used "assume complete" or "merge" would IMHO been lost. The merge needs to be modified so it does "assume complete and verify" after Shareaza gets hashset. So instead of failing silently or telling that a hashset is required, it would notify that the operation will be complete after a hashset is acquired. As it is I am stuck waiting for hashset, so I can then manually merge with the eMule partials. While the import is probably pretty rare operation, the flaw here is in the merge logic which is used quite a lot in troubleshooting, so this would be worth fixing.
2. Global search works, but didn't.
The problem is that while there are enough good servers, by default Shareaza will be overwhelmed by bad ones unless you only use a static list, which makes you vulnerable to server changes hiding large parts of the network. The problem went away once I enabled learning new servers and started adding bad server addresses to the security list manually. I think Shareaza should be more aggressive about the global search so it doesn't get stuck on the fakes not responding. Also enabling learning and using a block list seems to work better than using a static list, but I am not sure if there is a good way to implement an updatable blocklist that would cover bad servers. I guess it would require updating the security manager.
3. Adding a torrent still needs work...
I started downloading a torrent of a file I was download from ed2k. This failed because while Shareaza recognized I was already downloading the same file and rejected (correctly) starting a new download, it did not use the tracker data in the torrent. So I was was stuck with "already downloading a torrent" that was not really working as a torrent. I canceled the old download, started the torrent, and merged the old partial to it. (I really love this merge feature...) But this shouldn't be necessary. Shareaza should just add the the torrent info to the download when it actually recognizes it as the same file. In general while Shareaza supports downloads having all possible data, it seems to set the type of the download at the beginning and refuse to add info belonging to another type. Something to do with the way Shareaza links to the torrent info maybe?
Please reply if this help.