Free torrent software for linux

Torrent Swapper is an open sourced sociable peer to peer file-sharing client based on the Bittorrent protocol that is ideal for high-speed distribution of large files that has a basic understanding of human friendships, of user tastes in content, and of Internet connectivity between users.
Torrent Swapper project supports simultaneous downloads, download queue, selected downloads in torrent package, fast-resume, speed limits, port mapping, disk cache, proxy, ip-filter, etc.
Main features:
- Amazon-like recommendations to get interesting files
- Doubling the download speed by using the upload capacity of friends
- Real-time P2P file sharing with P2P video streaming
- Showing the locations of seeders / leechers of the same content with city-level accuracy on a world map
- Multiple downloads in a single window
- Queueing system with priority
- Supporing pause, stop, resume, queue, remove operations
- Supporting global setting such as upload and download limiting
- Supporting local setting for each torrent as well
- And much more...

cfv is a utility to both test and create .sfv, .csv, .crc, .md5(sfv-like), md5sum, bsd md5, sha1sum, and .torrent files. These files are commonly used to ensure the correct retrieval or storage of data.
cfv is written in python, and as such should run on all platforms python supports. Currently, it has been verified to work on linux, freebsd, openbsd, netbsd, solaris, macosx, and windows.
Main features:
- supports testing and creating of .sfv, .csv(2, 3, and 4 field variants), .crc, sfvmd5(sfv file using md5 instead of crc32), md5sum, bsd md5, sha1sum, and BitTorrent file formats
- test-only support for PAR and PAR2 files
- automatic checksum file naming ability in create mode
- recursive operation
- show unverified files option
- ignore case and fix path seperator options for cross platform use
- transparent gzip support for checksum files
- configurable renaming of bad files (with testing against previous bad files, to save only unique differing copies)
- searching for/fixing of misnamed files
- raw listing of files of specified type (bad, missing, etc)
- test suite to ensure correct operation

Torrentocracy (pronounced like the word democracy) is the combination of RSS, bit torrent, your television and your remote control. In effect, it is what gives any properly motivated person or entity the ability to have their own TV station.

By running torrentocracy on a computer connected to your television, you not only become a viewer of any available content from the internet, but you also become a part of a vast grass roots media distribution network.

This is not about the illegal distribution of media, but rather its about enabling an entirely new way to receive the video which you watch on your TV.

If you ever wondered how and when your computer, the internet and your television would merge into one seemless device with access to anything and everything, then at this very moment the theme song from 2001: A Space Odyssey ("Also Sprach Zarathustra") should be resounding through your head.

SDB is an utility for traders to manage a collection of live shows.
SDB is an utility for traders to manage a collection of live shows. It currently features various export formats (txt, html) and a gui to browse, add, edit your shows.
Main features:
Currently implemented features
- runs on Linux and Windows (should even run on MacOS, but I cant test this...)
- export options:
- HTML
- plain text
- PHP
- XML
Open tasks
- create lists of shows you dont have (ISO)
- import your lists in various formats (etrees CSV format)
- additional export formats (PDF/PS/DVI, CSV for etree.org)
- BitTorrent features (create .torrent files from your data)

FoxTorrent is a Firefox extension that lets you stream torrents as they download, from your web browser, with zero configuration needed.
Main features:
Streaming Fast Delivery
- Watch video and listen to audio as it downloads.
Complete Firefox Integration
- Manage your torrent downloads from your browser window.
Windows, Mac, and Ubuntu Linux
- Consistent downloading experience across all three platforms.
Background Downloading
- Continues to work even after your browser window has been closed.
Low Resource Footprint
- Foxtorrent uses less than 8 MB of RAM, and doesnt hog bandwidth.
Configuration-Free
- Automatic support for NATs, uPNP, and firewalls, with no tinkering necessary.

Armangils vodcatcher is a video podcast (or vodcast) client for the command line. Armangils vodcatcher project provides several download strategies (new shows only, allowed, back-catalog, etc), supports BitTorrent, offers cache management, and generates playlists for video player applications. It is written in Ruby, and runs on Linux (tested), Windows, MacOS and many other operating systems.

To watch video podcasts, simply type something like vodcatcher subscriptions.opml > latest.m3u. This will download the subscribed shows into the current directory and generate an M3U playlist named latest.m3u.

