![]() But it would seem that some people want to have zero mean zero - perhaps -1 could mean unlimited. Zero now means unlimited - and for downloading that is fine (I guess). Perhaps a change in Preferences -> Bandwidth could/should be done. and the network overhead of bouncing back and forth from being a peer you can download from and to a peer you cannot - creates a lot of problems for other users who are trying to get the torrent to a completed status. My point is it can get a little crazy being snubbed/unsnubbed/piece/snubbed/. re-snub all the peers, cancel/ignore those that you unSnubbed but have yet to send the piece you sent to someone else? Download another piece therefor you are below the ratio (goal) - or download a set number of pieces to be a certain percentage below the goal. around that limit is going to be very resource intensive. Automaticly stopping, starting, stoping (again). If ratio limits are to apply to all upload activity - even to torrents that are currently in a downloading state - there are some issues that need to be addressed. I can understand the concern about continuely uploading at a high speed while downloading at a low speed and the ratio shoots up. It appears to be a flaw in design & failure to consider some jobs will have very slow d/l & (possibly) decent u/l speeds, causing them to u/l > than seeding ratio. AFAIK, all jobs that finish d/l before the seeding limit is reached, continue seeding & stop at the set 100%. On some jobs, it just doesn't observe the seeding ratio limit. (Whether still accurate or not, I read SEEDING doesn't start till AFTER d/l finishes). That tells me the ratio counter starts counting when job 1st starts u/l, but because the d/l is slow, it may have u/l > 100% BEFORE d/l finishes. I don't understand what catching a screen at 29:xx min would show.ĪFA, when "un obedient" jobs finishes, it just shows they've u/l way more than 100% & the ratio column also shows > 100%. * turns out to have somewhat decent U/L speed If I could find a SMALL torrent (cause I don't want to make "Ma" mad), in my spare time, that: If you tell me what you're hoping to see, let me know & may be able to recall from memory. Sorry, I don't have any examples left or that are in that state. Vast majority of my torrents seed > 30 min & the bulk stop at 100 %. That's NOT the case w/ the ones I'm talking about. I suppose if a job was U/L VERY fast, so it exceeds seeding limit before 30 min (current setting), then it'd continue seeding for AT LEAST 30 min. It may seed for 2 days, if it's slow & hasn't reached 100% (for torrents that stop when supposed to). Now you're just messin' w/ me - right? Do you want the screen at 29:00 min or 29 min, 59.99 sec?ġst, the "30 min seeding" is a MINIMUM time. Impossible to predict - some files start D/L fast, then drop to nothing (even some w/ good initial # of seeds) - while U/L rate continues high. one knew which files would D/L very slowly, they could limit the U/L rate for ONLY those files. Very slow D/L files w/ decent U/L rate can U/L 100's MBs before the count of seeding ratio begins. ![]() ![]() UT's "old" U/L behavior may need to change. If files D/L VERY slowly, by design U/L continues - often much faster vs D/L, but doesn't count toward seeding ratio.ĭue to stricter data caps (& overage cost), the total U/L data for each file should count toward the user selected U/L ratio. IIRC, seeding ratio "count" starts when files finish D/L. Maybe uT devs need to rethink how seeding ratios are defined. But slow D/L'g files going way over seeding ratio may cause exceeding internet data caps. NOT that it'll stop "problem" torrents going WAY over seeding limit (ratio) - it probably won't. For now, I've (reluctantly) lowered the seeding limit. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |