Posts made by amice

it's not the server's fault, but the crappy BT clients not complying with BT specifications.

instead of "have it" message they send "100% completed" that causes these false info stats.

not all accounts that are listed as banned, are really such. when i started to handle duplicate accounts, i didn't fully know what this

banned list will act like. (when admins have some time, i will ask them to clear the banned list, to avoid misunderstandings). actually,

as Uwe already wrote, the system doesn't distinguish between self-deleted and banned accounts, so sometimes you can see a lot

of 'as if' banned accounts in the log. don't be afraid, it's not that bad as it looks like 

last approx. 14 days I'm getting weird page load freezes as well - F5/refresh has to be executed several times to get the page loaded… with all browsers...

nope. in this very case, the likeliest reason is a bug in the latest uTorrent version, or even more likely, you just caught a user who just finished his download, but the tracker's database didn't get refreshed yet - i.e. it happened in the interim. the other ways are spoofed uT versions which allow the permanent setting as a seeder (although they are not) or as a leecher (although they already have it), i have one of those. descriptions say about different tracker scenarios which can be spoofed/utilized this way…

@MrMazda:

I'm not sure of the technical reason as to why it worked, but resetting the passkey then disabling and re-enabling the download rights appears to have corrected the problem. I've never quite seen anything like this before.

Uwe got it correctly + i will add the missing part of this reason.

it depends how you start the torrents. the tracker protection has its limits which i may not disclose. nonetheless, aiweelie accidentally hit them.

it was sufficient to stop all torrents / or close the client + wait some time until site database settles things down. sometimes, if stop signal  isn't properly received (for various technical reasons) your account may get blocked by the tracker limit protection for up to 60 minutes of the last torrent announce (if you started more items, the last one's counts). therefore it may appear that it was needed to reset his passkey and dl-rights, but in fact, it had/has no impact on this issue.

if something similar happens again, calm down the users and ask them to stop/close their clients & check their profiles if you can see the desired effect (0/0). if users cannot fix this, after 60 minutes this problem should get gone itself.

when you save changes - this time is used.

the time limit for marking changes is 1 minute. within this time changes are not marked.

one plea to you: when you only quote the previous message, without need to pick up concrete statements, erase all text except the quote header between:

[ quote ] & [ /quote ]

the quote link is still clickable; those who want to read what you are refering to, can get there via this link. like this:

@wombat2:

@Gr1zz:

…
If you include the pictures, the torrent will be a different size than the original, especially if the pics go before the main movie, then each block of the resulting torrent will be different, and there will be no jump-on problems!

The only way the jump-on can happen is if the new torrent is IDENTICAL to the one the other person has.  Adding a single pic, or a text file, something like 'Thank <user>at GT.RU for this download!" can make it different enough that a jump-on can't happen...</user>

either you have the full torrent content or partial, you still can act as an "on-jumper", hence including additional stuff doesn't protect from jumping-on at all.

guys … if you want to understand a problem, you need to look at it from various angles.

@wombat2:

…
You don't seem to understand the torrent site ethos of "sharing with friends"..
It's not about my ego or yours.. it's about FRIENDS sharing as best they can...  :hug:
...

sure, but: this is a strict high-ratio demanding site, hence we need some order in these things. if the only goal would be sharing, be it, but users with slow uplinks suffer here, and it's something we don't want.

basically jumping-on wouldn't need be a problem if users would set their clients properly. but who cares? i saw a few jump-on'ers not only with 1.1 ratio, but even 10x more. this is inacceptable regardless their reasons. low ratio problem is my problem, i have no right to burden someone else with it.

when users see that their uplink bandwidth is exhausted and cannot afford or establish a better one, and have no new stuff to upload, the only way is donation or deletion of the account. another problem: connectability. users should demand 1:1 NAT from their ISPs. once established, also home gateway setting + firewall is needed, so that incoming ports are open. otherwise such users get lost in the ratio 'war' …

dears, once for all: we (staff) cannot stop anyone doing this. it's technically impossible because the transfers are P2P based –> you have no transfer interaction with the tracker but with yourselves only (with each other).

i hope that admins will find a technical solution how to stop this pet peeve (and not only this one). so far you are allowed to PM those users to ask them to stop their uploads of your fresh torrents. report them only if you cannot reach them by PM, or if you can but they don't seem to reflect to your request.

because this tracker has strict and hard ratio demands, we need a system for all users, not only for uploaders. while fast uplinks are still rare (compared to growing fast downloads), it's not that easy to make a system which would suit all users    we had many internal (staff) discussions about this topic, and still are not able to come to a concrete solution.

previously i had an idea about making some filters which would prevent new and low-ratio users from leeching torrents with a bad "health" (per-torrent up/down ratio), based on their account ratio. this way would be the easiest one of other possible, as other ways require too many combinations for calculation, and coding work (not talking about hunting and squashing bugs). i also had some ideas about lowering the current obligatory ratio levels, but admins say that users abused it in the past, so i'm lost here.

i too, would like to have an option to reset seeding levels in uTorrent, we (users) are still wanting and waiting for this longtime asked feature    …and also for a better sharing scheduler (there is none so far doing what we need) 

@blackdid:

…
Well, now you teach me something new as I didn't know at all what was "over-seeding" and the bad effects it could have on others.
I found a link that may be interesting, with someone asking : "What is overseeding ?"
And the 1st answer given to him was : "Some who overseed make it hard for others to seed back what they've downloaded"

hxxp://forums.whirlpool.net.au/archive/915839

there is nothing to "teach", the title of this says for all. over is simply over. or is there anything special to explain for you?

@__blackdid__