This application accepts one or more feeds (RSS or Atom) or subscription lists (OPML or iTunes PCAST) as argument, in the form of URLs or filenames. Alternatively, it tries to read one such document from the standard input.

For help, use vodcatcher -h.

Options:

-F, --Function FUNCTION used function (download search );
when using the search function (which
generates an OPML document), the only
relevant options are -v, -r and -f
(default value: download)

-d, --dir DIR Query for caching files
and storing application state
(default value: current directory)

-s, --size SIZE Size of media file cache in MB;
0 means infinite; default value is 500

-m, --memsize N Remember last N downloaded media files,
and do not download them again;
0 means infinite; default value is 1000

-t, --type TYPE Playlist type (m3u smil pls asx tox xspf )
(default value: m3u)

-S, --strategy S Strategy to use for downloading vodcasts
(new one back_catalog all cache ):
* back_catalog: download any show that
has not been downloaded before; prefer
the most recent shows of top-most feeds
in the OPML/PCAST documents.
* new: ignore vodcast back-catalogs; this
is like back_catalog, except that only the
most recent show of each feed is
considered.
* one: download one unlistened show of
each feed, with a preference for recent
shows
* all: download all show; even already
downloaded shows are downloaded once
again.
* cache: play shows that are already in
cache (default value: new)

-f, --feeds N Do not download more than N feeds
(when using the download function);
or return the first N relevant feeds
(when using the search function);
0 means no limits (default value: 1000)

-r, --retries N Try downloading files (media, RSS/Atom or
or OPML/PCAST) at most N times before
giving up (default value: 1)

-T, --Torrentdir DIR Copy torrent files to directory DIR;
handling torrents through an external
BitTorrent client is left to the user;
if this option is not used, torrents are
handled internally (if RubyTorrent is
installed), or else ignored

-U, --Uploadrate N Maximum upload rate (kilobytes per second)
for the internal BitTorrent client
(default: no limit)

-i, --itemsize N If a downloaded show is less than N MB in
size (where N is an integer), fetch other
shows of that same feed until this size is
reached (default: 0)

-p, --[no-]perfeed Create one subfolder per feed in cache

-c, --[no-]cache Play already cached files,
DEPRECATED (use -S cache)

-e, --[no-]empty Delete all previously downloaded
files

-a, --[no-]asif Do not download media files
(useful for testing)

-v, --[no-]verbose Run verbosely

--version Display current version

-h, --help Show this message

Usage examples:

vodcatcher -d ~/vodcasts feeds.opml http://host/second.opml > latest.m3u

vodcatcher -d ~/vodcasts -S cache > cache.m3u

cat feeds.opml | vodcatcher -d ~/vodcasts > latest.m3u

vodcatcher -vd ~/vodcasts -s 500 -m 10_000 -t asx feeds.opml > latest.asx

vodcatcher -vF search -f 44 video vlog http://www.podfeed.net/opml/directory.opml > results.opml

