Jump to content

3.5.x Beta


TylerW

Recommended Posts

New Question:    I don't see that the automatic application of the upload limit [from Prefs |Queueing]  is being applied once the seeding goal has been reached.   Both the upload continues to use lots of bandwidth and the "Up Limit" column remains blank [which means unlimited].  Shouldn't  the "Up Limit" column fill-in with the preset limit once seeding-goal has been reached?  And of course it shd throttle-down.

Also, when I do intervene and apply a manual "upload limit" it seems to fall down to 0 and stay there a long time rather than falling to the set limit; is this a normal hysteresis effect of UTP?  It stays about 0 and then finally climbs back up after about 5 minutes;  could be normal I guess....

running 45966  W7x64 [still].  Thanks..

Edited by javacatpaul
Link to comment
Share on other sites

A1. It should, unless you also enable pref->bandwidth->Alternate upload rate when not downloading, which overrides it.

A2. It's a possible behavior. I wouldn't call it normal tho... Maybe you have set it to enable limiting of overhead too, which can contribute to this side-effect and chock traffic.

Edited by rafi
Link to comment
Share on other sites

28 minutes ago, rafi said:

A1. It should, unless you also enable pref->bandwidth->Alternate upload rate when not downloading, which overrides it.

A2. It's a possible behavior. I wouldn't call it normal tho... Maybe you have set it to enable limiting of overhead too, which can contribute to this side-effect and chock traffic.

OK, 

I do have "alternate upload rate when not downloading" checked and set to basically double the global UL limit when not DL anything.   Seems like the nice thing to do, so I'll leave that.

I also have "apply rate limit to transport overhead" as that seemed logical too.  Since overhead is always small relatively I will try unchecking that to reduce any side effects.

And, since the ETA column goes blank when the seeding goal has been met I guess that's a suitable-enough indicator for the user.

Thanks.

 

Link to comment
Share on other sites

I actually believed that Utorrent 3.5.5 build 45952 finally fixed the problem of randomly dissociating files - which causes all sorts of problems.

I got my database of torrents 100% fixed, which took nearly a week to accomplish.  7800 torrents running just fine.  But then.. for no reason.. without a crash.. about 900 of them lost their associations again.  I give up!

Qbittorrent seems to be the most promising replacement for Utorrent/Bittorrent.  They just updated to version 4.3.4.1 and there is a 64 bit version. 

Rafi and a couple of others have been doing a fantastic job of making Utorrent work as best it can, and helping people overcome problems.  The fact that Rafi's repeated pleas for a 64 bit version have been ignored - tells me that Utorrent is never going to solve it's problems. 

I am keeping utorrent on my computer, but I won't be using it to download new torrents.  I will use it to seed old torrents, and probably phase it out completely in about a year.  Microsoft Windows operating system and Facebook are also loaded with errors that will probably never be fixed. 

It's interesting that in TV shows and in movies, computers are always shown working flawlessly, with no delays - yet in reality.. we get shit.  Microsoft makes untold billion$ off of it's crappy software, even though you don't buy it directly, every computer product you purchase is forced to pay royalties to Microsoft.  Even if your computer doesn't run Windows, computer manufacturers STILL have to pay Microsoft for every motherboard they produce.  It's great to have a monopoly!  Likewise with Facebook.  All facebook cares about is collecting and verifying your name, mobile phone number, location, email addresses and any other information that is none of their business, so that they can sell it to advertisers, marketers, investigators, government agencies, and anybody else that will pay for it.  Facebook even does their best to prevent you from using your own database of friends and followers to do anything.  Their lists are not alphabetical, not consistent, and unusable. 

If Qbittorrent has big problems, I will let you know. 

So far, I am very impressed with Qbittorrent.  It is very smooth and fast, and doesn't lock up or crash.  The one tiny problem I found is that if you have a torrent that contains multiple files, but you choose to skip some of them.. everything is fine UNLESS you then add those files later.  To fix it, you must remove the torrent (making sure you don't remove the files as well) and then add the torrent back and re-check it.  This is a very minor problem that I am sure they will fix.  Most people never skip files within a torrent - and when they do, they don't add them back - so they would never notice this error. 

 

Edited by joshace
update on performance of Qbittorrent.
  • Confused 1
Link to comment
Share on other sites

  • 2 weeks later...
