[3.5.x Beta]

FWIW, _45533 beta no longer exhibits the issues I had under Win 7 [prefs | advanced | filter_box] with prior two betas.

Fixed! [in Mike's maglink version at least].]

I think mike's versions all always smaller since he builds them compressed and UT only bothers to compress non-betas.

Anyway all betta now...

[3.5.x Beta]

I'm on Win 7 still.  It starts going wonky when you backspace the filter entry, both stated versions do it, 45449 works solid.

As a test type "btfs" then backspace it out, pow.  the release notes said they fixed multiple memory leaks,  this sounds like another one to me...

 

[3.5.x Beta]

On 1/11/2020 at 3:24 AM, mike20021969 said:

3.5.5_45519 magnet:
magnet:?xt=urn:btih:9FA028A6C8F4DFF3B76501792D91A4D4F606857F
File size: 1.81 MB (1,902,824 bytes) / MD5: 83B9F5B07C113311787E7BC09890BE7D
Digitally Signed: BitTorrent Inc. 09 January 2020 18:15:58

45519, like 45505 before it, still has problems in the Options | Preferences | Advanced filter: "box".  Type chars and the list reduces as expected, but hit backspace and they do not reappear. Also lines in the main box start to disappear and the whole things gets wonky.  Most especially true when using SHIFT-F2 to get at the "special" parameters.  Been true since the addition of BTFS,  45449 is the most recent version that is actually stable...

[3.5.x Beta]

response:  it bothers me that sites can insert trackers of their choice into the magnet link url, above and beyond what's in the .torrent.  That's "sponsorship" plain and simple, and wreaks of "user tracking abuse".  and yes, anonymity...  I know DHT isn't immune to "infiltration by bad actors", but now that we have DHT working well the requirement for tracker sites is eliminated.  Thanks for listening...

 

[3.5.x Beta]

I would like to make a feature request here, FWIW.  I know some developers do hang here...

I'd like an option to SUPPRESS contact with any tracker OTHER than DHT.  Typically when I add a torrent I get the options dialog to adjust the name etc., and I click "Advanced" to delete all the trackers, which were specified in the .torrent, or via the magnet link url from the site.  However, uT has already gone ahead and contacted the trackers [if it was a magnet, in order to find the .torrent].   I don't want it to contact any tracker, EVER, just use DHT.  Does that make sense...  Thanks...

[3.5.x Beta]

Thanks, the " ul_rate_download_thres"  change from 0 to 20 worked wonders, I am now "giving back" properly.

 

[3.5.x Beta]

On to another issue with recent releases:

Upload Rate Limit.  I have prefs set to allow a higher upload rate when there are no tor's downloading.  This feature used to work, but now [when there are NO tors downloading AT ALL] it seems to constantly oscillate between the regular rate and the alt rate; this can be seen in both the status bar legend and the speed-tab's "upload rate limit" graph line.  the actual rate never seems to go above the normal rate.  It looks to me like the transport overhead (of 2kbs) is being considered, which it shouldn't since there are NO torrents in DL state at all.  This feature's "sensitivity" needs to be adjusted so it works better.

And just one more long-time gripe - the logger pane initializes BLANK if there are no torrents, STILL.

[3.5.x Beta]

user-local is the appdata one; the other "normal" location has been present since uT version 3 was unveiled. 

FWIW, when I update I just put the new exe into both dir's and launch, it autoupdates - I don't run the newer SETUP releases.  This is the old traditional way of doing it; it's always worked... [and as I recall this is the rafi recommend way to do it, to preserve all preference settings; maybe it was another guru... ].

Anyway, based on your post I went to that " Attempting to download web UI archive.."  location and managed to download the said json file, followed its link and renamed it to webui.zip and placed it into the appdata folder, and now the error is gone.  Why it didn't auto-download that I do not know, perhaps because of my old setup structure.

BUT I do think this points to a bug in the new version, IF webUI is off why is the code even bothering to check the bloody zip!

BTW, I reran the test at "http://lock.cmpxchg8b.com/utorrent-crash-test.html" and the new version doesn't crash, that's what's most important.  That was an ugly day when they uncovered that snafu...

 

[3.5.x Beta]

the exe is in two places, as it always has been [and I never knew why...]:

  'C:\Users\Paul\AppData\Roaming\uTorrent\utorrent.exe"     and

  'C:\Program Files (x86)\utorrent\utorrent.exe"

the one launched from the start menu is the user-local one.  this results in three occurrences in Task Manager, the user-local one and two utorrentIE.exe children.  Again, it's been that way for a long time now...

and yes, webui is NOT enabled in prefs | advanced | webui, nor are any vrbls enabled.

I have never enabled WebUI over the years, and never downloaded it manually.  I do not "see" it try to download the json file at startup [when monitoring net traffic].  my proxy doesn't seem to block it [Privoxy], nor does my hosts file or dns.

Anyway, just something new I noticed...

 

 

[3.5.x Beta]

with new 3.5.3.44428 I get a new error message at the very beginning of the log upon startup:

 [2018-05-08 10:21:35]  Can't read directory in web UI archive 'C:\Users\Paul\AppData\Roaming\uTorrent\webui.zip'

that path has no webui.zip file, never did.  a hold over ??  I do not have the webui turned on in prefs dialog, and all webui advanced variables are set to *false.

[3.5.x Beta]

FWIW,  i just noticed that the help / show statistics info does not increment "number of torrents added" for adds done via magnet links, just via .torrent files.  oops.

Also, it would be a nice addition if those stats could be wiped by the user, for those that don't want anyone to know that they've downloaded 1000 torrents!