First time i've seen this...
http://img297.imageshack.us/img297/3725/123pb6.jpg
Printable View
First time i've seen this...
http://img297.imageshack.us/img297/3725/123pb6.jpg
No never , now i can't wait to see -1 Seed
yes i have seen it few times but really rare,tracker problem i guess :)
How strange! :blink:
How cool, first time i've seen it. Normally the scripts over exaggerate the number of peers ie, 23285238532 but first time i've seen a negative value..
Anyone scriptor want to explain whats happening here?
ghost leecher ? :D
I think it's a SQL problem, but don't sure, i'v never seen this before...
Let's wait for an answer from a coder...
negative leech, sounds like a good emo song :P
well,seen it before ,looks like Trackers stealing content from you instead of you downloading :P
^^^ lol
tracker stealin content from u..>:P
...Waffles is stealing my music >< :O
I think tracker error.
Seen it before in RTS.Lousy coders.
that's a strange one, i use to see impossible number of peers in RevTT but never a negative value
lol
time to add a private tracker patch me thinks otherwise.....
lol, I see the same on another waffles torrent now ^^ 0 seeders -1 leecher(s?)
I thought it was strange having -1 invite but this might take the cake.
-1... lol... and this is even more odd :
http://img225.imageshack.us/img225/2076/picture2hw9.png
Lol well cmon Peter Juergens is amazing...why wouldnt every person in china want to download it this very minute.
^ lol
is that the same tracker?
and I think it may differs on every browser's view
its a coding bug for sure. probably the sites which have this problem are using a source code which causes it
it also happen to high lv tracker :D
http://img299.imageshack.us/img299/2766/picture2lh4.png
That's what happens when you reach MAXINT.. :lol:
and MAXINT is different depending on what setup you used for the peer table. If the number of peers is unsigned, MAXINT will be 4294967295, but if it is signed, then it appears as -1.
This bug is actually a product of the increment and decrement code within announce that adjusts the leecher and seeder values of the torrent being announced. More modern code will actually check the dynamic peers table, than rely on possibly flawed data.
cool :D
As far as I can tell, it's designed this way to be more efficient (although less accurate) because, for large trackers, having millions of queries checking the dynamic peers table would be a lot less efficient than just using the value stored in the torrents table.