DanielSB

This is awesome, thank you! Hadn't even noticed a 64-bit version existed until today when I reinstalled my server. This saves me from installing 250+ MB of ia32libs!!! THANKS!

Thanks for the new build, will try it out now Just because I was wondering, here's the news from that rev: Changes □ Added configuration file setting low_cpu □ Fixed bug that would accept invalid characters for hexadecimal representations of integer type values in configuration file □ Fixed timestamps in log files to reflect local time □ Added configuration file setting localhost_authentication to allow administrators to override the default system behavior by disabling authentication for requests originating on the local host □ Changed data file list presentation in web UI for current torrent so that percent done for each data file updates during downloads □ Made alignment of advanced options in preferences dialog consistent among browsers □ Server version information now displays in about box when running IE □ Fixed bug where directory tab fields appeared at bottom of preferences dialog when re-opened □ Fixed bug where OK/Apply/Cancel buttons weren't visible in preferences dialog when using Internet Explorer □ Added configuration file settings uconnect_enable, uconnect_password, and uconnect_username for participating in µTorrent Remote □ Added validation of proposed values of webui.restrict setting Known Issues □ Guest mode support is broken in the web UI and/or the server □ BEP22 isn't supported on POSIX platforms □ There's no table of contents in the PDF form of the user manual □ Checking for and reporting that product updates are available isn't supported yet □ The web UI doesn't show an indication when a setting change fails to apply because the proposed value was invalid □ The web UI doesn't show an indicator if the port is blocked by a firewall □ The web UI doesn't provide control of RSS actions supported by the server □ The web UI doesn't show status and error messages generated by the server

Even though utserver is alpha, it's still a stellar piece of software. Yes, the gui is seriously flawed, but it's easy to replace it with another one — http://forum.utorrent.com/viewtopic.php?id=58156. Yes, it crashes from time to time, but that's easy to work around. E.g., in my /etc/rc.local: # uTorrent FTW - this one survives crashes ionice -n 7 -c 3 nice -n 19 su -c 'while [ -d "/home/p2p" ]; do cd /home/p2p; ./utserver; done' p2p & As you can see, my utserver runs as the user "p2p" directly from the /home/p2p directory, and I've tweaked it to use the least amount of resources, both CPU and disk wise. It starts when the server starts, and it keeps on coming back automatically whenever it might crash. This has been running fantastic for half a year now. There really aren't any features I'm missing ATM (except for a working file pre-allocation routine, so that I can ditch my slow-ass temporary drive). I use plugins in the browsers on my laptops and my workstation so that I can just right-click a magnet or .torrent link and start it on the server automagically. For what it's worth, I'm entirely grateful for this release, even if it's half a year old. Whatever kinks are there, they aren't critical, so I'm just gonna be the grateful patient user Anyone experiencing serious issues, try and see if it's not resolvable by replacing the GUI or doing a hack like the one I exemplified above.

Great, thank you Well, rather than end all my sentences with a question mark, I thought that I'd just as well test this. Just tried starting a 1.76 GB torrent with uTorrent Server. It started out with: ~$ du -csh Downloads/Running/Shanghai.2010.BDRip.XVID.AC3.HQ.Hive-CM8/ 16K Downloads/Running/Shanghai.2010.BDRip.XVID.AC3.HQ.Hive-CM8/ 16K total After a while it grew to 46 megs when the uTorrent cache was flushed. The "Pre-allocate all files" setting is enabled. As you describe, the files are *seemingly* pre-allocated, as they're all there with full sizes. Except, as you can see, the disk usage result suggests sparse files are being created. diskio.sparse_files is false. I take back my claim that zeroing out files doesn't work for pre-allocation either - it does: ~$ dd if=/dev/zero of=testfile bs=1M count=10 10+0 records in 10+0 records out 10485760 bytes (10 MB) copied, 0,0458941 s, 228 MB/s ~$ du -csh testfile 10M testfile 10M total So if you do put it on your todo list, if pre-allocation can't work otherwise, /dev/zero could be a working hack Thanks for your time and help!

Sorry if I'm sounding daft, I just want to be sure I'm following. If I'm understanding you correctly, there's one thread dedicated to moving just-completed torrent data, and thus the moving of completed data files would never cause fragmentation in and of itself? (apart from what would happen anyway given the current allocation of blocks on the target drive). I used to do this on Windows, as pre-allocation works fine there. It's been different using WINE on Linux, though, as it seems that either the pre-allocation routines are either not translated correctly to the OS layer by the WINE libs, or perhaps not all Linux FSes support pre-allocation? I seem to remember having an option in uTorrent to "actively" pre-allocate files, I'm thinking dumping zeros into the file? Although that wouldn't help, at least not on XFS, since zero-filled files do not actually use up any blocks. Is there work going on to make sure that pre-allocation will work correctly with this Linux port? The fact that I haven't been able to make it work in Linux is the sole reason I have a 600 GB RAID0 temp drive

That is beautiful, and a very nice choice, thank you very much for the info Do you know if "move threads" are queued or may happen simultaneously? I mean that if one thread is running and moving a file while another download finishes, will the newly finished torrent wait for the other move operation to finish before starting its own move operation (to avoid fragmentation on the target drive)? Sort of like how rechecks of torrents queue up ATM?

Hey, I'm Danish, bear with me

Just tried it, and indeed it works now It's beautiful! And so far, at least double-clicking a torrent to get to its properties sheet thing works fine, too. Can't recollect any other place I usually double-click, but if I experience weird behavior, I'll be sure to visit Linux Support, thanks Great work, much appreciated! Merry christmas

Hmmm... Not here. Chrome 8.0.552.224. But still good news as that probably means it *should* work

Just let uTorrent under WINE auto-update itself today, and it failed to come back up. Went here to look for a version to downgrade to, and found this. F***ing awesome! I have been hoping for something like this for years. THANK YOU!!! The AJAX (AJAJ? GUI is now in every important aspect just as functional as the native application one. The most important advantages for me here is that it's no longer necessary to run an X server on my server box, and I can have uTorrent auto-start with every boot. Oh oh oh, Christmas comes early this year Couple of questions, though: * GUI is a tad flaky at places in Chrome (like right-clicking a file in a torrent and trying to change its download priority; left-clicking in the context menu doesn't work). Is this an objective, that is, should it work on Chrome and will it, or should I prepare myself to have to use Firefox more? * Does this native Linux port mean that pre-allocation of files will work, or does it depend on the FS in question? I've never been able to actually pre-allocate files under WINE, I just get large sparse files, and assumably lots of fragmentation. * If pre-allocation won't work, will we see better behavior when finished files are moved to a different directory on a different drive, i.e. when moving of the files take a long time? Previously, when finished files are being moved to the target directory, the download speed of every other torrent would drop to a practical halt. Once again, thank you so much for this christmas present, and may your own christmases be filled with lots of goodies