Deluge Forum

I have used deluge as a daemon on Linux with console access for a couple years now, that's been great, other than I'm paying my ISP a surcharge because I once cracked the terabyte/month limit. There are occasionally issues with Python packages, but that's my language of choice, so resolving those hasn't been an issue. This evening I've been working on creating and seeding a torrent for the first time and it's been absolutely maddening.

I have about a terabyte of data that I'm going to distribute by torrent. It's on an external device in a ZFS dataset - /extdown/elkbackup. I ran the following command in that directory to create the torrent file:

mktorrent -l 20 -p . -o CapitolSiegeBlackBox.torrent

So that's 2^20 or one megabyte chunks, 999,059 of them, starting in the current directory, and putting the results in a torrent file. The total file size was about 21 meg and the first time I tried adding it Deluge failed, saying "too many pieces in torrent". I started another mktorrent using -l 22, hoping that four megabyte chunks would be acceptable.

There are a functionally infinite number of guides out there about how to seed using Windows, how to seed connecting with one's browser, and so forth. They all seem a bit remedial to me and I've not been able to locate one that covers the precise steps to getting a new torrent seeding using the console. I tried starting deluge-console in that directory and loading the torrent there, tried starting it from home directory, etc, and I come to a point where the client thinks I want to download the torrent from elsewhere, it doesn't see that the data is already present. In the various guides I see mention that Deluge wants to use ~/Downloads the starting points for anything it does.

Since the content is in a ZFS dataset it's trivial to change the mount point from /extdown/elkbackup to /home/whatever/Downloads or /home/whatever/Downloads/elkbackup. I'm messing with it now, just using a symlink, while I'm waiting for the new torrent file with four megabyte chunks. I did jump through the hoops of getting the web service running on tcp/8112 but this just seems like another layer of stuff I don't need. The machine I'm using actually has the a Ubuntu Budgie so I could remote desktop to it, but that also seems like a layer of stuff I don't need. All I really want is to get this seeding with deluge-console running under tmux.

Once I understand what to do in terms of paths to make Deluge happy, seems like this is about a two minute problem. Is there a guide out there for the n00b seedbox operator?

Sorry, don't know, but regarding piece-size then I read rutorrent has a 2mb limit(don't know if they mean rtorrent or actually the rtorrent frontend), so for compatibility then maybe over 2mb isn't good, but mind you, I'm definitely not in the know regarding this.

I only looked at it briefly, but I believe libtorrent needs be 1.2.2+ and client needs probably be changed also to accommodate loading the bigger torrent, e.g qbittorrent work or worked on this, and I read likewise that 1tb was pushing it for many clients.

For the torrent not to re-download, then the referenced data needs to be available in the configured download_location/save_path, normally ~/Downloads as you stated, but can be changed editing core.conf or using deluge-console.

Hope you can figure this out eventually, good luck.

A quick look at dpkg shows this:

python3-libtorrent 1.1.13-1.1build2

The file with 2^22 or 4mb chunks seems acceptable to deluge-console.

There is a bug related to Python 3.8 - I hunted this down, edited log.py, recreated bytecode, this fixes a bunch of noise coming from deluge-console.

https://git.deluge-torrent.org/deluge/c ... ed0f2c3206

This is starting to feel like a lot of work for a widely used package on a very widely used distro ...

This seems like a step forward ...

https://github.com/userdocs/python-libt ... repository

Maybe the thing to do is rent a seedbox, just so I can examine a properly configured setup.

Yeah, I built that before, and works good. Though I'd guess you could just add the libtorrent 1.2 PPA also.

Nice it worked with bigger piece-size, though as said keep in mind if seeding to rutorrent users, unless that was fixed in meantime.

I've suggested ubuntu users several times to ping there deluge package maintainers about needing backport that log-fix, but nothing happened as of yet unfortunetly. However, there's imho too many glaring bugs in 2.0.3 compared to develop, so personally I would install manually deluge develop branch, but my used distro made the inteligent decision of providing the dev version as exception in this specific circumstance. I made thread before about how easilly install that manually, from a venv, but in hindsight I would skip venv and just install with '--user' param to pip, e.g 'pip3 install --user git+git://deluge-torrent.org/deluge.git', which still installs into homedir and even sets up shortcuts under ~/.local/bin for you, and then just needs 'sudo apt install python3-libtorrent', optionally from the libtorrent 1.2 PPA, or just as regular older repo package.

Installing libtorrent 1.2 PPA leaves me with a package maintainer's version of deluge-console that gets as far as noticing deluged is running, but then it just stops there. That's on Ubuntu Budgie 20.04.3 LTS and just for your info.

I did what you suggested:

pip3 install --user git+git://deluge-torrent.org/deluge.git

This left me with deluged and deluge-console in /root/.local/bin

Started it up, forced a check, it's doing about 0.03% per each update.

There are many torrents in the world, but this one happens to be a recording of the information operation on Twitter that lead to the Capitol Siege on January 6th, delivered as a snapshot of our Elasticsearch system. The FBI and the Select Committee are already aware that this is available, now it's going to be generally available to the world.

This isn't as exciting as parachuting into Normandy like my father's generation did, but in the end it may be similar in spirit. Thanks