Hydranode Core is a modular, plugin-driven peer-to-peer client framework which is designed with true multi-network downloads in mind.
Hydranode Project can be used directly via the built-in shell functionality, or via external user interfaces.
To achieve the large number of features described in the previous section, HydraNode core needs to be extendible without causing feature bloat and increase in system requirements resulting from that. The only way to accomplish that is make the application completely modular - only a minimum set of features are provided by the core application; the rest of the features are implemented by optional loadable modules. Each file-sharing network should be in a separate module, as should be other additional features like e-mail notifications. With this design, the features are de-coupled from each other, thus greatly simplifying the debugging process, and allowing end user to select only the features he or she needs instead of what a programmer thought was best for him or her.
Second most important pre-requisite for a modern peer-to-peer application is platform-independence. The biggest differences in platforms are the graphical user interfaces, while the underlying structure of operating systems is rather similar. To achieve maximum portability, the core application should be decoupled from graphical user interfaces, which then could be written platform-dependently for each target platform; native user interfaces always perform better than interfaces designed for running on large number of platforms. To achieve this, the core application should not have any interactive graphical user interface of its own at all - it should only provide a protocol through which native graphical user interfaces and other application could communicate with it and control it. The protocol itself should be in human-readable format, but also be easily parse-able for client software; the reason for this would be to allow the possibility of interacting with the protocol directly through simple software like telnet, which would greatly simplify debugging process, but could also be useful even for end users as a crude remote control mechanism.
Related to the above comes the question of programming language to use for writing the core application. At this, C++ would be the most sensible choice, because it is widely used across all platforms and provides fastest code (which is required to achieve low system requirements); it allows (and even enforces) object-oriented design, and is easier to understand than C code. Additionally, since HydraNode strongly relies on module-writers, C++ coders are far easier to find than, say, Java coders.
As mentioned in previous section, quickest way to rapid development process is to give the users free access to the source code of the application; it increases possible developer/debugger-base significantly. Out of the myriad of open source licenses out there, GNU General Public License is most respected among users and developers, so HydraNode source code should follow the trend and be licensed under GNU GPL. Having the source code licensed under GNU GPL also allows us to use the almost infinite amount of existing code freely available through the internet, which could prove as a very useful option.
With the fore-seeable future of large number of co-developer base, it is necessary to clearly define the coding standards for the core application. Coding style is very personal; having large number of developers modifying the code will quickly lead to a mix of different styles and personalities, which in turn makes the code less readable, and thus less maintainable. There are several widely accepted coding standards floating around, and for this project we have chosen to use Linux Kernel coding standard; while originally written for C, the concepts still mostly hold for C++. Source code, however, is worth nothing without correct documentation which would give the future co-developers hints on what the original developers had in mind while writing/designing the application. Again, there several widely accepted documentation standards, out of which perhaps the most common is Doxygen-style. The reason behind this is that Doxygen is capable of extracting documentation from source files and generating web pages out of it, which can give a very quick and extensive overview of the entire application at a glance - something future developers will greatly appreciate.
The privacy of the user should be a serious concern for any modern peer-to-peer application developer; there are several institutions which tend to have a habit of spying upon the users and invading their privacy. The simplest solution would be to block the IP addresses of those groups; even better solution would be to simply stay off their radar. The first part can be implemented within the core application since it controls the low-level networking functionality; second part can be implemented by networking plugins depending on the specific networks.
Since the core application will eventually have a large number of very different networking plugins, we have the problem of bandwidth management. The end user shouldnt be bothered with each specific plugins bandwidth limiting settings, so the bandwidth limits should be managed by the main application, which in turn could either allow or deny requests for bandwidth to modules. This setting should be fully configurable, allowing end user to either have the bandwidth shared equally among the plugins, or in favor of one or several specific plugins.
Various file-sharing networks use very different files identifying methods - most often this is a checksum of the file, sometimes accompanied by file size; additionally, there is files meta-data, which can help the end-user identify the file. Since this feature is common to all file-sharing networks, while only differing in the actual checksum used, it should also be handled by the core application. Several points must be considered here - the core application should be able to generate a large number of checksums and store them. It should also be capable of extracting meta-data of files, as well as do cross-references with checksums - given a checksum from one network, it should be able to find the same file on second network (provided the file is known). However, no single client can know the checksums of all files of all networks, which means that the cross-referencing functionality will be of little use locally - this needs a central database which could store the checksums of all files from all networks, and provide cross-referencing functionality. Heres where Myradin comes in - it does exactly that. While support for Myradin shouldnt be completely integrated since it isnt really a part of the application, it could be an optional plugin that retrieves and submits checksums to the central database.
The last feature is far more important than is obvious on first impression; this is the feature that will eventually allow real multi-network simultaneous downloads of same file. The problem is - since each network uses different checksums for files, it is impossible to identify the same file on two separate networks - you dont know the file is the same until you have downloaded the entire file and generated a checksum out of it. However, with a central database which stores checksums of different files from multiple networks, it would be possible to retrieve the checksums of a file on all other networks provided you have the checksum of a file from one network, thus allowing downloading the same file from two or more networks simultaneously. Upon completition, files actual checksum could again be tested against all known checksums to provide even higher corruption protection than single-network downloads. The central database would also contain files meta-data, which would allow end-users to more clearly identify fake files, thus improving the overall quality of files on all file-sharing networks.
Enhancements:
Graphical User Interface (NEW) (madcat)
- Supports search, download and shared files lists
- Lists loaded modules
- Shows networking statistics
- Lists eDonkey2000 server list
Core/GUI communication (NEW) (madcat)
- Supports networking, files, modules and custom data syncronization with user interface(s).
Hydranode Base (madcat)
- No longer writes ANSI color codes to logfile
- Portability to platforms without stdint.h header
- Portability to unix variants without execinfo.h header
- Full support windows XP Service Pack 2 (half-open connections limiting)
- Using hand-crafted event multiplexing system in sockets to bypass the slow Boost.Signals
- Fixed issues with >2GB files on Windows
- Fixed issues with UDP packets handling when multiple packets arrive with short interval (previously this caused the socket to become dead)
- Support for more than 64 concurrent open connections on Windows
- Handles some race conditions in networking, where events come from backend when frontend has been destroyed more gracefully
- Now remembering total downloaded/uploaded/uptime across sessions (global)
Hydranode Core (madcat)
- No longer allocates disk space when shutting down
- Cleans up filename of invalid characters when starting downloads
- Fixed uploading issues while moving completed download to incoming
- Uploaded amount (for shared files) is now properly stored across sessions
- Avoids duplicate scanning of already-scanned directories
- Fixed crash when download is canceled while chunk hash job is in progress
- Added dynamic module-based upload-speed scaling based on modules overall upload/download data ratio, thus upload-capable modules that have downloaded 70% of data get 70% of upload slots. Note that these are not hard limits, so actual results may vary depending on various conditions.
- Faster and non-blocking disk space allocation for downloads
- Fixes crashes when search result handlers get destroyed
- Properly updates file modification date after movework finishes
- --disable-colors and --transform-colors command-line options
- --module-dir command-line option
- Now correctly handles temp/shared dirs with .. in path names
- No longer shares desktop.ini, thumbs.db and similar files
- No longer loses custom metadata after file rehash
Bittorrent Module (madcat)
- Fixed links command for single-file torrents after restart
- Reduced outgoing client connection timeout from 30s to 5s
- Fixed an issue with URI delimineters not being encoded in tracker GET request (ticket #225).
- Handles tracker responses sent with
newline instead of
- Properly seeds downloaded torrents after completition
- Cleans up cache folder on download completition or canceling
- Properly urlencodes HEAD / GET request arguments (ticket #235)
- Listening ports are now restarted instantly after runtime configuration changes
- Fixed some crashes during torrent completition
- Multi-tracker support
- Fixed uploaded/downloaded ratio calculation
eDonkey2000 Module (madcat)
- Reduced outgoing client connection timeout from 30s to 5s
- Fixed parsing QueueRanking packets from MLDonkey clients
- Fixed a bug where client would be dropped after download session end, when the remote client contacted us and sent AcceptUploadReq, and we didnt send ReqFile.
- Now properly destroys remote LowID clients if we are also LowID.
- More default (hardcoded) servers
- Support for global searching
- Miscellaneous protocol performance improvements and fine-tuning
- Properly switches sources to other files on download completition now
- GlobGetSources v2 packet is sent with different opcode. This raises UDP source queries effectiveness by ~5 times (from 4% to 20+%)
- Better A4AF handling
- Listening ports are now restarted instantly after runtime configuration changes
- Setting ed2k/FindServers can be set to 0 now to disable receiving servers from clients and servers
Email notifications (madcat)
- Fixes unhandled exceptions from connect() call (ticket #217)
HLink application (madcat)
- Its now possible to pass full paths (to .torrent files etc)

CTorrent is a BitTorrent client written in the C programming language, known to be a very robust and mature programming language, which produces fast and optimized applications. There are compilers for most operating systems, making programs written in C easy to port.
It currently runs on most Linux variants, MacOS and FreeBSD, but it hopefully run on Windows aswell! CTorrent is built as a console program, which means that it doesnt require any graphical components (such as an X server) on the machine you are running it on, you can even run it remotely through a terminal if you wish.
While a lot of people prefer a GUI (Graphical User Interface) for this kind of applications, there are quite a few people who run "console only" servers and want to use them to download files in the background. CTorrent can help you do exactly this, assuming you are downloading from the BitTorrent network.
Main features:
- Primary purpose of CTorrent is to provide a way to download files off the BitTorrent network.
- Runs on most Linux distributions, FreeBSD and MacOS.
- Does not require an X server, can be run as a consoleprogram from a shell (locally or remotely)
- Programmed in pure C, which means small and lightning fast executables.
- Opensource. Download the source-code of CTorrent and customize to fit your needs (requires C-programming skills)
- Has the ability to create new torrent-files (for seeding and sharing etc)
- Uses very little CPU and memory resources.