Using latest svn, I get : Invalid data from tracker in the tracker status field. This happens when using any torrent from oink.me.uk. Tested the same torrent with azureus and working fine. I can't tell you the exact date it started doint this, but i'm pretty sure it's a change done this week or the previous. If you want me to send you a torrent from the tracker or an invite to the tracker, I will do so.

Btw, thanks for the awesome client, I like it so much that im building it at almost every svn commit .

If you could get us an invite, then we could check this out. But wait, maybe Ivan has on, because we had dealings with Oink before, I will ask him.

I know somone (who might be me) who can use r598957 on Oink, so i suspect they removed the exception for header in HTTP which got patched last 25 Oct?

Scratch that, the latest version gives me the same problem. I guess they have a hard exeption for KTorrent which needs loosing for 2.1dev?

EDIT
Just tested, r598819 works fine, r599103 is problem

Ok, if you need an invite, just give me the email you want me to send it. Thanks for the quick replys .

I've talked to OiNK admins and it seems that this is some kind of their server issue. They are working on it and hopefully it'll be fixed soon.

Well, I still have this problem and really I don't understand how this could be something from oink, because it started with a version from svn this week, but I will be patient and wait and use 2.0.3 until it's fixed, thank you .

Well, if you want it described, some trackers complain if our HTTP request has anything other than 'text/plain' for accepted mimetype. We've recently changed this and it works good on almost every tracker except OiNK. Their admins are checking out why their server won't allow our request seeing that they do send 'text/plain' only, and this is correct behavior from our side. Somehow, they don't have any luck yet.

BTW, if there are any Apache gurus we/they could need a bit of a help.

Ok the OiNK admins informed me that this issue is now solved. I haven't tested it yet (I'll report here what happens) but I believe them. It was indeed an Apache issue.

Working fine for me =)

Indeed, they fixed it.