1 hour ago, rafi said:

Both 45974 == 45918 are identical...

That's just the size of the files (if you remove the signatures and unpack UPX) are different and are 5,376,512 bytes for 3.5.5.45974 and 5,385,256 bytes for 3.5.5.45918.

Edited by YuriPet
Link to comment
Share on other sites

De-associated, and re-associated. Just need to find something I want to download! (The downloading bit works without issue.)

Latest problem is a persistent message that pops up when starting uTorrent. 

A newer version of uTorrent, 3.5.5 build 45974 is already running. Would you like to downgrade to 3.5.5 build 45852? Choose "No" to continue running uTorrent."

I choose 'No'. :)

This is a persistent issue. It's appeared for the last 3 or 4 beta version updates.

Link to comment
Share on other sites

On 4/12/2021 at 6:04 PM, rafi said:

Both 45974 == 45918 are identical...

They're not identical.
Sure, they may be the same size but they have different checksums.
3.5.5_45918.exe : CRC32 = D522A732
3.5.5_45974.exe : CRC32 = A245C1D9

It's not the first time 2 releases have had the same size.
For example:
3.5.5_45838.exe & 3.5.5_45790.exe are both 2.01 MB (2,113,240 bytes).
3.5.5_45776.exe & 3.5.5_45702.exe are both 1.83 MB (1,920,232 bytes).

Edited by mike20021969
Link to comment
Share on other sites

uTorrent v3.5.5 build 45988

http://download-new.utorrent.com/endpoint/utorrent/os/windows/track/stable

or

http://download-new.utorrent.com/uuid/e744c0c2-1168-4a8c-9719-0348dfc85914

File size: 5,01 MiB (5.252.904 bytes) / MD5: c7d8be7eef6ef338b9d43013a8c103f1
Digitally Signed: BitTorrent Inc. 21 April 2021

 

uTorrent 3.5.5 Build 45988 Update

http://llsw.download3.utorrent.com/3.5.5/utorrent.45988.installer.exe

File size: 2,03 MiB (2.133.032 bytes) / MD5: 2DFF38F4CCA96A429EBDDD2E9AD02573
Digitally Signed: BitTorrent Inc. 20 April 2021

Edited by ex58
Link to comment
Share on other sites

20 hours ago, ex58 said:

uTorrent 3.5.5 Build 45988 Update

http://llsw.download3.utorrent.com/3.5.5/utorrent.45988.installer.exe

File size: 2,03 MiB (2.133.032 bytes) / MD5: 2DFF38F4CCA96A429EBDDD2E9AD02573
Digitally Signed: BitTorrent Inc. 20 April 2021

LAA flagged stable version updated as well.   Size is: 2,133,032

From μTorrent 3.5.5 Beta (build 45986):

April 23, 2021

  • Fixed GDI leak issue
  • Fixed IEframe related hang
  • Fixed invalid Pro license bug.
Edited by rafi
Link to comment
Share on other sites

Are you sure this is GDI stable?  After around 10 hours it had 530 GDI open, and after adding 10 torrents, then moving and deleting 10 different torrents in the program, it has 661.  It definitely gave some GDI back, peak was around 780 during use, but that it didn't go back when the same number of torrents is in the program, and no significantly different paths for the new compared to the old, I am concerned. 

Link to comment
Share on other sites

What I am sure of, is that the previous leak , which  was root caused to the new BT Speed (so every refresh of  that icon leaked) - was fixed . It does not mean there aren't any other leaks, just that manual operations like you are describing - will never reach 10K, so the related increases  are not that important...

Edited by rafi
Link to comment
Share on other sites

Well, depends on how long you go without reboots/shutting down the program I guess.  The problem is the "set download location" function.  This is how I move content files before deleting the torrents.  When this function is used, not all GDI objects used in displaying the file window are returned when the window is closed.  Seems to be ~ 10 or so GDI per torrent, and I tend to do this in batches of up to 20 at a time.  Small, but its there.  Now up to 831. 

Link to comment
Share on other sites

I am using this function often, probably not massively as you are tho... Never had  real GDI related issues after those actions. It is a minimal leak. I'd let it be, have the devs focus on more important issues, like easily reaching GUI overload (not GDI related)  when reaching  40MB/s rate or so over time... It is poorly designed (process-wise).

Edited by rafi
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...