Anyone seen this before?

[pro267]

That's what happens when you reach MAXINT..

[TheFoX]

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.

[showbox]

cool

[fstokebanget]

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.

nice explanation

[eLucid]

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.

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.