Problem with single torrent - tracker status: "HTTP error 404"

[zgsezsad]

After downloading some files using a certain private tracker I continued to seed them. Everything was O.K. until I upgraded (from version 2.1.1) to uTorrent 3.0 (build 25460). After the upgrade I continued to seed those files, and all of them work except one.

I am having problem with a single torrent: I am getting "HTTP error 404" under tracker status. Tracker status under other torrents using the same tracker is "working".

I checked with the private tracker's admin, and he confirmed my settings (including the tracker URL) are 100% correct. I tried removing the torrent from the list and adding it again. Updating tracker doesn't help. Restarted uTorrent, my modem and computer (all several times) - but problem remains.

I found an old version of uTorrent 1.8.5 (build 17414), tried it, and everything works - so it must be a problem with the latest uTorrent version!?

Any ideas how to resolve this? Thanks in advance!

[DreadWingKnight]

What internet security software do you have installed?

What proxy settings are you using?

Also, 1.8.5 isn't supported any more (hasn't been for months now).

[zgsezsad]

Quick Heal Internet Security 12.00 SP1. I am not using a proxy.

I am not asking for support for version 1.8.5. The problem appears ONLY when I use 3.0. Version 2.2.1 worked O.K. Version 1.8.5 (for testing & comparison purposes) works O.K.

The problem seems to be just when I use uTorrent 3.0.

[DreadWingKnight]

It honestly sounds like quick heal is interfering with the request in some way, assuming there's nothing else injecting itself in the http calls.

[zgsezsad]

I disabled Quick Heal, but the problem persists. What puzzles me:

1. Why does the problem appear only with a single torrent, while other torrents from the same tracker work fine?

2. Why does the problem appear only when using uTorrent 3.0, while other versions work fine?

I would appreciate any meaningful input! Thanks in advance.

[Firon]

There is very likely something wrong with the tracker itself, as it's the one that is most likely returning the 404. You may want to consult the staff of that tracker for help.

[zgsezsad]

I did suspect the tracker myself. But tracker administrator has investigated the problem and assures me that nothing is wrong with the tracker.

[zgsezsad]

After further investigation the tracker administrators have discovered that the problem appears regularly when using uTorrent 3.0, but only when using that version of uTorrent. Other clients and uTorrent versions work fine. So, there is a bug in uTorrent 3.0 that causes the problem mentioned in my original post.

As uTorrent is closed source, the only way to eliminate the bug would be for someone from the development team to look into it. Would anyone be willing to do it? Thanks in advance!

[hwkns]

Hi folks, thought I might chime in as staff from another private tracker.

This is definitely a bug in uTorrent 3.0, and it has not been fixed yet, as of 3.1.3b27207. We replicated the issue several times over with uTorrent 3.0+, and were unable to replicate it using other clients. We also restarted the tracker, and observed no change in the situation.

It's simply ridiculous to suspect the tracker is giving a 404 error when several other torrents with the exact same announce URL are working perfectly across multiple announces. If that's the kind of conclusion you reach when seriously considering this issue, it's a miracle any of your code works at all.

[Firon]

We've tested uT with a huge number of trackers across the world and had no problems. The fact that only your tracker gives a 404 makes it much more likely that it is not our bug.

Furthermore, the webservers people use (apache, lighttpd, nginx, and even the nightmare that is IIS) behave correctly with HTTP traffic from our client. It also works correctly with opentracker, which is the most popular open-source tracker at the moment.

The last time there was such an issue (though it was only for HTTPS), it turned out to be a bug in lighttpd.

Capture some wireshark dumps of the traffic and show us what's wrong. The best way to do it is to capture an announce from one client that works and one that doesn't and post the dumps here.

We'll be more than happy to fix it if it's our bug.

[hwkns]

The fact that only your tracker gives a 404 makes it much more likely that it is not our bug.

Where are you getting these ridiculous assumptions? I have no idea what tracker zgsezsad was using when he posted this issue, but it wasn't ours (we have no record of users contacting us about this bug before this week).

We've tested uT with a huge number of trackers across the world and had no problems

The issue is obviously a rare occurrence, and it exists in one torrent among many that are interfacing with the same tracker, so the impressive range of trackers across which you've tested uT is irrelevant in this context. We are not disputing the idea that uT works properly with some subset of the possible torrent files in the universe, and I am confident you did not test all possible torrents.

Logic would suggest that something about the afflicted torrent is not playing nicely with uTorrent:

1. The same torrent on multiple uTorrent clients produces the same error.

2. The same torrent on multiple non-uTorrent clients works perfectly fine.

3. Different torrents on the same uTorrent client with the same announce URL work perfectly fine.

I will see if we can get some wireshark dumps to compare, but seriously, take a minute to think about this. This is not a tracker problem.