Since long lime I've been searching for a working torrent client for AmigaOS/MorphOS. As fas as I know there is now 3 solutions: ctorrent port, BitTorrent port by Tokai, and mlDonkey (which can download torrent files too). I've tried all of them, and I was very disappointed. CTorrent crashes every time (there are such versions, which even can't download anything at me), BitTorrent can't resume files, it's very-very-very slow and eats a lot of CPU time, and well, mlDonkey.. I think, it's not a torrent 'client' at all (viewing the status of a download with a browser? No, thanks).

I feel it's time to ask the question: Is it my own problem or are we many enough to create a new bounty to solve this problem.

I think we need the following things:
- Porting some stable and reliable torrent engine (maybe rtorrent's libTorrent would be good)
- Creating a working, user-friendly MUI GUI for it. No browser frontend, no ncurses ugly-gui-like-thingy, MUI GUI with lots of informations (displaying seeders, peers, adjustable transfer rates for every peer, status of the files in the torrent, and many features).

The goal is to create a client which is at least as powerful as BitsOnWheels on OSX or µtorrent on Windows.

I'm waiting for your opinion on this topic.

User friendly (nice, useful MUI GUI) and quite fast (faster and less cpu/ram hungry than current bittorrent port based on python) torrent client would be nice. One thing I would like to see in the feature list - trackerless support.

Quote:
Umm, why does it need to "be a torrent client" as long as it can download torrents?

You can (sort of) imitate the look of btdownloadcurses (bittorrent client) by using mldonkey via its telnet interface instead of the "more eyecandy" browser interface.

My opinion:
mldonkey still loads most torrents without problems. Most of the time there's no need for any GUI at all, and it can "just work in the background". If you need to see the status, you can either 1) Use browser interface. 2) use Telnet interface. 3) Check incoming drawer for completed files.

bittorrent client: It can resume transfers (unlike what you say) but resuming files "faster than it takes to restart entire download" it requires you to set HOME. I think that's explained in other threads.

Yes, the hashing files is EXTREMELY slow (like I said, usually it's faster to re-download the entire file, no matter how many hundreds of megabytes it is) and checking downloaded segments is slow too. I'm not sure, but I guess that problem might be "MOS<1.5 specific" as some people (most specifically those behind the port) don't have those problems.

imho, instead of this bounty, a better choice would be a bounty for MUI GUI for mldonkey. It has a separate interface for GUI (like it has for browser and telnet) - it's just that no-one has yet written a MUI GUI for it. There is a GUI for old version, that uses Telnet interface (for some weird reason) but the bad thing is that, it doesn't work on any of the newer versions anymore...

@gk_lka:

the bittorrent port is by CISC, the mld port is by me.

anyway.. I cant speak for BitTorrent (i only tried it once when CISC ported it for the first time and that time it worked fine for me ;)

MLD works fine for torrents if you follow the readme properly. Well.. and ctorrent is a bad joke IMHO (i only made a port to prove its easy to port back then... maybe it improved in the meantime, dunno ;)

Anyway.. i personaly see no problem to use the WebUI or the TelnetUI of MLD. Usually I leech my stuff with Azureus these days on my Mac. And I control/ check Azureus status very often with its WebUI plugin too (and Azureus has a quite usable/ complex GUI itself).

In the end it counts if you get the file downloaded or not... and IMHO mld is not bad choice here.



But if you think it's worth to waste money for some pointless extra eyecandy... I'll not stop you. ;)

@tokai:

Sorry for the mistake, I've thought that you created the port, because I've found it on your home page. :)

@Jupp3:

Tryed to set up BitTorrent a hundred times, and I have used it on Linux: The linux and MOS versions are very far from eachother. The linux-one is quite fast, works fine, but the MOS one has always the problems. (And now I didn't mentioned that it needs MOS SDK, and a lots of useless unix-ish configuration.)

About your other idea: You (?) have already told that in an another topic, and this time I can say the same (as fas as I remember, what have I said last time): I think mlDonkey web interfase is worse than terrible, telnet interface is only useful when you are not at your computer - but if we had a correct, integrated, not-hacked, usable GUI for it, it came maybe a usable client for me.

But I'm still not sure what things mldonkey's torrent client does support (e.g. what I've mentioned in my first post).

@tokai:

Well, it's worth me some money ;) (I don't have Azuerus and an another computer dedicated to download files :))

yes, 100% agreed! we need a decent torrent client, like the ones on win/osx.

no need to dirty tricks and ugly workarounds to dl a single torrent! other systems have plenty of nice, configurable torrent clients - why dont we?

i know, lots of mos users are devs/heavy users who dont care about gui and elegancy of an app, and use shell happily, but hey, there are some normal users on the morphos front and we want to do things simply and elegant way - as it can be done ot win or osx.

personaly i use my winbox mostly for dowloading torrents - coz mos doesnt have a normal torrent client. i've tried ctorrent, with success, but it doesnt have a gui and not configurable. its a pain to use and opens ugly shell windows (yes, i dont like shell too much:)

if mos want to be a serious/usable desktop platform it needs apps that normal users/begginers can use without dirty shell tricks.

bounty for a MUI GUI torrent client! (utorrent cant be ported for example?)

thx

@GK_LKA

have you tryed with different TCP/IP stack?

Quote:
-
i know, lots of mos users are devs/heavy users who dont care about gui and elegancy of an app, and use shell happily, but hey, there are some normal users on the morphos front and we want to do things simply and elegant way - as it can be done ot win or osx.
-

Damn right MOS-users aren't dependent on GUIs, that *is* part of the reason we use MOS in the first place. We're not "normal" users. Normal users use platforms with modern core features (memory protection, vmem++), free modern web-browsers, office suites, decent cd/dvd-burning software, etc etc.

Don't get me wrong, I love MOS, and it is my primary OS. But I am *not* a normal computer user. I am a nerd/geek/hobbyist/whatever. I don't use my computer just to "get things done". If I was, I'd have used a Mac or a PC.

As for the whole torrent-client-debate, I agree with Jupp3, a decent GUI for mldonkey would be the smartest and easiest way to go. It would also be of great use to us *real* users that has an old Intel-box running Linux and mldonkey as a 24/7 slave. :) For me, MOS crashes and hangs a bit to often to be good as a p2p-slave.

