Jump to content

mcdonald

Established Members
  • Posts

    342
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by mcdonald

  1. Despite the lack of published product updates, we've continued developing uTorrent Server for Linux. The SoShare project was using uTorrent Server for Linux, so we made some improvements based on the needs of that project. Also, one of our engineers spent a fair amount of time this year uncovering and resolving problems involving our torrent products, so I expect that you will find some performance improvements, generally and in certain edge cases; I'll report more on this once I work with that engineer to develop a list of those improvements.

    The release that's available for download is based on a code line that is roughly equivalent to the 3.3 release on other platforms. We are working on the 3.4 code line to prepare releases of numerous products, including uTorrent Server for Linux.

    Also, try accessing the web UI from a mobile device.

  2. Getting quality bug reports from people and sorting through all the duplicate/junk bug reports adds a lot of work.

    Fortunately, my experience for this product is that many of the reports are useful, and I haven't had to waste much time on unusable reports. Maybe it's because this product requires a bit more experience from the user. Some of the reports have even saved us some trouble on other products that have a larger user base.

  3. Hi I'm running utserver and think its great, I just have a few questions:

    - Is this ever expected to come out of Alpha?! Three years is a long Alpha!

    Right now it seems like a product for more experienced Linux users. I'd like to see some of the bugs resolved that not everyone sees. There isn't a whole lot of push right now to move the product further along a release cycle, even though the product continues to improve because the code it is based on is improving. I can't even say when I'll prepare another release right now because I'm working on other things. Yet, the product is built, unit tested, and system tested nightly so it stays pretty close to releasable. If I had time for a 4-day stress test on multiple platforms (32- and 64-bit, Ubuntu and Debian), I'd provide Firon with an update to post.

    - Will this ever have the remote.utorrent.com remote access capability? I have an Android phone and would love to be able to use the native app rather than a browser. I know from reading that the functionality exists, but it just needs a registration process in the gui.

    I hooked that up about a month ago as a test (it needed a little bit more than the web UI work, and somebody else updated our new web UI to provide an interface to configure this), but it hasn't been integrated into the code yet. It was about a day's work to do, but it's a matter of my scheduled priorities. It is on the management list of things-to-do, but I've lost track of the priority of that feature.

  4. 1) why an updated x86 build hadn't been posted WITH the x64 one?

    2) giving away frequent updates makes the devs work simpler: more feedback -> less work for them.

    1) It takes additional time to test additional configurations, so I didn't have the time then to run tests on the 32-bit builds.

    2) I have found this to be as you say - for example, some of the Russian uTorrent Server users who use the Cyrillic character set(s) found problems with localization in code shared with the uTorrent Mac GUI client, so by promptly working with the uTorrent Server user base (who typically has a good level of technical knowledge and ability) we were able to resolve a problem that also affected the Mac client (which has many more users than uTorrent Server) before its release. I present this sort of example when I am in project prioritization meetings. However, there are many projects here and limited resources.

  5. A non-server version would need some sort of UI. Right now there's even less likelihood of a native GUI version since there's not enough time to update the web-based server as frequently as I would like.

    I'm sorry' date=' I stop being unnecessarily snarky. How about a serious answer whether we can look forward to an updated server version in the next six months - or should we look for alternatives?[/quote']

    I don't have that answer. That decision is not up to me. Your frustration is understandable.

    However, while engineering continues to make improvements to the code shared by uTorrent Server, the Windows GUI client, the Mac client, and the embedded products, putting out an update of uTorrent Server is lower in priority. The part of that I agree with is that there is some rework of some generic code that is currently negatively affecting operation of uTorrent Server, so I'd rather not release something that still has some known problems that appear to be significant to some of the uTorrent Server user base.

    There are plans to hire additional engineering staff; I hope that will provide enough resources to stress test a new release of uTorrent Server that doesn't have the above bugs and that is tested on 32- and 64-bit Ubuntu and Debian.

  6. The really bad thing is, that right in this thread even Moderators kept confirming that development is still going on.

    But this is increasingly implausible. I would even go so far as to say it's dishonest to keep promising new versions for the community, when clearly uTorrent for Linux doesn't seem to be a priority and/or under active development.

    The Share team is using uTorrent Server as part of the Share system. I've helped them configure their servers so they get better results. There is still interest in server development, but it is lower priority than other products right now.

  7. Almost a year without updates... seriously? I was worried about the move to paid solutions and now it just confirms it - lesser projects just get cast away.

    I believe the last update (for 64-bit) was last summer, but your main point is valid that it has been a long time between updates.

    According to some posts before a lot of code is shared so it should be progressing at the same speed as other platforms but is it? I still have high CPU usage problems and outdated official webui interface. What about a non-server version?

    It is progressing because the code it shares is progressing, and it does use lots of shared code, so it not only improves but also gets caught up in new generic bugs.

    One issue is taking the time to run stress tests on a release candidate amid all the other demands for time. Another issue is there are bugs introduced since last June that are still not resolved; not a huge number, but there are some.

    A non-server version would need some sort of UI. Right now there's even less likelihood of a native GUI version since there's not enough time to update the web-based server as frequently as I would like.

  8. Wow, it's been a month since I've shown up here. I'll catch up.

    For the zombie processes issues, I'd like to give you as complete a bug report as I can come up with in the hopes that you can reproduce it.

    OK - that may help.

    exec su utserver -c "$UTHOME/utserver -configfile $UTHOME/utserver.conf -settingspath $UTHOME/config -logfile $UTHOME/logs/ut.log -daemon"

    I have one idea: do you still get zombies if you run utserver without the -daemon option?

    My utserver is running inside a 32-bit VM on my 64-bit linux box, since you recommended 32-bit linux for now (and it worked well for me since I ran uTorrent for windows the same way). I would be happy to give you the VM if it would help. It's a kvm VM and is ~2GB.

    There is a 64-bit Linux archive available on the forum (Firon posted it) - you could try that.

    The VM stores all its data on the host server via a samba share (the /fdrive that the conf file refers to is that share). Again, that's the way my windows uTorrent worked so I just carried it over to utserver.

    I think it would be better to have torrent files and data files on drives local to the VM and machine.

  9. Since the linux server shares codebase with other version is it possible to take the webui.zip from a Mac and use it on ubuntu linux installation?

    I can confirm this works; I took the webui.zip from the lastest and greatest windows build and replaced the linux one with it. This is freaking awesome!! Its like I have a new version of uTorrent since I can only use it headless on linux.

    You may find some subtle bugs or missing functionality. Right now' date=' if the Mac's webui.zip is derived from what I think it is, there is a different index.html for each product, which defines certain variables that help identify the product on which it should run, so there may be some unexpected deficiencies, but my guess is that they will be either entirely cosmetic or relatively minor.

    I can't believe how improved the UI is compared to the version shipped with the last linux build.

    The next release of uTorrent Server will have this web UI, or something roughly equivalent (with RSS support, etc.).

  10. I'd like to know if the development is still going on ... last update was at the beginning of the year !

    Development is still going on. Mostly, development is generic since uTorrent Server shares much of its code with other products. I have added some server-specific stuff as well. I have not had the time to run stress tests on a candidate build since there are other projects here. Some delay is from seeing some bugs that we later resolve, so in some ways not distributing a new release saves you from learning work arounds for new bugs.

  11. state_cmd scripts complete but are not properly handled. They execute and then become defunct processes. Since there are a lot of state changes per torrent, this can result in a lot of defunct processes laying around.

    If this bug could be put on list to fix, that'd be great.

    It's not a matter of putting this bug on a list. If I could reproduce it, I could work on it. I try what others try, but I don't see the zombies.

  12. I think something wrong with automatic disk cache

    I believe that one's been handled; it may be fixed in the 64-bit build (of course that won't help if you run 32-bit). I've just got to get some time to go through the release process. Although, we are currently working on some bugs that would also affect uTorrent Server, so I'm not in a hurry about releasing before resolving those issues.

  13. When will there be a new build?

    I was hoping by the end of September, but that's gone by. I've recently updated the web UI with something newer developed by a web engineer here. It looks like another engineer will be working on the problems with local peer discovery starting within the next week, so I'd like to wait for that, but I may start a test run soon if that work will take longer.

  14. Reply here if you want me to find any more details in order find the bugs...

    Try setting logmask: 0xffffffff in the configuration file, then run the program again until crash, then submit the log messages that you see (hopefully they will indicate something interesting) together with the contents of your configuration file.

    Also, in the future, I'd prefer if you submitted problem reports to the troubleshooting section of the uTorrent Linux area of the forum.

  15. Hello! What a very long time has not been updated uTorrent for Linux, the project still alive?

    It is still alive. I prepared 64-bit builds for Ubuntu and Debian a couple of months or so ago. I just checked the download page, and they are not there; I think Firon posted them to the forum.

    Since the server product uses much code shared with other uTorrent products, it has progressed as have the other products. Every night, the server product is built, unit-tested, and system-tested. I've been working on other products recently; I hope to have a server update within a month that will include a number of bug fixes.

  16. Have a problem with this release (didn't try any previous) - if file in torrent contains cyrillic letters' date=' the file name ([b']on disk! not in webUI) looks like ??????????????.mkv and so on.

    yes I have the same problem

    server starts kakchat file with the Russian name the torrent, but then after a reboot an error about a file named ??????????. avi incorrect

    This is on the most recent 64-bit release?

    What locale does uTorrent Server report in the first line sent to standard output?

  17. The files tab doesn't update as fast as the torrent list. Are you sure it isn't updating at all?

    You might try different webui builds to see if the JS error goes away. Seems like that is a new error.

    I recently put in a fix to have the files tab update more often. It was only reading the files list when the files tab was first displayed, then it would not update. Although, there's a new web UI developed here that will probably get included in the next release.

  18. I tried to utilized the "Run program when a torrent finishes" in uTorrent Server (latest) for Linux.

    I have Twidge installed. It's a command line twitter client.

    twidge update "%F has finished downloading."

    Executing: twidge update "Star.Wars.The.Clone.Wars.S03E16.Altar.of.Mortis.HDTV.XviD-FQM.avi has finished downloading."

    So I know for sure that the line of command has been executed, but there is no status update on the twitter page!

    What went wrong?

    The message you report shows that uTorrent Server recognizes it needs to run that program as you have registered it, and is attempting to run it at that time. That doesn't mean that the program ran successfully, or even that uTorrent Server found the program. Unfortunately, there isn't a good way for the application to log failures for this operation. However, you can set up logging yourself. You could set up a shell script file that generates output to a log file, redirecting standard output and standard error of the twidge program to that log file, and run that shell script instead of running twidge directly.

    I'm suspecting that all you need to do is to provide the full path to the executable, instead of just twidge. uTorrent Server runs exactly the command you provide; it doesn't run the command in a shell, so there's no which command lookup functionality available to find the executable referred to in the command.

    On another topic, I'm not sure why people post trouble reports to the announcement forum instead of the troubleshooting forum. I think it would be more useful to post in the troubleshooting forum, since that would organize the posts for later searches, and leave this forum just for announcements and questions about announcements.

  19. New build up!

    You may find that this build has faster download speed. I found that to be the case when stress testing the release (frequently seeing 35 MB/sec download rates when using 4 seed computers in a gigabit Ethernet LAN). Engineers here have a theory that recent fixes to piece caching improved performance. Although, you'd need a substantial Internet connection to see that rate outside of a LAN. Hopefully, the faster download speed means more efficient downloading, which would likely mean less CPU usage, which would benefit users regardless of Internet bandwidth.

×
×
  • Create New...