TylerW

3.5.x Beta

Recommended Posts

I have the 2nd fastest SSD's made.. (the fastest cost a mega fortune)

I am very pleased to say.. that it LOOKS like build 45918 has FIXED the disassociation problem (or at least allows the disassociated files to be fixed)

I have a few hundred torrents that are now "re-associated" that were locked up.. being rechecked.  After that is done, I am going to try giving ALL 7588 of my torrents a unique label.  If all of them take the unique label, then that means that they are all "associated" 

It seems like even though the developers don't respond to the forum posts.. they DO pay attention.   The three updates in the past few days after going a LONG LONG time with no updates tells me they went to work on the disassociation problem.. and fixed it!

Of course, by saying that.. I have probably jinxed it.. and when I reboot my computer will explode, my hair will fall out, and my house will burn down.

Share this post


Link to post
Share on other sites

45918 allowed me to fix all the dis-associated files.. and Utorrent runs MUCH smoother and faster when all the dis-associated torrents are fixed. 

I will let you know if I find any problems... but it looks like 45918 is a WINNER.

 

Share this post


Link to post
Share on other sites
2 hours ago, joshace said:

45918 allowed me to fix all the dis-associated files.. and Utorrent runs MUCH smoother and faster when all the dis-associated torrents are fixed. 

I will let you know if I find any problems... but it looks like 45918 is a WINNER.

 

I'm hesitant but I guess at this point I do not have much to loose I have hundreds of disassociated torrents I'll give it a try and see if it fixes the problem?

Share this post


Link to post
Share on other sites

Tried to install 45918 as a user - normal procedure. received the message

"uTorrent Install Wizard - We're sorry, the installer encountered an unrecoverable error and must quit. (Error: Permission denied: file: common.js; line: 10)"

I'm currently running 45852 - thought I'd try updating to a beta - have normally been able to do this without issue.

Tried again running the installer as admin. Went all the way through the process before telling me a newer version - 45918 - is installed and would I like to downgrade to 45852? Selecting 'No' loads 45918.

Let's see how it goes.

Note: this also added an extension - 'Safe Torrent Scanner' - to Google Chrome. There was no notification that this was going to happen.

Edited by gjm

Share this post


Link to post
Share on other sites
22 minutes ago, gjm said:

Tried to install 45918 as a user - normal procedure. received the message

"uTorrent Install Wizard - We're sorry, the installer encountered an unrecoverable error and must quit. (Error: Permission denied: file: common.js; line: 10)"

I'm currently running 45852 - thought I'd try updating to a beta - have normally been able to do this without issue.

Tried again running the installer as admin. Went all the way through the process before telling me a newer version - 45918 - is installed and would I like to downgrade to 45852? Selecting 'No' loads 45918.

Let's see how it goes.

Note: this also added an extension - 'Safe Torrent Scanner' - to Google Chrome. There was no notification that this was going to happen.

don't use the installer.  Use Rafi's LAA version that already has utorrent extracted from it. 

  • Like 1

Share this post


Link to post
Share on other sites
49 minutes ago, R2_D2 said:

I'm hesitant but I guess at this point I do not have much to loose I have hundreds of disassociated torrents I'll give it a try and see if it fixes the problem?

I should have been more clear..   it allows you to FIX the problems with the methods I mentioned before (rename bad torrents to something like *.torr) and restart utorrent, then rename the *.torr files back to *.torrent and recheck)

it doesn't automatically fix the problems.  The previous versions would not even allow me to manually fix the problems.

my HOPE is that build 45918 doesn't create MORE disassociated files.    I found some more buried in my 7800 torrents, but they are clearing up bit by bit.

Share this post


Link to post
Share on other sites

Bad news.. 45918 still has problems.. but I have not given up on it yet. 

=====