I use bittorrent since its release.
It is the first usable client, in my opinion.
It is very easy to use, works fast, does not eat the cpu and can resume.
And of course hashing is very fast.

The conclusion is your setup could be misconfigured/broken ;-)


[ Edited by Henes on 2006/7/27 14:26 ]

I'm not much of a torrent user myself (in the US the MPAA and RIAA like to go after people on it and I dont feel like getting busted) but the ones out do work well. The official one is fast here for me, it just depends on the number of seeders and the ammount of bandwith they have given for the file.

Quote:
Could it also be that YOUR setup has a newer MorphOS system with more stabile TCP/IP and stuff?

Oh, and about bittorrent client...
The archive comes with "btlaunchmanycurses". Just launch it somewhere. You can hide the shell window if you want. Then it's just a matter of copying .torrent files to the same drawer, and the download will automatically begin in a while. After the download is finished (and you've seeded enough), you can just delete the .torrent file, and the seeding will be stopped.

Of course this doesn't cure the other problems we "normal mortal 1.4.5 users" have (such as extremely slow hashing, general unstability, network transfer corruption (if someone is still using MiamiDX, I'm not)) but that way you don't have to write "bittorrentcurses file.torrent" in shell, as it seems to be too hard

Well, the slow hash issue could very well be caused by improper filesystem/dos settings (or massive fragmentation :-).

For the rest... I guess lame tcp/ip stacks are at cause (mine also fucks up if I launch too many downloads at the same time but it's not a problem once you know the limit).
I heard there are workarounds for miamidx, though.


[ Edited by Henes on 2006/7/27 16:26 ]

Quote:
I know. It's called MosNet. It's also rumoured that MorphOS 1.5 has a better workaround built-in

Well, just wanted to point out one potential couse of problems... And as it can be already fixed, why not? I did.

Yes, I have tried MOSNet 1.2, but - as I remember - ctorrent didn't downloaded anything at all. I have read all the documentation (more than once), asked people here, in forums, and the best I got was "It is working for me". No, it is not working. Look at etc. AmiNetRadio: I download it, unpack, click on it's icon - and IT'S working. That's what a normal user - you mentioned - wants.

BTW: I think the same as mikeri: We, MOS users are not simple "normal" users. I use shell very often, and I love it - but when I download a file, I want to download it with GUI (with many pretty jumping and moving gauges, statistics, etc.). Look at AmiTradeCenter: In this case would you use the commandline "ftp" command instead of ATC? Isn't it much better? :)

GK_LKA

Hi. First off, MOSnet may be your problem...

and to my experiences with torrent clients on MOS

ctorrent: worked best for me, no probs go a few big isos with it... just shell but whatever

mldonkey: hacky, worked but slow as hell, used telnet interface and web interface but think they are broken now?

bittorrent: tried to use it but it wouldnt work - library errors or something i dont remember, read the docs, but were not clear.

btw I was using MIami dx never tried with mosnet

I am agreed with alot of ppl in the thread, a GUI client is needed, whatever client doesnt matter as long as it has a GUI and it works. Most users are Amiga guys not linux guys and probably despise the shell ( i like it but..)
With all these genius developers it shouldnt be a problem..

A bounty may help out to get it done for sure as they guys who are capable of doing it dont need a gui
magnetic

"Most users are Amiga guys not linux guys and probably despise the shell "

yeah, thats the point!:)
i like the option of shell, i like to use it when its needed, but amiga is about gui, isnt it?

