mcdonald

Established Members
  • Content count

    339
  • Joined

  • Last visited

  • Days Won

    1

mcdonald last won the day on September 23 2015

mcdonald had the most liked content!

Community Reputation

3 Neutral

About mcdonald

  • Rank
    Software Developer

Profile Information

  • Gender
    Not Telling
  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. 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. 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. 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) 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. 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 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. 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. 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. OK - that may help. I have one idea: do you still get zombies if you run utserver without the -daemon option? There is a 64-bit Linux archive available on the forum (Firon posted it) - you could try that. I think it would be better to have torrent files and data files on drives local to the VM and machine.
  9. 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. The next release of uTorrent Server will have this web UI, or something roughly equivalent (with RSS support, etc.).
  10. 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. 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 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. Can you try recording the current value of bt.transp_disposition, then setting bt.transp_disposition to 5, and see if you still see slow seeding?
  14. Can you provide a reference to a torrent file for which this occurs?
  15. Is anybody seeing slow seeding in uTorrent Server, either via uTP or TCP? Slow, as in 5-20 KB/sec.