Update.. I think what I will do is rather than migrate all my torrents to another client.  I will stop using Utorrent and start using another client for my future torrenting.  If that client is buggy... I will migrate the new torrents to Utorrent.   One warning about that.. if you choose to use Bittorrent which is published by the same company, it will use the same database - and Bittorrent has substantial problems of it's own. 

===

By the way.. Utorrent should have a feature where you can have MULTIPLE databases.. so that when one gets thousands of torrents, instead of getting bogged down, you can go to another database.  Having a separate database for every year would be a good idea.  Everybody's database is constantly growing.  What is someone supposed to do when their database is too large for them to manage? 

 

 

Edited by joshace
New strategy.. and new feature request.

Share this post


Link to post
Share on other sites

Is it possible to run multiple instances, each with its own path, port number and destination directory?  Only issue I can think of
would be which one gets the hand-off when you click on a torrent.  That might be solvable simply be naming the .exe's differently...

If you can't run multiple instances at a time, you could still have multiple instances setup on disk, and run just one each day to allow say 1/3 or so of your collection to be available at a time.

Perhaps [as you suggest] a new feature supporting multiple repositories in Options and, which upon start up or via parameter would asks which repository to handle on this launch would be simple to implement and useful to advanced users.

Plus, I have to say that while I applaud your "generosity" by offering up so many torrents to the community, uT was never designed to be a "server-grade" tool, it's for "users" and wasn't [and maybe simply can't] scale up to really large repositories.   Perhaps a new product...

 

Share this post


Link to post
Share on other sites
11 minutes ago, javacatpaul said:

Is it possible to run multiple instances, each with its own path, port number and destination directory?  

It is, using the /recover command line option. 

Share this post


Link to post
Share on other sites
1 hour ago, javacatpaul said:

Is it possible to run multiple instances, each with its own path, port number and destination directory?  Only issue I can think of
would be which one gets the hand-off when you click on a torrent.  That might be solvable simply be naming the .exe's differently...

If you can't run multiple instances at a time, you could still have multiple instances setup on disk, and run just one each day to allow say 1/3 or so of your collection to be available at a time.

Perhaps [as you suggest] a new feature supporting multiple repositories in Options and, which upon start up or via parameter would asks which repository to handle on this launch would be simple to implement and useful to advanced users.

Plus, I have to say that while I applaud your "generosity" by offering up so many torrents to the community, uT was never designed to be a "server-grade" tool, it's for "users" and wasn't [and maybe simply can't] scale up to really large repositories.   Perhaps a new product...

 

Renaming .exe files doesn't affect anything.  I never heard of the "/recover" feature.  I will have to take a look at that.  I was thinking along the lines of a programs that allow for multiple accounts.. for instance.. a single program where when you start it, you select WHICH account to use:  such as a specific employee, or as I suggested a database made up of torrents of just a particular year.   //  Torrents work because of "generous" people.  Far too many people just leech what they want, and then go offline or remove the files.  The more leechers there are, the more bogged down the servers get, and files wind up vanishing or taking far too long to complete. 

Share this post


Link to post
Share on other sites

>I will have to take a look at that. 

I guess you've never read the helpfile then. Maybe you should...

Share this post


Link to post
Share on other sites

>>  Torrents work because of "generous" people.  Far too many people just leech what they want, and then go offline or remove the files.  The more leechers there are, the more bogged down the servers get, and files wind up vanishing or taking far too long to complete. 

Of course that's true and I thank you.  I try to keep things for several weeks and a ratio of at least 3 to 1, but I confess that after  that I do some house cleaning.   FWIW, on particular "special" torrents I archive the whole thing to a external drive and then about every two months make it avail again for a few days.  But I'm making excuses...

I'd suggest trying the recover thing and see if breaking the repository into pieces might be the solution, then you could write it up for those interested in trying it too.

Share this post


Link to post
Share on other sites
1 hour ago, rafi said:

It is, using the /recover command line option. 

 

17 minutes ago, javacatpaul said:

>>  Torrents work because of "generous" people.  Far too many people just leech what they want, and then go offline or remove the files.  The more leechers there are, the more bogged down the servers get, and files wind up vanishing or taking far too long to complete. 

Of course that's true and I thank you.  I try to keep things for several weeks and a ratio of at least 3 to 1, but I confess that after  that I do some house cleaning.   FWIW, on particular "special" torrents I archive the whole thing to a external drive and then about every two months make it avail again for a few days.  But I'm making excuses...

I'd suggest trying the recover thing and see if breaking the repository into pieces might be the solution, then you could write it up for those interested in trying it too.

I just tried the /recover option.. which I never knew existed.  So far, it confuses me.  It just opened up a 2nd instance of Utorrent with the exact same database of 7643 torrents.  I expected the  /recover instance to be empty of all torrents so I could start like new...

 

Share this post


Link to post
Share on other sites

Just a note:  I was just nosing around in the BEncode Editor forum

   https://forum.utorrent.com/topic/26674-bencode-editor/page/17/

and there is a post there from forum member Odinos from back in 2015 and he states there:

  "I run a dozen instances of utorrent on a server and adding torrents by hand is just not feasable,..."

So somebody has tried this sucessfully in the past, perhaps Odinos is still around and can be contacted....

     a good pandemic lock-down busy-work exercise for a young power-user to tackle...good luck...

 

Share this post


Link to post
Share on other sites
17 minutes ago, joshace said:

 

I just tried the /recover option.. which I never knew existed.  So far, it confuses me.  It just opened up a 2nd instance of Utorrent with the exact same database of 7643 torrents.  I expected the  /recover instance to be empty of all torrents so I could start like new...

 

I guess reading one line in the the helpfile is not enough... You need to know what you are doing, and the right way to do it...

Edited by rafi

Share this post


Link to post
Share on other sites


My take from MINIMAL research ---

/recover simply tells launching ut.exe to not do the "is there an instance already running" check, and instead just run.

So to make it work you need to set things up right.  Try this...

go into your appdata folder and find the utorrent folder.  Copy it and Paste it back in twice. Rename the copies to UT1 and UT2.  [hell, paste a third and call it SAFETY_BACKUP, you'd hate to lose that sucker during testing!!!]

Go into each and

   - rename utorrent.exe to ut1.exe and ut2.exe
   - delete the .old files [or move to a junk folder just in case]
   - delete resume.dat
   - delete dht.dat [it'll remake with a new node_id]
   - leave settings.dat alone for now. perhaps make a safety backup.

now make a shortcut to each .exe and edit that shortcut to add the /recover option; move the shortcuts to the desktop for testing.

create two new folders to hold each guy's repository, UT1_TOR  and  UT2_TOR, at the root of a drive [or alongside wherever your current repository is].  Leave them empty for now.

You should be set.  Make sure your main uT is not running. And for this testing, RENAME the main repository directory by appending something to its name; you want it to be not found. [DON'T FORGET TO NAME IT BACK AGAIN AFTER TESTING!!]

Fire up UT1 via the desktop shortcut.  It shd report some errors about not finding the repository folder, good.  Open preferences and fix up/verify the port number, firewall choices, UPNP info, path to this guy's repository, etc. Make it all point to UT1's places with UT1 unique port, ID, etc.  Quit UT1.  Fire it up again.  It ought to look fine now, with no torrents.  Quit.

Repeat the above using UT2's shortcut. Fix up its prefs and Quit. Relaunch to verify, and quit.

Now,  COPY a few torrents and their data-folders from main repository to UT1's repository folder.  Do same with different torr's for UT2.

Fire up UT1.  Does it "find" the torrents and start serving them?  Check if preferences | directories | "automatically load torrents from" is checked and pointing to the right place.  It should find the torrs and serve them.  You may need to do a right-click Recheck and then resume the torrents. You may need to do an Add Torrent and point to the .torrent file [that would be a pain for thousands of tor's!].

Now Try UT2, while UT1 is still running.  It too should find and serve its torrents.

Take a look at Task Manager and see that both instances seems to be working side by side just fine. Rememeber that each one will also have two companion processes named utorrentie.exe, they should be seperate and linked back to their respective parents.

If it all works you can continue to divide torrents between the two repositories and carry on.  GET FAMILIAR WITH THE SETUP COMPLETELY before commiting  to the new scheme.

Lets us know....

Note you may then need to tell your browser where to pass torrs and mag-links, rememeber until you do that it'll want to fire up the original master which doesn't have the /recover option yet...be careful...

 

Edited by javacatpaul

Share this post


Link to post
Share on other sites
1 hour ago, rafi said:

I guess reading one line in the the helpfile is not enough... You need to know what you are doing, and the right way to do it...

Well, I did read the helpfile.. but I searched under "/recover" when I should have searched for "encapsulated"

I will give that a shot. 

I'm also working on ways to prevent Utorrent from getting bogged down in the first place.  I've had a lot of success in repairing disassociated torrents, but I am still working on preventing MORE disassociated torrents from occurring. 

Share this post


Link to post
Share on other sites

I have came across a strange bug in the latest beta 45918:

 

It sometimes (about once a day) display a message box saying something like 'Select our partners...', but I cant close that message box! If i for example denies everything and select 'save' nothing happens and uTorrent becomes unresponsive, and also if enable everything and select 'save' uTorrent becomes unresponsive, I ended up closing it in task-manager, after having waited about 30Mins for it...

This was not the case with the earlier builds...

Share this post


Link to post
Share on other sites

Most likely - ads/offers  related ... Best way to avoid such bugs - is to disable ads altogether... if you don't know how - use my settings example (in my sig)..

Edited by rafi

Share this post


Link to post
Share on other sites

RE:  Beta 45918

 I am noticing with this release that the logging tab is reporting A LOT of FAILED HASH CHECK  entries [1 or 2 per second] without causing a ban to be imposed.   maybe a minute's worth before I finally get a ban.  My ban parameters are unchanged, 128, 3, and True [ratio, thres, use_thres].  Has happened on a couple of different torrents and a couple of different users so far today.  FWIW...

Share this post


Link to post
Share on other sites

FOR THE DEVELOPERS TO READ:

re:  multiple instances

when playing with multiple encapsulated instances and the use of /recover, I noticed that the hand-off of  browser clicks and explorer double-clicks to the ASSOCIATED instance [just 1 is associated, and the 2nd is in its own path and has a changed .exe name]  seems to go to the top-most [z-order] active instance instead of the SPECIFIC [path in the registry] associated instance.

My guess is create_mutex()  is used to find an already running instance, and a static-string-constant  is used as the mutex name.  So even tho the two .exe's have different paths and different .exe names they are both using the same mutex.  A solution would be to use argv[0] [cleaned up] as the mutex name, so that every individually-encapsulated instance has its own mutex to identify itself as "already running", and that mutex-owner's WHND shd receive  the hand-off of the maglink/.torrent DDE-msg, rather than sending thru the z-order.  This way only the truely associated instance would get launched-or-receive-the-handoff even when another instance is already running.   PLUS,  the /recover parameter would actually not be required anymore to launch a seperately-encapsulated instance, a plus because accidentally launching a second copy in the same path is really bad for the .dat files [which I discovered when futzing].

Now I know uT has some funcky behavoir on startup deciding if it is "installed already" or "shd be installed" and a change like the above might effect that,  but it's worth looking at.  I know multi-instance is very low priority and it has other pitfalls, but I thought I'd toss out my 2 cents...thanks for listening...

 

Share this post


Link to post
Share on other sites
7 minutes ago, javacatpaul said:

FOR THE DEVELOPERS TO READ:

re:  multiple instances

when playing with multiple encapsulated instances and the use of /recover, I noticed that the hand-off of  browser clicks and explorer double-clicks to the ASSOCIATED instance [just 1 is associated, and the 2nd is in its own path and has a changed .exe name] 

Describe your setup details: are any other file(s)  located in each exe folder (except for the exe itself)?

Edited by rafi

Share this post


Link to post
Share on other sites
48 minutes ago, rafi said:

Describe your setup details: are any other file(s)  located in each exe folder (except for the exe itself)?

ok.  2nd instance is full copy of original's \appdata\ut   folder, renamed to appdata\UT2, and .exe renamed to UT2.exe and settings.dat fixed-up to point to different repository paths with different port numbers, etc.  dht_node_id and client_id were also changed to ensure they were different.  resume.dat was deleted of course.  subfolders are still there with their contents. 2nd instance is fired up via shortcut with the /recover param.  2nd instance is NOT associated [did not click the assocate button], only original remains associated in the reg.

fire up the original [alone] and everything works just as it did before, as expected.  quit original.

fire up 2nd [alone] and it comes up just fine, serves up the torrents I placed in its repository just fine. quit 2nd.

fire up original, then fire up 2nd.  both running fine side by side.  6 processes in the task manager, parent-child linkage looks fine, both ports linked to right processes as expected.  Each working its own set of torrents and DHT slice, all fine.  minimize both to tray.

fire up browser.  go to a torrent link site, choose a torrent,  but don't click the maglink  [or .torrent link] yet.

raise original instance from tray.  go back to browser and click maglink, hand-off goes to original.  cancel.

minimize original, raise 2nd from tray.  go back to browser and click maglink again, hand-off goes to 2nd!  cancel.

minimize 2nd and repeat, maglink click still goes to 2nd  [it's most-recently-active, zorder I guess].  raise original and lower it again, maglink click now goes to original.

Now, when you do these clicks you do see that win launchs the original exe ALWAYS [cause that's what's associated] but it quickly determines "i am already running" and hands off the DDE [drag and drop exchange, ie the link-info, %1] and quits itself.   But the hand-off isn't to the specific associated-path exe, it seems to pass thru the z-order stack of win handles. and gets processed by whichever instance is most-recently-active.   If it's using the win_handle of the mutex owner then that handle is changing, which would [IMHO] be win api FU, so I assume it's z-order related somehow.

Additionally, if only 2nd is running and a link is clicked the 2nd gets the hand-off, rather that the accociated original being launched and handling the link.  Basically only the original should ever be handling browser click hand-offs or explorer double-clicks of uT associated objects.

Thanks for listening...

 

Edited by javacatpaul

Share this post


Link to post
Share on other sites

 

34 minutes ago, javacatpaul said:

 which would [IMHO] be win api FU,

I agree... So, if just the association is broken/unpredictable  - it's not such a big deal, API hasn't  probably been designed to work that way...  

You can always just copy the magnet link to the clipboard and use file->add-torrent-from-URI (ctrl-U) in whatever instance you want, so  to avoid confusion.

Edited by rafi

Share this post


Link to post
Share on other sites
1 minute ago, rafi said:

 

I agree... So, if just the association is broken/unpredictable  - it's not such a big deal, API hasn't  probably been designed to work that way...  

You can always just copy the magnet link to the clipboard and use file->add-torrent-from-URI in whatever instance you want, so  to avoid confusion.

 

1)  yeah, the api may be "unpredictable" with "dual owners" of the mutex.  but if the mutex's were named with an argv[0] derived name then the instances would be unique.   And /recover would not be needed at all...

2) copy [just] the hash-id and paste into uT via ctl-U  has been my standard method for years, it relies on DHT alone and has rarely ever failed to work just fine [even works on private torrents, please don't fix that bug!].   I don't like annoucing to Trackers if I don't need to.

Carry on...

 

 

 

Share this post


Link to post
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.