Version: (using KDE 4.3.3) Installed from: openSUSE RPMs Please add support for the magnet: URI scheme, a draft open standard defining a URI scheme for magnet links, which are mainly used to reference resources available for download via peer-to-peer networks. This URI scheme is supported by other popular BitTorrent clients. The standard seems to have been stable since 2002. Standard specification: http://magnet-uri.sourceforge.net/ Wikipedia: http://en.wikipedia.org/wiki/Magnet_URI_scheme See also related Bug 87074 (for Konqueror).
Several popular trackers are now moving to magnet links...
*** This bug has been confirmed by popular vote. ***
Will be needed much soon, since TPB moved to magnet-only way.
TPB isn't magnet-only (yet) e.g. http://thepiratebay.org/search/foo/0/99/0
i vote for this one too :-)
DHT is used by many that I know of so this would be a useful/necessary addition/fix. ;)
DHT is not the same as magnet URI support. In fact, I'm fairly sure Ktorrent already supports DHT (at least, it says 'DHT <num>' at the bottom). If you have problems with DHT, please log a different bug.
If DHT support is strangely missing then you are probably using official SUSE packages. SUSE disables DHT when they build ktorrent packages.
(In reply to comment #8) > If DHT support is strangely missing then you are probably using official SUSE > packages. SUSE disables DHT when they build ktorrent packages. Yes I had DHT not working when was using opensuse 10.3. Interesting why they disable?
Badly worded by me I see.(-:( Ktorrent, at least my copy, has DHT and I find it valuable. Just like the rest of the program really. A recently noticed trend towards tracker-less torrents with magnet links containing the relevant info to enable P2P operation is what prompted my initial message.
They disable it for legal reasons: https://bugzilla.novell.com/show_bug.cgi?id=205390 Anyway I'm currently working on magnet support, and hope to finish it pretty soon.
We've just reenabled it in the build service 3.3.1 rpms, following changed legal advice that DHT is safe to distribute as long as we add a notice explaining that copyright should be respected.
Created attachment 38565 [details] KTip about copyright Can we get this upstream? Then it will be translated.
(In reply to comment #13) > Created an attachment (id=38565) [details] > KTip about copyright > > Can we get this upstream? Then it will be translated. Why infect KTorrent proper with the legal paranoia of a single distributor? I'd prefer my KDE applications not to preach to me about how I choose to use them. That patch should remain downstream for whomever thinks they can get away with annoying their users.
I'm willing to include that patch, but only if it is a compile time option, and disabled by default. I have a great dislike for tip dialogs, nor do I care much for the legal paranoia at SUSE. However I will probably get a bug report one day that this is not translated, so it would be better to include it. Strange though, the pirate bay switches to magnet links, and suddenly the lawyers at SUSE change their mind.
(In reply to comment #15) > I'm willing to include that patch, but only if it is a compile time option, and > disabled by default. That's a more reasonable idea. For Exherbo's packaging of KTorrent at least, it'd be no trouble to add an option flag allowing users to toggle that at compile time.
SVN commit 1058967 by guisson: - DHT can no longer be disabled at compile time - Add support for magnet URL's BUG: 214375 M +0 -11 CMakeLists.txt M +2 -0 ChangeLog M +7 -3 ktorrent/CMakeLists.txt M +79 -10 ktorrent/core.cpp M +15 -0 ktorrent/core.h M +3 -3 ktorrent/gui.cpp AM ktorrent/icons/hi16-action-kt-magnet.png AM ktorrent/icons/hi22-action-kt-magnet.png AM ktorrent/icons/hi32-action-kt-magnet.png AM ktorrent/icons/hi48-action-kt-magnet.png AM ktorrent/icons/hi64-action-kt-magnet.png AM ktorrent/icons/hisc-action-kt-magnet.svgz M +3 -0 ktorrent/ktorrent.notifyrc M +2 -1 ktorrent/ktorrentui.rc M +0 -5 ktorrent/pref/btpref.cpp D ktorrent/queuemanagermodel.cpp D ktorrent/queuemanagermodel.h D ktorrent/queuemanagerwidget.cpp D ktorrent/queuemanagerwidget.h D ktorrent/queuemanagerwidget.ui A ktorrent/tools (directory) A ktorrent/tools/magnetmodel.cpp [License: GPL (v2+)] A ktorrent/tools/magnetmodel.h [License: GPL (v2+)] A ktorrent/tools/magnetview.cpp [License: GPL (v2+)] A ktorrent/tools/magnetview.h [License: GPL (v2+)] A ktorrent/tools/queuemanagermodel.cpp ktorrent/queuemanagermodel.cpp#1057208 [License: GPL (v2+)] A ktorrent/tools/queuemanagermodel.h ktorrent/queuemanagermodel.h#1057208 [License: GPL (v2+)] A ktorrent/tools/queuemanagerwidget.cpp ktorrent/queuemanagerwidget.cpp#1057208 [License: GPL (v2+)] A ktorrent/tools/queuemanagerwidget.h ktorrent/queuemanagerwidget.h#1057208 [License: GPL (v2+)] A ktorrent/tools/queuemanagerwidget.ui ktorrent/queuemanagerwidget.ui#1057208 M +8 -1 ktorrent/torrentactivity.cpp M +2 -0 ktorrent/torrentactivity.h M +10 -0 ktorrent/trayicon.cpp M +6 -0 ktorrent/trayicon.h M +44 -1 libbtcore/magnet/magnetdownloader.cpp M +12 -1 libbtcore/magnet/magnetdownloader.h M +0 -2 libbtcore/torrent/torrentcontrol.cpp M +6 -0 libktcore/interfaces/coreinterface.h M +0 -2 libktcore/interfaces/functions.cpp M +1 -2 plugins/webinterface/actionhandler.cpp M +0 -4 plugins/webinterface/globaldatagenerator.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1058967
So, which release is this going into?
I would humbly suggest it would be an important feature for the upcoming 4.4 release...
(In reply to comment #19) > I would humbly suggest it would be an important feature for the upcoming 4.4 > release... Do u mean 3.4 ?
The next feature release is 4.0, 3.4 will never exist.
I'm currently running 4.3 so it was selfish in a way :-) 4.4 is due for beta very soon (if not already).
ktorrent is not on the same release schedule as KDE
Sounds like this means it can be delivered even sooner - Great ! Lets get a new release with this increasingly important feature out there then, and KDE (etc) can package it up when they next do a release.