Shareaza

Lately ED2K servers have started responding to search with the ever so helpful: "Your client is too old. Please upgrade to last version !" Anybody have an idea of what they want? Suggestions to the reason they don't give a message that is actually useful would also be welcome. Honestly I don't need the search enough for it to be a big deal, but it would be nice to know what feature they consider to be so important, so it could be at least added to the tracker as a feature request...

This message used to be to do with shareaza's lack of ED2k large file support. I did not think the latest builds had this problem though.

Well, there is a "LargeFileSupport" and it is set to true by default, so it should not be that anymore. It might be a problem with my install though, can anyone confirm seeing this if they do a keyword search over ED2K? Some servers do seem to still work, so you might not see this everytime.

BTW and totally unrelated: crashing ASSERT( strXML.GetLength() == int( _tcslen(strXML) ) ) from CXMLElement::ToString line 431 in XML.cpp seems to be coming from nGroup += G2_PACKET_LEN( G2_PACKET_METADATA, pPacket->GetStringLen( strMetadata ) ) in line 544 of localsearch.cpp. Somehow related to G2 metadata? Doesn't happen if G2 disabled anyway. I am now trying if disabling metadata sharing makes it go away.

Did not help. Come to think of it, it was actually trying to add a G2 hit to the file metadata. Nothing to do with sharing metadata at all. So no G2 for me at the moment. Since nobody else is reporting this, it is probably caused by the file metadata being corrupted for some file(s) on my system. Anybody know where the hits are stored? In the hidden metadata folders? If so, I could just delete them all to fix this. But why wouldn't ed2k hits cause a crash?

You might want to report the issue to Ryo...

What I would want to do would be to find out if anyone else is seeing either of these. I actually have some hardware problems which could be causing weird problems in my system without there being anything wrong in the code that Ryo could fix.

Are you using the latest build? I'm using Build r8662 and have had no trouble. Although I am using the x64 r8662 release build so I may not be getting debug asserts. (I could not get a message about my client being out of date from ED2K servers either.)

Thank you very much. The server message is then probably caused by my client being black listed which could reasonably be a result of hardware problems I am having. Wish they'd give a more useful message, but these people ARE bit paranoid about bad guys trying to sabotage them by sending bad packets... If so I'll have it fixed by the end of the week.

The debug assert... If nobody else is seeing it, it probably IS file corruption. Anybody know where G2 hits are stored?

EDIT: Yup, that was it, thanks once again loopyloo. Now, if anyone could give a hint on the G2 hit problem?

Actually it was not caused by the hardware problem. Seems that for some reason uploading partials was not working and after some delay the server assumes my client is too old to force sharing partials. Will take some time to make sure, but at least with this theory the error server returns makes sense. What would happen was that the upload would queue as #1 on the "ED2K partial" queue and then almost instantly "time out waiting for queue update." I deleted the partial queue and made "ED2K core" share both complete and partial files and it started working just fine. Very odd.

It did not start working fine. It still would not actually upload. The length of the ED2K queue just meant that they got queued properly before trying to upload and failing. It took several hours before uploads progressed to where I started noticing something odd...

Anyway, this time I actually took the time to fix it properly. (Well, I still have no idea why it didn't work but...) I am on win 7 and by default Shareaza uses users/???/appData/local/Shareaza/incomplete. For unknown reason this did not work so I changed the temp folder to something else and partials started uploading. No idea what the problem was. The appData folder has odd permissions, is hidden, and aliased and is in general weird... To be honest I already hated appData because the totally unnecessary trouble I had copying my Firefox and Thunderbird profiles due to it being hidden and this experience did not really help.

Does anyone know if this was particular to my system or is there a general compatibility problem with Win7?

Well, in my case the problem was with the default folder and changed folder worked fine. (Still working, btw...) So you might want to modify that request a bit. Also unless it was something specific to my system, it would be a Win7 compatibility bug instead of enhancement.

I'm using win7 with UAC turned off. Shareaza works fine under these conditions. So sounds like it is a permissions problem.

Maybe we should add a folder to the user's own files folder, which we then could call "Shareaza". Inside, we can add folders called "Shareaza Downloads", "Application Data" and "Incompletes". This will make clean installs and similar operations very easy.

I just Reverted to the shareaza default upload queues and observed shareaza failing to upload partial files to emule clients. I was using modified queues before this. It seemed to be only emule clients it was failing to upload to, MLdonkey and other clients seemed to maintain upload connections. The emule clients would start to upload then disconnect. So perhapse there is something else going on than a permission problem. I need to test this more.

I also saw some random behaviour while fiddling with the queues. Unfortunately I didn't really pay attention, but IIRC making the queue too short made it not work properly. Also for a while the queue became "invisible"; the clients were shown while connecting, but were invisible while waiting or downloading. Everything was actually working, it just wasn't visible in transfers tab. (But you could see the operations in the network tab.) Restarting Shareaza made everything visible again.

Could you plz fill in a bug report?

What queue I use doesn't seem to matter. Emule still does not upload. I just did not notice before.

I am currently uploading partials to several eMule clients. I think the "starts to upload" is probably the "queue up" connection. That is, eMule connects, tries to queue up, and fails/drops. That would be pretty much what I saw while trying to make my partial uploads work. I really should have paid more attention to how I got it to work... I think I just made the queue 1000 entries long, but I am not sure how it could apply here.

Shareaza still fails to upload to the emule client after changing queue lengths and changing the default incomplete folder to a different folder in my personal user folders. (C:\Users\(username)\Documents\Shareaza\Incomplete).

It will however upload to MLdonkey,eplus,shareaza,etc using the ED2K protocol.

I am getting the "your client is out of date" message from some eDonkey servers.btw.

Yes, as I just found out that is what the servers will tell you if you have problems uploading partials. Dammit, this totally looks like what I run into... My theory was that the newer eMules have some anti-leech protection that doesn't connect if the queue is too short or does not have enough bandwidth. (eMule doesn't understand multiple queues.)

EDIT: My working queue has 1000 waiting slots, 128 kbps bandwidth and 10 max transfers.

I saw the "starts upload and drops after few seconds" as well. Installed a newer beta and this happened. Downgrading back to an older beta made everything work again... Didn't seem sensitive to what the upload client was or which ED2K queue it was, so probably a different issue than with loopyloo.

The problem is fixed in the latest build r8693. Shareaza now uploads to ED2K.

However there is still a message in the system log that my client is too old. It could be because I have less than 10KB/s allocated to ED2K uploads maybe?

It does seem to be related to upload capability, yes. If you are short on bandwidth, you might want to make a combined queue for shared and partial files. That might help.

Yeah..Already doing that. Trouble is I have such a low upload rate that there is not much I can do about going under ED2K's 10kbs penalty limit without making HTTP uploads suffer. Still it's good to see ED2K able to upload again. Thanks Wildcard.