well, lets make a bounty for a torrent client gui as GK_LKA mentioned! its a good idea:)

GK: ctorrent is working for me too. i've dl-ed several hundreds of mb's (or even gb) of data when my winbox was dead for a few weeks, but i've tried 2 or 3 versions of it and had to ask help from the author - but its working now (with good speed and with miamidx).

@saddam:

Believe me, I've tried everything, and it's not working for me. (If you know some magic - then I try it with pleasure ;)) Please don't misunderstand me: I could download lots of GB's (maybe over 50) with it, but it crashes very often, especially when there are many peers connected or the speed is very fast (in the student's hostel I have full 100Mbit access, and torrents came often with 4-5MB/s (I think it's the limitation of the emulated MiamiDX stack)). There were days when it ran a whole day, but there were others when it crashed in every 5 minutes. And when it crashes, the whole system crashes, thanks to the lack of memory protection in MOS... :(

About shell: I think I've found the difference between Amiga- and Linux-people. Both are loving shell, but for different things: The Amiga people run programs and do file operations from it - but linux people also use the programs in the terminal. That's about what we say it's unconfortable and ugly :)

And when talking about p2p/torrent GUIs, what happened to AmiGIFT? It seemed like a nice project but was halted back in 2004 if I remember correctly? It worked with the MOS-port of mldonkey and was therefore capable of downloading torrents.

To repeat myself, I'd vote for a mldonkey GUI.

Well somebody submit the bounty and i'm sure somone will take it!

magnetic

@mikeri

Hm... I've never heard of AmiGIFT, but now I looked after on Google:
http://sourceforge.net/forum/forum.php?forum_id=592410
The page is updated this month (as also the program). I have downloaded it and will test.

Quote:
Hi. I know what Amigift and mldonkey are but i don't understand what you mean by "amigift is working with mldonkey and was therefore capable of downloading torrents". Can you please explain?

After reading the documentation I can say the two program is similar, because both of them can download from multiple networks, but that's all. I think they don't work together... :)

So.. AmiGIFT is a promising project. Unfortunately I couldn't try it out, because I don't know any of the networks what it supports, but I think writing a torrent plugin for AmiGIFT would be the best choice. There is also a MUI GUI (I think it supports almost everything we need), and it's also supporting more networks, as some of you needed. Well, what about a bounty for "Writing a new torrent client with mui gui OR writing a plugin for AmiGIFT?" Do we need this way a bounty for this at all?

I think we shall ask the authors first, is it possible to write the plugin or not. (But I think if there is AmiNET plugin too, it IS possible.)

To clear things up a bit, giFT is a cross-platform suite of p2p-clients that boasts a standardized GUI protocol, making it easy for third parties to make different GUIs for it. Mldonkey supports the giFT GUI protocol, hence the possibility to use the AmiGIFT GUI to control mldonkey, both locally and remotely.

I know this works (somewhat buggy), because I used it myself.

However, mldonkey also has it's own GUI protocol that supports some options the giFT protocol doesn't. For a capabable coder experienced with MUI, I'd imagine a good GUI for mldonkey could be done in a relatively short time.

[ Edited by mikeri on 2006/7/29 3:34 ]

the Amigift GUI (giFTMui) has been written from scratch by the author of Amigift (Diego Casorran).

Sorry but i don't follow your statement about the compatibility between Amigift amd Mldonkey.

Ah and yes.... a torrent Plugin is WIP for Amigift. (not available atm)

As soon as the sources of the docs about the daemon and available plugins will be released (NOT of the GUI) everyone will be free to write all the plugins he wants.

[ Edited by Framiga on 2006/7/29 11:12 ]

I'm repeating myself in multiples here.

I know the GUI is written from scratch, but it's still using the giFT GUI-protocol.

The giFT suite uses a *standardized GUI protcol*. This protocol is supported by mldonkey, as can be read here. (Search for gift on the page.) As AmiGIFT uses this protocol, it is possible to use the GUI included in AmiGIFT to control both local and remote mldonkeys. Again, I have done it myself.

How to do it? Fire up the GUI without launching the deamon and point the GUI to your running mldonkey using the IP settings. Should be quite simple. I can not guarantee that this will work on the newest version, since I haven't tried it myself yet.

[Update: I tried it just now, and some of the communication between mldonkey and giFTMui seems the be broken, both search results and transfer info are totally bullocks. On the more happy side, there is a Torrent-assistant visible (but grayed out) in the new giFTMui, hopefully a thing to come.]

As for the whole torrent-downloading-thing, I might have gone a little overboard in my statements, as there does not seem to be a way to send direct commands via giFT(Mui). This means giFTMui was only good for monitoring torrent transfers, not starting them.

I hope I explained myself well enough this time.

[ Edited by mikeri on 2006/7/29 13:39 ]