µTorrent Server 3.0 alpha build 27079 (for Linux) - x86

[LEVAC109]

I made the utserver.conf file. Still doesn't work :\ shows me that webui not installed message. Is anyone willing to help me with TeamViewer program?

[mit]

I made the utserver.conf file. Still doesn't work :\ shows me that webui not installed message. Is anyone willing to help me with TeamViewer program?

Try to use this for starting & stopping utserver!

For more info read here.

[DanielSB]

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

[mit]

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?

In "Chrome" works with double click.

[DanielSB]

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.

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

[Ultima]

The Files tab context menu is known to be broken at the moment in Chromium. 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.

Edit: Clarified that the context menu is broken only in Chromium.

[DanielSB]

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

[Ultima]

Hm...? "Linux Support" isn't something to visit. It's just a section of the first post in that thread I linked to that basically tells you what's expected of you if you run into bugs while running my WebUI under µTorrent Server...

[DanielSB]

Hey, I'm Danish, bear with me

[mit]

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

Actually i using this WebUI with "Firefox" (now even 4 beta) and dont find a bug to this moment.But i remember before going out this version that was accidentally find double-click option until I tried how it works in "Chrome".Now i tryed again in "Chrome" and context menu also works.In general this WebUI it's a perfectly to me.I recommend everyone to download it: WebUI v0.380 WIP

[Ultima]

Oh, yeah, I think it broke in Chromium only because Chromium's function bind() conflicts with mootools' Function.bind(), with the conflict arising as a result of Chromium having updated to match the updated ECMAscript spec for bind() a few months ago.

[mit]

Strange behavior in last release: 2010-12-24

In add torrent dialog box,when sub-path field is active (blue frame) "OK" and "Cancel" buttons does not work.(in "Firefox")

[braykov]

The dir_autoload option in the conf file does not work.

I put torrent files there and nothing happens.

Also the web UI does not show it on the prefererences - as if it is empty.

Ubuntu 10.10 64bit

[braykov]

The web UI shows "not installed" - not working if I specify the -settingspath option when I run utserver.

It only works if I put the webui.zip in the settingspath folder. If I specify the "webui_dir_files" option in the conf, it does not work for the zip. I have to extract it in a folder to make utserver see it.

Ubuntu 10.10 64bit

[mit]

The web UI shows "not installed" - not working if I specify the -settingspath option when I run utserver.

It only works if I put the webui.zip in the settingspath folder. If I specify the "webui_dir_files" option in the conf, it does not work for the zip. I have to extract it in a folder to make utserver see it.

Ubuntu 10.10 64bit

This is not true! Probably you have written something incorrect.

[Rudde]

It is very nice you have started developing utorrent for linux! Grat job guys!!

One question, can I set up RSS with this yet?

[eru]

One question, can I set up RSS with this yet?

yes, but manually :

http://forum.utorrent.com/viewtopic.php?pid=527498#p527498

[mcdonald]

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.

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

[DanielSB]

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?

[mcdonald]

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

A torrent data file move operation is requested for every just-completed torrent that needs it. The requests are queued for the thread that performs these operations. The operations will wait based upon the positions of the associated requests in the queue, but the requests are made immediately and rapidly; making the request won't block the requesting thread.

Right now, a torrent data file move operation is done all at once and not interleaved with other operations. This non-interleaving behavior may change in the future so I would not recommend depending on it. I'd try preallocation of files as a strategy to avoid fragmentation, although preallocation won't help if you are moving files between file systems since the preallocation occurs on the files in the active directory, not the completed directory.

[DanielSB]

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

[mcdonald]

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

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. No guarantee this implementation won't change, although I don't expect it to change.

Of course, depending on what else you've got running on the computer, you can still have fragmentation. That's why I was mentioning preallocation.

I'd try preallocation of files as a strategy to avoid fragmentation.

I used to do this on Windows' date=' 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?[/quote']

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.

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

There isn't any work being done on preallocation on Linux. I can put it on my personal to-do list to at least see if it works or not, but I've got assigned tasks that have priority. I'll add a task to the issues list if I find it doesn't work.

[DanielSB]

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!

[Mr. DOS]

I've got µTorrent Server up and working fine on my Debian 5.0 box, but it dies every six hours or so. While it's running as a daemon under its own steam at the moment, I had it running in a screen session to see if I could see what was happening and every time it died it complained of a segfault.

I currently have just shy of 200 torrents seeding or queued, all of which are on private Gazelle-based trackers. My global connection max is set to 200, torrent max to 50, the max number of active torrents to 50, and the max number of downloading torrents to 5.

Any possible solutions or logs I can hand over to ease debugging? I will add that transmission-daemon also died habitually with the same dataset (albeit less frequently – anywhere from two days to a week), although I've no idea if the problem is at all related.

[temptemp]

I've got µTorrent Server up and working fine on my Debian 5.0 box, but it dies every six hours or so. While it's running as a daemon under its own steam at the moment, I had it running in a screen session to see if I could see what was happening and every time it died it complained of a segfault.

...

Any possible solutions or logs I can hand over to ease debugging? I will add that transmission-daemon also died habitually with the same dataset (albeit less frequently – anywhere from two days to a week), although I've no idea if the problem is at all related.

The same problem. When I run it as "./utorrent" in screen session - all works fine. Previous versions works fine too.