Stats problem

[nos_slived]

Does the tracker use the TB source? If so, it's their problem, not yours.

[jait]

the tracker in question does NOT use tbsource... even if it did, (and it does in another tracker i have) we have had 0 problems with every other client in the WORLD except ur 1.7.x branch so cut the bs if u will plz... I code for another client myself and have had 0 such issues... suprisingly, uve had 3 so far in 3 versions u rolled out... funny how 1.6.x behaved perfectly at least in the trackers eyes and ur 1.7 had numerous bugs (including this one as well as others)...

we use a c++ based tracker and there are no bugs in recording statistics as if u knew any better, ud know that the implementation of recording stats is extremely simple on the tracker level and only a retard could screw that up... and if there were (in both our c++ based tracker and tbsource) dont u think that all clients would manifest the same issue? use some common logic if u will plz be4 respoding to ppl which lack the techincal skills to give u a more thorough expelanation and even remotely understand the issue... I have provided to rebecca her entire announce log (which is basically everything ur client sent to our tracker along with the exact announce strings)... how could it remotely even be something related to the tracker? can u plz explain that to me.. u probably cant becaue it doesnt make any logical sense

I have full announce logs of exactly what ur 'perfect' utorrent sent to my tracker and it had no resemblence to what utorrent reported (and what was actually sent by the client data wise to the other peers), at least according to rebecca and i have no reason to believe she would lie about a torrent she uploaded.. it doesnt even make sense that it was her own material (so noone else could have it to hellp seed) AND she didnt even seed it not even once but nevertheless, more than 5 seeds emerged in the time she was seeding... weird eh?.. that is simply impossible UNLESS there is a bug in utorrent... thus my reply to her to come here and talk to u guys.. obviously u lack the skills to do a simple tcpdump and verify what i m saying... if u dont know how to code then leave the coding for the ppl that do and then start judging. Probably the reason those other trackers banned ur entire branch is because of ur attitude. we havent yet, but unless u fix this issue i gurantee that every private tracker will ban ur entire branch once i notify the admins of this bug.

excuse my attitude, but i m allergic to bullshit.

peace.

edit: since u asked for details: the problem lies in the fact that utorrent missreports upload amounts to the tracker.. it seems to be recording much less than actually is the case.. now u know the problem (there are probably more, but i dont use utorrent so i have no reason to conduct more tests on it other than what i did)

[DreadWingKnight]

I'm sorry, but your post fails several sections of the How to report bugs effectively document.

the problem lies in the fact that utorrent missreports upload amounts to the tracker.

Provide EXACT steps to reproduce this issue.

[jait]

dude, i do not have exact steps as i do not have logs of what utorrent performed ie what the client actually sent to ther peers (as i do not use that client- nor that operating system for that matter).. i am going by exactly what rebecca told me and what i see at the tracker level... i have provided her our tracker logs which she is willing to give to u..... as far as i m aware, this occured on several of her torrents.

and logically, she should have at least uploaded ~700mb since that was the size of the torrent while she only reported to us that she uploaded 540mb....

it is interesting to note, that this mullfunction i have not found in the rest of the utorrent 1.7.2 clients (or at least it has not been reported to me by anyone else).. maybe some setting is causing it in utorrent.. i dont know.. i m not familiar with the client nore the settings of my user... in any case, what the client reports to the tracker should be consistant with what the client sends to the other peers.

[Switeck]

Random packet loss?

...and of ALL things, your upload/download report to the tracker!

Possibly caused by upload speed set too high. (...or worse, unlimited!)

[Firon]

Connection drop, crashes, overloaded connection preventing tracker announces, proxy failures, trying to ghost leech. So many things outside of µTorrent's control. Unless you (or someone else, and rebecca's report sure doesn't cut it) can prove this by testing the client and finding out how to do it consistently, your report just doesn't help at all and will be ignored.

Tracker staff I know quite well have not reported it, and I'm a lot more inclined to believe them.

[Switeck]

Being unable to reproduce a bug does not mean the bug may not exist.

However, you MUST be exacting as you can to localize the bug (if it exists) to make it reproducible by others or eliminate outside sources...if the bug's not in the program in question (µTorrent).

Good luck, the hardest jobs fall to those who are only experts after they're done.

[rebeccah]

Two things I would be grateful if you could explain

From the little I know about how it works, how could random packet loss explain how the amount reported to the tracker is less than the total file amount when I have the only file and it has been completely seeded?

also upload speed set too high? It is set to the default settings, using the speed guide in utorrent, which is unlimited. Should I be setting it anyway differently?The upload speed is usually around 25kps.My connection is 2MBps

