javacatpaul
-
Posts
136 -
Joined
-
Last visited
-
Days Won
14
Content Type
Profiles
Forums
Gallery
Downloads
Events
Blogs
Store
Posts posted by javacatpaul
-
-
18 hours ago, icebox said:
>>> * I thought was for manually adjusted settings.
the star [asterisk] on a value means it is the default.
[edit] what I meant to say is star means MODIFIED from the default.
-
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!]
-
1
-
-
19 hours ago, Bacc said:
The link above only downloads the old stable version for me, 45852.
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...
-
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...
-
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...
-
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...
-
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...
-
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...
-
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...
-
>> 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.
-
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...
-
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...
-
Just noticed something in 45852...
the add torrent dialog "torrent content" area [right-side] has a "size" line that says torrent's dl size and then "(disk space:xxx)". xxx is always 1.25 TB . Thats a bug! it even says 1.25 TB when it doesn't have the .torrent file yet...
just spotted that, probably been there for years, not important really but amusing...
-
Yeah, that's why you want to use the 2 mb size version without the wrapper-installer. Just rename the small guy to utorrent.exe and overwrite the old with the new and launch it directly from its normal location [%appdata%\utorrent], it'll self-update with no fuss at all.
If you launch the small guy from another location it will redo its [minimal] install , asking a few questions before overwriting itself, and you might loose a few settings but not many, it preserves your setup. But it's easiest to just overwrite it yourself and avoiding any sort of install at all.
BTW, to find the small guy inside of large one, open the large one with 7zip; you'll see within a file called "carrier.exe", that's the small guy, everything else is "the installer" crap, which often offers up shareware...just extract carrier.exe, rename to utorrent.exe and do the overwrite - voila...you're updated...with all your settings intact [important if you turned off all the ads.]
I've been overwritting for years and never once seen an ad or any shareware...
Always look for the 2 mb size, or extract it yourself from the 4mb wrapper...
-
2
-
-
one more thing, not to be a nudge...
I have the tool to set the LAA flag [from ntcore named 4gb_patch.exe] and have used it before. when I use it on the orig carrier file from ex58 I get a diff file than from you; the tool sets the LAA flag AND ALSO UPDATES THE CHECKSUM in the second optional header [according to PE Deconstructor and WinMerge], but yours only set the LAA flag in the first header, the checksum remains unchanged. I'm not really sure what effect that actually has on the Windows loader, if it objects to the checksum missmatch or not; it clearly does launch the exe without an error dialog. I'm not even sure the 2nd header checksum actually even covers the first header, but the tool does update it, and that tool has been around for years and years, they must have had a reason for doing it, perhaps wrongly!
Just thought I'd ask...
ALSO... [ yeah, more
] both versions above do not verfy when examined by Process Explorer, which is expected since the image was changed and the bittorrent signature was not; totally expected...
-
yeah, I followed the original link in the quoated text, not the link in your footer, sorry...
-
rafi, that INSTALLER has LAA set, but embedded carrier.exe does not...
ahh, I guess you meant to follow the link in your footer, sorry...
-
"Enable protocol enhancements" setting causes settings variable "wallet_integration_enabled" to be set to true, which allows Tron and BitTorrent Token (BTT) to use BitTorrent Speed, a monetized exchange mechanism (you get "paid" for participating). The "W" is for Wallet.
Search for "BitTorrent Speed" and read all about it...
-
39 minutes ago, rafi said:
I think it fails when the download path have NOT been created yet (first few second of each file, when it is in cache).
Just check if the folder really exists on disk.
yeah, the folder does exist. rt click on the FILE'S LINE [in file tab] and choose open destination and it works right, but right click on the TORRENT LINE [in main pane] and it open's my docs...
-
new bug in 45714: when double clicking a completed torrent [to open its folder] it now opens My Documents intead of the torrent's folder. new in 45714 I think. FYI, the torrent's properties lists the dir path correctly, and it is filled properly with the files, nothing was actually saved into My Docs.
FYI, this particular torrent only had SOME of its files selected for download. As a test, I choose all files and set them to priority=normal -- and IT WORKED properly when ALL files were done dl'ing. So, maybe not new in 45714, maybe an esoteric case, tho I havn't seen it before and I do often only DL selected files in a package...
Later...
attempts to duplicate this with different torrent failed, it worked just fine...hum...
btw, search drop-down menu positioning bug is fixed. also could not duplicate "reset history" clears UPnP port forward issue, thats seems to work fine now too; my guess it may be a race condition wth my router's UPnP cmd stack.
Later Still...
OK here's a test case that does fail consistently:
use ctl-O and this hash A885CF05B3729D6B7431E3B456329FDF84ECE691
click Select None button and then check just the first file, track 3 then click OK
Let it finish dl'ing track 3 and it'll notify that the torrent is done
double click the torrent line [or rt-click Open Containing Folder] and it'll open My Docs insted of the true destination folder. THERE!
So, wierd huh... -
I just noticed it... [W7 btw...]
-
another bug in 45710: when doing a "reset history" in options | prefs | transfer cap page, the port forward [via UPnP] in the router goes away, thus all incoming stops. Doing it a second time seems to bring it back tho. interesting...
-
re 45710, new search has bug, drop-down menu appears way off to the left and up in corner of screen rather than at the down-arrow location. This is in win 7. Also it's rather distracting sitting smack in the middle of the tile bar, looked better right justified as before.
-
I tested the direct from UT version 0f _45553 and it no longer has the problem either.
re: sizes, I examined both and all I see is ut version has an RCDATA resource that mike's does not, and the segments have different offsets (duh). mike's build is not including something... but mike's build in not one of those newer and much larger "installer types" that has the embedded CARRIER.EXE original, which I always extract and discard the wrapper.
3.5.x Beta
in Announcements
Posted
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...