actually, there is no special explanation for you necessary, as your example was absolutely correct (perhaps if you read my reply with more attention, you could save your fingers - because i completely agree with you). my reaction only precises your previous utterance. in fact, connectibility has no effect on it. now have a closer look at what happens and why the real result is different from this 'scheme'…

there are more forms of 'bad behavior' on this tracker, not only jumping-on. another flaming problem names over-seeding - here's the stumbling-block of this case. two basic forms of overseeding can be recognized: too fast up-streams & over-ratio. both are dangerous and detrimental for new users and for slow-liners. if all users would be gentlemen and set their clients in the spirit of a fair-share policy, no one would have problems here.

what to do? alas, there is very little to help out of this uneasiness. no rules would help resolving this event, we need a firm system solution - site software control against all 3 pet peeves: jumping-on, up-streams, over-ratio. i hope you can imagine how a complicated change this would be

however, a few tools might help with this: uTP protocol in uTorrent (supposed to help with NAT issues), initial-seeding mode (should be morally obligatory for fast-liners), maximal moral per-torrent ratio of 1.1

@__MrMazda__

you wrongly got my objection. i was talking about your opinion that non-connectible users should endure jumping-on, just because of their technical state. i asked why, because as me, Uwe and others already many times explained that connectibility may not be seen as an obstacle in the seeding process (as it isn't either).

• typos corrected

@MrMazda:

True in some cases, but not always the case. In some cases, not being connectible can also mean that a firewall or port forward setting has not been properly configured and is blocking incoming traffic to your computer. In such a case, it doesn't matter how many times the tracker updates, it will yield the same result.

shouldn't happen. even if communication is being blocked by firewall to inside, they still are able to upload to others.

@blackdid:

Because, amice, they first made a confusion with an "offline" user, thinking that if he was "offline" he won't seed anymore.
…
Apparently you mean the seeder is not "connectible" which hasn't the same meaning at all. Even if he's not connectible, he will upload to others, but not as much as if he was connectible (in fact, he'll get all new leechers names each 30 min, when he connects to GT tracker each 30 min, and will be able to upload to them only at that time)

in fact my posting was a reaction to MrMazda's last posting (that's why i didn't use quotes). now to you: either you are or aren't connectible, it has no impact on how much you upload to others; dataflow remains the same. the only difference is that someone may/can beat you in a certain time frame (fast-liners always should limit their upstreams because of this fact).

why? being 'not connectible' only means that you need to wait until the next announce round (maximally 30 minutes)

you can be sure that it works. however, we can confirm your settings (if correct) only in the time of your seeding / leeching. GT-guard enables the use of their service directly from uTorrent (& like) clients (without addidional software). once correctly set, your IP address should be identified as their IP address. in general, there are no special restrictions against torrents, unless openly alleged in any VPN provider policies, thus normally any of them should work with us. the problem comes here: this tracker system limit is set to 5 connections (= accounts) from the same IP address, or 1 account from 5 different IP addresses. once this limit is reached, there will be "who comes sooner, takes it" policy used; hence we really recommend to use your own IP address if possible. we can confirm for users the need of use of their own IP address with common VPN services, not so for GT guard (but this could be possible by using a VPN client with their settings, just for one log in to your account).

'partial seeding' .. hey, you!    ok, ok, i realized my own nonsense {and forgot to correct it in that posting}, but you can see the word "perhaps" - i wasn't sure how to call this event either. it's 'partial content seeding', not partial seeding as such, as both actions are firmly defined about what they do.

i don't know what Mgr exactly thought in his diagrams, it's all about agreed definitions only. usually it means that such a peer is NATed with 1:multi IP pool scenario {= sort of indirect access}. users used to uTorrent definitions then may get confused with the distinction between 'blocked' and 'non-connectable'. it's not the same.

normally, every solid ISP gives you 1:1 NAT scenario {in case they need to do it this way}, i.e. your private or dedicated IP address gets translated with 1:1 NAT to a public IP address. these users are always connectable. but, here comes the clue: some users share their connection with other family members or friends, etc. with cheap devices that, in default settings, are configured for 1:multi IP pool scenario. if they were clever enough, they could read manuals and set their devices to open a direct access, usually with DMZ or 'special applications', or UPnP settings. so, here is the reason why there are so many not connectable users around.

it can't be named 'partial seeding', 'cause there only can be either seeding or leeching. the status could be named 'incomplete'. even if there is no support from Cohen's side {as it is said, he doesn't plan to develope this protocol anymore}, trackers are capable to sort out these peers correctly with some software changes.

@blackdid:

In the 2nd attached pic ("case 2a.jpg") we notice the tracker "registers client B as downloading" blindly, but the tracker information is wrong because client "B" is not connectable.
My question is : why doesn't the tracker wait for an acknowledgment from client "B" (like the "thanks mate" found in 1st pic), before it registers client B as downloading ?

still the same misunderstanding over & over: 'not connectable' doesn't mean the same as 'blocked'. it means that the user has an indirect access, usually based on non-1:1 scenario. the information hence is correct. if you are in the [desc=not connectable]passive mode[/desc], you need at least 1 direct-access user to connect to and use them as a "bridge" between. the new uTP protocol in uTorrent is told to overcome even this problem. give it a try and let us know 

you hit the nail - it was the intention 

no need to worry about it - the time delay of new versions is intentional. there are 3 uTorrent streams released, each of them has its beta versions. because their development is very fast, programmers decided not to release the very new versions soon - it would bring too many client downloads, and it's actually useless. as soon as there is a greater code change, they force automatic uTorrent updates.

one detail by me more precised:
@amice:

reset of session counters has two phases, timeshifted. as soon as the stop signal is received, transfer speed counters get reset first. there is no way to avoid it. but: if you resume your transfers in a short time after stopping, uploaded counters remain intact. the time limit is about 1 minute.

it's 15-20 seconds only, sorry.