Can you explain what ghost leech is please. There is no proxy connection on my pc. Presumably connection failures would just mean that the stats weren't reported that time but would be the next time it was connected.

I don't know how utorrent reports to the tracker, so can't provide you with any information on that.

thanks

[system]

First off, are you the same jait who takes pleasure in using other peoples code to exploit tbsource sites?

This isn't coding, it's being a script kiddy.

Secondly, your entire report is based on the fact that an uploader reported 540MB out of a 700MB torrent.

Instead of ranting about everyone elses lack of knowledge, you should perhaps think for a minute.

If her client disconnected and reconnected at the 160MB point, it may only show 540MB uploaded for that torrent unless you record all previous sessions.

If another peer downloaded 160MB or more elsewhere, they would have been able to provide that upload without showing as a seed.

It is possible to join ghost peers (including seeds) to a swarm without the tracker ever knowing about it and without using DHT. In this case, your tracker logs wont be anything like a complete record of what's happening.

Someone using a hacked or spoofing client to allow DHT on private torrents could easily have picked up parts of the file over DHT and seeded it in. Again, they would not have to show as a seed.

As mentioned by firon, failed announces can and do happen. Unless you keep all peers listed for all torrents for the life of the torrent, there comes a point where the code should consider the peer timed out. At that point, the tracker will most likely take the next announce as being 0 upload, and wait for the announce after that to add anything to the stats. This one can probably be discounted if your logs show an announced upload of only 540MB.

There's many reasons for this to have happened. The fact that this has been reported by one client on one torrent does not automatically mean a client error. If it's not even reproducable with the same settings, it suggests it's not a client error.

Final point. To anyone with the technical knowledge to understand INT overflows, it's a perfectly valid line of thought when there are no numbers given. In PHP, integers overflow at 2GB and wrap around to either a negative integer or a lower value. Your tracker is written in c++, which supports other INT types, but may or may not support integers bigger than 32 bits. If your tracker uses unsigned long, it'll hit the same problems at 4GB. A signed long will behave exactly like PHP. Only if your code uses long long (signed or unsigned) will it behave any differently (and still hit overflows at other points, just much larger). Integer sizes are a part of the language used in the coding, and not everyone who fails to know the breaking points of those INTs is a retard.

BTW, your tracker will break on recording stats at either 9,223,372,036,854,775,808 or 18,446,744,073,709,551,616. Unlikely to be seen, yes, but it's the same problem as php has with lower values.

To be absolutely sure you never hit an overflow, you have to move away from INTs altogether. I have code that uses string functions for stats, which are not limited to 32,64,128 or even 256 bit numbers. Unless you're using string maths, you must be a "retard" when your stat logging screws up

Now that we know it's 700MB being talked about, we can discount overflow, but it was valid reasoning.

[Switeck]

rebeccah,

Yes, the upload speed is too high to run set as 'unlimited'. Your connection cannot handle trying to upload at unlimited speed.

Also, as far as upload speed is concerned, your connection is not 2 megabits/sec either. It's about 1/8th of that at 256 kilobits/sec...and apparently if it's only getting around 25 KiloBYTES/sec in µTorrent, it's only about 85-90% usable. So you've been cheated there too.

µTorrent needs Speed Guide (CTRL+G) to be run and needs to be set to xx/256k. Beyond that, it may run a little better to reduce the max number of connections further, but that's really personal preference so long as you have good networking software and hardware.

Ghost leeching is downloading a torrent while intentionally disconnected from the tracker and NOT reporting back download/upload stats. As far as the tracker is directly concerned, it cannot "see" you, so you are invisible to it...thus the name.

I think µTorrent may only report the change in amount it's uploaded since the last tracker update...not sure on that. Either that, or there's some other checks possibly tracker-side to prevent BitTorrent clients from reporting bogus stats...and missing a tracker update may trigger them.

[MHauge]

I have been running µTorrent 1.6.1 for a while now, but still get some strange figures on some trackers - so i'm about to be convinced that my error has nothing to do with µTorrent - but the tracker-software, hopefully the people controling that will find the bug

[system]

I think µTorrent may only report the change in amount it's uploaded since the last tracker update

Sorry to do it, but this needs correcting

All clients report a running total on uploaded and downloaded. The tracker works out how much has been uploaded since the last announce by subtracting previous upload from current upload.

If the client announces 0,100MB,200MB,300MB, then 400MB but the 200MB announce screws up for any reason, most will count the 300MB as the starting point for a new session so you'd have 100+0(dead announce)+0(restart)+100. The client would be announcing 400MB, but only 200MB would count in overall stats. The per-torrent stats would only show 100MB due to the restart at 300.

If the client manages to get the 200MB announce in (through repeated attempts) before the timeout period for the tracker though, it'll all function as normal.