javacatpaul

Established Members
  • Content Count

    63
  • Joined

  • Last visited

  • Days Won

    3

javacatpaul last won the day on March 19

javacatpaul had the most liked content!

Community Reputation

4 Neutral

2 Followers

About javacatpaul

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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..
  3. Hell, I was in the middle of editing myself and you caught it before I could click SUBMIT! Yes, the star means MODIFIED, that's what I meant to say...
  4. [edit] what I meant to say is star means MODIFIED from the default.
  5. If you see Speed there than you have "BitTorrent | Enable Protocol Enhancments" checked in options. This allowed uT to install the "BitTorrent Speed" add-on at some point. This add-on is a fairly large thing, and if you do not use it then turn it off by: 1) Quit 2) save settings.dat [just in case!] 3) launch and uncheck "enable protocol enhancments", save. 4) Quit and relaunch. It shd be off/gone now. FWIW the btspeed add-on is in the ut/helper folder. Note: once turned off it will not come back simply by turning it on again - you need to wait for it to be offered up again, perhaps a few weeks. you may also lose your earned tokens. [restoring the prev settings.dat file might bring it back immeadiately, I'm not sure tho]. But if you're not using the feature you don't care anyway... If in doubt read up on BitTorrent Speed. --- you can also disable other "baggage" in uT: TronTV, BTFS and DLive, with these Preferences | Advanced option changes: offers.dlive_enabled to false offers.TronTV_enabled to false offers.btfs_enabled to false. [I think btfs has been totally depreciated] Note: you need to hold down shift-f2 when clicking on Options | Preferences menu choice to see these "hidden" options. [This an an old trick, shift-F2 reveals a different second-set of advanced parameter-names, always best to try both regular and then shift-F2 when "snooping" thru the parameters. BEncode Editor is also great for snooping thru .dat files]. Once done these guys [F8 and F9] should be dimmed in the Options drop-down menu, and gone in the sidebar. Lightening the misc features may make it work better for you... good luck. [Remember to always make a backup of settings.dat just in case!]
  6. Yeah, that's pretty typical on the days right after a new release, you need to try multiple times before you get the truely latest guy. It took me a bit but I did get 45952 on the 5th or 6th click. Madness...
  7. 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...
  8. 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...
  9. 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...
  10. 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...
  11. 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...
  12. 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...
  13. >> 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.
  14. 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...
  15. OK, I get it now, it's telling me how much SPARE [FREE] SPACE is avail on that drive! I thought it was telling me how much space the torrent would take up in disk-space [multiples of clusters/stripes vs raw byte size]. Duh! Maybe the caption should be "Available Disk Space"? Yeah, I assumed WAY too much, sorry...