Tracker Announcer Bad URL..

[coyote]

Hey guys, thought I'd ask, in case I have some mis-selected settings causing this, and googling the error doesn't seem to report anyone else having had this issue -

Symptoms: Some private torrents start out at high speed, but as time progresses, they slow to a crawl. Closing Vuze out completely, and re-running Vize will fire the torrent off at high-speed again. This does not happen with ALL private torrents, only some - and some from the same tracker work fine (i.e. Don't produce the following error..)

What seems to be happening is that something is overwriting the tracker URL after the first contact, so that all subsequent attempts at contacting fail. So the torrent gets a list of peers on the first request, but then never do again - as peers given in the first contact drop off, Vuze can't get more, and so the Peer pool drops considerably.

Here are the messages from the Console (trimmed out a lot of extra, unrelated lines..)

Code:

[18:10:24.725] {tracker} Tracker Announcer [http://announce.torrentday.com:60000/<hash>/announce] has received : d8:completei54e10:incompletei6e8:intervali1800e12:min intervali1800e5:peers288:[e0� ULj“Y�¢Û³}5NP²·û¸KÔ‚ÈÕm”'Ùs¡D5|€•²®Ò¢z"OˆRÔ¦¢Û³z5N^„ëù0È{óÞî°%l;hîŒ @8“%¿Ê2f§þ‰ÃáV“[…ù6K¹ìÕ�}¸@D¿f ÙzmHGQböUkúÓcïá^òÞ%ÆLpÈ.<ÊV·$ªâ
NcÏ¢©V›D^8ÜWû1/È�DÊæØ¥{óúÙ¸ÑR,v÷\ V†yóUlyßZ    öë6™á<­­NÆÔÂP½=áWBj C“V‘÷ó5BÜ¢%R.5“ß÷ËÛùRóÑR"�âÜž¢Û°*ÈÕC¤.ɆÚQ¦•­sðB[ñøÖ­ZÉ�í ­n¯ŸÀïe;     | Torrent: '...'
[18:10:26.921] {tracker} Tracker Announcer is Requesting: http:?info_hash=<hash>&peer_id=-AZ5301-hW8L09feN6Fk&requirecrypto=1&port=12365&azudp=12365&uploaded=0&downloaded=9&left=3229614080&corrupt=0&event=started&numwant=30&no_peer_id=1&compact=1&key=9N5RoL7D&azver=3;     | Torrent: '...'
[18:10:26.921] {stderr} DEBUG::Sun Jul 13 18:10:26 EDT 2014::org.gudy.azureus2.pluginsimpl.local.clientid.ClientIDManagerImpl::generateHTTPProperties::354:
[18:10:26.928] {stderr}   java.net.MalformedURLException: no protocol: 127.0.0.1:52770http:?cid=:80&info_hash=<hash>&peer_id=...&requirecrypto=1&port=12365&azudp=12365&uploaded=0&downloaded=9&left=3229614080&corrupt=0&event=started&numwant=30&no_peer_id=1&compact=1&key=9N5RoL7D&azver=3
[18:10:26.928] {stderr}     at java.net.URL.<init>;(Unknown Source)
[18:10:26.928] {stderr}     at java.net.URL.<init>;(Unknown Source)
[18:10:26.928] {stderr}     at java.net.URL.<init>;(Unknown Source)
[18:10:26.928] {stderr}     at org.gudy.azureus2.pluginsimpl.local.clientid.ClientIDManagerImpl.generateHTTPProperties(ClientIDManagerImpl.java:350)

Notice that on the first line, we get a whole b unch of garbage back, which the Tracker Announcer (?) changes the tracker's URL, and then tries to access some heavily-malformed URL (which doesn't work, of course..).

Any thoughts? Is the tracker returning bad information, or do I have a combination of settings on my side causing the tracker URL to get changed up? (And, if the latter is the case, I would recommend adding a check in the code - something like, 'Hey, if the URL's changed, and it causes an error 2 times in a row, revert back to the initial tracker..'. But admittedly, I am NOT familiar with tracker replies/responces, so I'm just suggesting out my bum here.)

Thanks in advance!
--Mike

[parg]

The 'garbage' in the initial response is just encoded peer data, don't worry about that. For the URL to be changed the tracker would need to return a 301/302 response with a new location, this is pretty rate. Are you sure that the torrent doesn't have multiple trackers defined and that one of them is a borked URL? You can see the trackers when you add the download in the 'torrent options' dialog (under the last section)

[coyote]

Interesting - I hadn't thought to check that, so I did.

Here's what I found -
On a torrent that was exhibiting the issue, I see what's in the first image. (Sorry, I'm an idiot, I see how to attach, but not how to place inline..) So, yes, there's an empty tracker there, d'oh!
So, I decide that the smart thing would be to remove this tracker entry, since it's not doing anything. Right-click on it, select to remove, and THEN I get what's in the second image - removing the null one removed BOTH of the trackers.
So, here's the kicker - on anoter, seperate torrent that was showing the same symptoms (it matched the 'two_trackers' image), I did NOT remove it, but stopped and restarted Vuze. Once Vuze was restarted, the torrent was back down to ONE entry, see the third image.

Also, I get the feeling - but I could be wrong, I haven't done extensive testing yet - that if a torrent is stopped upon Vize startup, and then later started (right-click -> Queue), it does not show this odd behavior. I say this because back when I first dug into the issue, I had a couple torrents that would repeatedly show this behavior - stopping and starting Vuze - every time. Tonight, however, I had a few torrents that I stopped, and had planned to start manually to catch the console logs better, and every one stated up fine, and now don't show the issue.

Strange..!

Thanks!
-Mike

 

 

 

[parg]

Very weird :( I assume you haven't been playing with tracker-templates and auto-applying them via tags?

Perhaps you could send me a torrent that exhibits the issue if/when it happens again? email it to paul@vuze.com - thanks!

[Lewisboss]

I am new to the forum may I join the discussion

[coyote]

Very weird :( I assume you haven't been playing with tracker-templates and auto-applying them via tags?

Perhaps you could send me a torrent that exhibits the issue if/when it happens again? email it to paul@vuze.com - thanks!

 

Hey -
Sorry for the delay in getting back to you. ("Real Life" has been keeping me far too busy..) Email will come shortly!

Oh, and no - I use a tag to simply mark whether I had processed the finished torrent - no tracker-templates are even in use. (And with the one I'm going to send you, it's happened both while leeching and seeding.)

Cheers -
Mike