Jump to content

DanielSB

Established Members
  • Posts

    22
  • Joined

  • Last visited

Posts posted by DanielSB

  1. 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

  2. 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.

  3. Currently there is one thread that performs all the just-completed torrent data file moves, according to the requests in its work queue. So, moves aren't interleaved; one move is performed and completed before the next move is started.

    Great, thank you :)

    It's possible it may be a deficiency in uTorrent Server. I haven't tested pre-allocation. However, when I tried that option recently, I thought I saw the file size grow immediately rather than later. I need to look at the code and test this more carefully to confirm this.

    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! :)

  4. The requests are queued for the thread that performs these operations.
    Right now, a torrent data file move operation is done all at once and not interleaved with other operations.

    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'd try preallocation of files as a strategy to avoid fragmentation.

    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 :D

  5. If pre-allocation won't work' date=' 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.[/quote']

    I think you will see better behavior because file moves are now done in a separate thread.

    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?

  6. The Files tab context menu is known to be broken at the moment. Double-clicking indeed should work. I'm not sure what to say if it doesn't, but if you really need the functionality now, the WebUI v0.380 WIP should work on utserver, and its context menu works (though the tradeoff is that I stupidly broke double-click support too in one of the recent builds). If you decide to use it, do keep the Linux Support section of the first post in mind.

    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 :)

  7. Couple of questions' date=' 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? :)

    [/quote']

    In "Chrome" works with double click. :D

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

  8. 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 :D

    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 ;)

×
×
  • Create New...