Deluge remote control. Installing Deluge BitTorrent on Ubuntu Server. Deluge adding extension for unfinished files

Installation

To get the latest version, add a PPA repository:

Sudo apt-get update
sudo apt-get install python-software-properties sudo add-apt-repository ppa:deluge-team/ppa

Update the list of packages:

Sudo apt-get update

Install the client, console and daemon:

Sudo apt-get install deluge-common deluge-console deluged

If we want a web interface, install it too:

Sudo apt-get install deluge-webui

All! Let's start the daemon:


Settings

To enable remote access, launch the console:

Deluge-console

And we execute the commands:

Config -s allow_remote True
config allow_remote

Exit the console:

Add a user for remote access (this data is in no way related to your Linux user) and specify access rights:

Echo "username:password:level" >> ~/.config/deluge/auth

More details on access rights.

And restart the daemon:

Pkill deluged
deluged

If we want deluge to run along with the system, we need to create scripts that will do this.

Create the config:

Sudo vim /etc/default/deluge-daemon

Paste this code there, Necessarily DELUGED_USER must indicate the user on whose behalf the daemon will run:

# Configuration for /etc/init.d/deluge-daemon

# The init.d script will only run if this variable non-empty.
DELUGED_USER=""

# Should we run at startup?
RUN_AT_STARTUP="YES"

Create a launch script:

Sudo vim /etc/init.d/deluge-daemon

And we write in it:

#!/bin/sh
### BEGIN INIT INFO
# Provides: deluge-daemon
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Should-Start: $network
# Should-Stop: $network
#Default-Start: 2 3 4 5
#Default-Stop: 0 1 6
# Short-Description: Daemonized version of deluge and webui.
# Description: Starts the deluge daemon with the user specified in
# /etc/default/deluge-daemon.
### END INIT INFO

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="Deluge Daemon"
NAME1="deluged"
NAME2="deluge"
DAEMON1=/usr/bin/deluged
DAEMON1_ARGS="-d" # Consult `man deluged` for more options
DAEMON2=/usr/bin/deluge-web
DAEMON2_ARGS="" # Consult `man deluge-web` for more options
PIDFILE1=/var/run/$NAME1.pid
PIDFILE2=/var/run/$NAME2.pid
UMASK=022 # Change this to 0 if running deluged as its own user
PKGNAME=deluge-daemon
SCRIPTNAME=/etc/init.d/$PKGNAME

# Exit if the package is not installed
[ -x "$DAEMON1" -a -x "$DAEMON2" ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$PKGNAME ] && . /etc/default/$PKGNAME

# Load the VERBOSE setting and other rcS variables
[ -f /etc/default/rcS ] && . /etc/default/rcS

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

if [ -z "$RUN_AT_STARTUP" -o "$RUN_AT_STARTUP" != "YES" ]
then
log_warning_msg "Not starting $PKGNAME, edit /etc/default/$PKGNAME to start it."
exit 0
fi

if [ -z "$DELUGED_USER" ]
then
log_warning_msg "Not starting $PKGNAME, DELUGED_USER not set in /etc/default/$PKGNAME."
exit 0
fi

#
# Function that starts the daemon/service
#
do_start()
{
#Return
# 0 if daemon has been started
#1 if daemon was already running
#2 if daemon could not be started
start-stop-daemon --start --background --quiet --pidfile $PIDFILE1 --exec $DAEMON1 \
--chuid $DELUGED_USER --user $DELUGED_USER --umask $UMASK --test > /dev/null
RETVAL1="$?"
start-stop-daemon --start --background --quiet --pidfile $PIDFILE2 --exec $DAEMON2 \
--chuid $DELUGED_USER --user $DELUGED_USER --umask $UMASK --test > /dev/null
RETVAL2="$?"
[ "$RETVAL1" = "0" -a "$RETVAL2" = "0" ] || return 1

Start-stop-daemon --start --background --quiet --pidfile $PIDFILE1 --make-pidfile --exec $DAEMON1 \
--chuid $DELUGED_USER --user $DELUGED_USER --umask $UMASK -- $DAEMON1_ARGS
RETVAL1="$?"
sleep 2
start-stop-daemon --start --background --quiet --pidfile $PIDFILE2 --make-pidfile --exec $DAEMON2 \
--chuid $DELUGED_USER --user $DELUGED_USER --umask $UMASK -- $DAEMON2_ARGS
RETVAL2="$?"
[ "$RETVAL1" = "0" -a "$RETVAL2" = "0" ] || return 2
}

#
# Function that stops the daemon/service
#
do_stop()
{
#Return
# 0 if daemon has been stopped
#1 if daemon was already stopped
#2 if daemon could not be stopped
# other if a failure occurred

Start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --user $DELUGED_USER --pidfile $PIDFILE2
RETVAL2="$?"
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --user $DELUGED_USER --pidfile $PIDFILE1
RETVAL1="$?"
[ "$RETVAL1" = "2" -o "$RETVAL2" = "2" ] && return 2

Rm -f $PIDFILE1 $PIDFILE2

[ "$RETVAL1" = "0" -a "$RETVAL2" = "0" ] && return 0 || return 1
}

case "$1" in
start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME1"
do_start
case "$?" in

esac
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME1"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
restart|force-reload)
log_daemon_msg "Restarting $DESC" "$NAME1"
do_stop
case "$?" in
0|1)
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
echo "Usage: $SCRIPTNAME (start|stop|restart|force-reload)" >&2
exit 3
;;
esac

Set execution rights for root:

Sudo chmod 755 /etc/init.d/deluge-daemon

Add the script to autoload and unload:

Sudo update-rc.d deluge-daemon defaults

Well, let’s check the work done.

On the BitTorrent server, the Deluge client and manage it through the web interface (WebUI). Unfortunately, WebUI does not support all Deluge features. Especially in terms of plugins, most of which cannot be configured via WebUI. Fortunately, Deluge's graphical (GTK UI) interface allows you to connect to and manage a remote server client with the same ease as a local client.
We have: A remote server (on the local network) running Debian 7 and the Deluge daemon installed on it paired with WebUI, as well as a home computer running Linux Mint 14 (Ubuntu 12.10). We will omit the installation process of the server part, since it is described in detail in the article dedicated to Deluge. Let's move on to the settings and installation of the client part on your home PC.
It is worth noting that the presence of WebUI on the server is not necessary, but it will not be superfluous if you plan to connect to Deluge not only from home. In this regard, you can start setting up in three ways, after first installing GTK UI on your local computer:
aptitude install deluge deluge-gtk
Then we launch the daemon on the server and set the login and password for remote access. The command must be executed as the user under which Deluge Daemon is running.
echo "username:password:level" >> ~/.config/deluge/auth
Where “username” is the user, “password” is the password, and “levil” is the access level. The user and password can be arbitrary. It is not necessary that they coincide with the username under which the daemon runs. The daemon must be running.
Access levels:

  • 1 - read only.
  • 5 - user.
  • 10 - Administrator.
1. The first method involves the presence of WebUI on the server. In the settings, we need to enable remote access to the daemon in order to give us the ability to connect to Deluge remotely.

2. In the second method we use Deluge Console. To do this, you need to install it on the server.
aptitude install deluge-console
Launch the console
deluge-console
In it we command:
config -s allow_remote True config allow_remote
Exit the console:
exit
All actions with the console must also be performed on behalf of the user under whom Deluge is running.
Reboot the daemon:
/etc/init.d/deluge-daemon restart
3. In the third method, we use an SSH tunnel from a home computer to a server. In this case, it is not necessary to enable remote access on the server side. Open a local terminal and write the following:
ssh -fNL 127.0.0.2:58846:localhost:58846 server
Where “server” is the IP address of our server. We use 127.0.0.2 instead of localhost so that the client knows we are connecting to a remote daemon. If you get the error “bind: Can"t assign requested address”, then run the following command (add an alias to the local loop):
sudo ifconfig lo0 add 127.0.0.2
Then we repeat the previous command.
Next, launch GTK UI on the local computer and in the interface settings, uncheck the box next to Classic Mode, and then restart the UI. Now when we start GTK UI we see the Connection Manager pop-up window. We remove the local daemon from the list and enter the address of the remote one. Depending on the method chosen earlier, in the Hostname field we enter either the ip of our server where Deluge is located, or, in the case of an ssh tunnel, 127.0.0.2. We do not touch the port if we did not change the daemon port during the configuration of the server part. Username and password - indicate the data that we specified in the ~/.config/deluge/auth file.


That's all. If everything is done correctly, then we can safely connect to the daemon through the local GTK UI, in which everything that we could not use through the WebUI will be available to us.
The screenshot shows two connections. The first is remote, requiring a previously enabled option that allows remote access to the daemon. The second is a connection using an ssh tunnel. Green checkmarks mean connections are available.


Important! The server and client versions of the programs must be of the same line. For example, on my server the program version is 1.3.3, on my home computer it is 1.3.5. This is fine. If version 1.2.X is installed on the server, and version 1.3.X is installed on the PC (or vice versa), then even if the design works (which is unlikely), problems are inevitable.

All subsequent steps are described using Fedora as an example, but can be adapted for any other distribution.

Installation

Installation is as simple as it gets.

$ sudo dnf install deluge-daemon deluge-console

We install the console client, as well as the cli for it.

That's all for now. The client is ready to go. You can already turn it on and use it.

$ sudo systemctl enable deluge-daemon $ sudo systemctl start deluge-daemon

But there are many problems with this configuration:

  • no logs
  • incorrect distribution by server ports

Do you need this? 🙂

Logs

Immediately after installation, the daemon is ready to run. But the configuration offered by distribution suppliers is not entirely successful. There is no logging of what is happening.

To do this, we need to set logrotate.

$ sudo dnf install logrotate

Configure it to support the new rotation rules. To do this, let's create a file /etc/logrotate.d/deluge approximately the following content

/var/log/deluge/*.log ( rotate 4 weekly missingok notifempty compress delaycompress sharedscripts postrotate initctl restart deluged >/dev/null 2>&1 || true initctl restart deluge-web >/dev/null 2>&1 || true endscript)

And also a folder for storing logs. And we will give her the necessary rights.

$ sudo mkdir /var/log/deluge/ $ sudo chown deluge:deluge /var/log/deluge

Now all that remains is to enable log support for the daemon.

Create a new daemon description for systemd in /etc/systemd/system/deluged.service

Description=Deluge Bittorrent Client Daemon After=network.target Type=simple User=deluge Group=deluge UMask=007 ExecStart=/usr/bin/deluged -d -l /var/log/deluge/daemon.log -L warning Restart= always TimeoutStopSec=300 WantedBy=multi-user.target

Great. All that remains is to configure iptables and deluge itself.

Setting up iptables

In some cases, it is enough to simply open the necessary ports

$ sudo iptables -A INPUT -p tcp --dport 56881:56889 -j ACCEPT $ sudo iptables -A INPUT -p udp --dport 56881:56889 -j ACCEPT

But in some configurations there may be problems with the conntrack mechanism, which marks a number of packets as invalid (especially for dht traffic).

Therefore, it is worth disabling conntrack for all deluge connections.

$ sudo iptables -t raw -I PREROUTING -p udp --dport 56881:57200 -j NOTRACK $ sudo iptables -t raw -I OUTPUT -p udp --sport 56881:57200 -j NOTRACK $ sudo iptables -t raw -I PREROUTING -p tcp --dport 56881:57200 -j NOTRACK $ sudo iptables -t raw -I OUTPUT -p tcp --sport 56881:57200 -j NOTRACK $ sudo iptables -I INPUT -p icmp --icmp-type 3 - j ACCEPT $ sudo iptables -I INPUT -p icmp --icmp-type 4 -j ACCEPT $ sudo iptables -I INPUT -p icmp --icmp-type 11 -j ACCEPT $ sudo iptables -I INPUT -p icmp --icmp -type 12 -j ACCEPT

$ sudo /usr/libexec/iptables/iptables.init save

Local authorization

In order for us to successfully use deluge-console, local authentication must be enabled for our user.

Those. there should be a file ~/.config/deluge/auth containing a login-password line

Localclient:here_long_hash:10

You can copy this file from the /var/lib/deluge/.config/deluge directory

$ sudo cat /var/lib/deluge/.config/deluge/auth >> ~/.config/deluge/auth

Starting and configuring the daemon

$ sudo systemctl enable deluged $ sudo systemctl start deluged

Thus, we launched the daemon, the config of which was described earlier.

Actually, why is our file server idle? And where should the file come from on it? It’s a mess. Let’s install a torrent client on it. I’m used to uTorrent in Windows. In kubuntu I used kTorrent at one time. But in this case we are interested in clients that can work without a GUI and that have a web interface. Options:

  1. A combination of rTorrent + wTorrent. There are quite a lot of setup descriptions on the Internet, but the process scares me =)
  2. TorrentFlux and its fork Torrentflux-b4rt. Created as a web interface and nothing more. You might want to think about setting it up.
  3. Deluge. Initially it was planned as a torrent client for gtk. But starting from a certain version, it can work as a daemon, to which you can connect the desired interface - either a graphical face, or a web face, or controlled via the console.

For now I’m thinking of trying to mess around with the third option. Oops - it turns out you can attach a screw face to it! I’ll google further. It would just be quite convenient as usual - you sit in the browser, click on downloading a torrent file and open it using Windows. And she already transfers the download to the daemon on the server. We install deluge (in general it is recommended to install the version from the official site, but I installed it from the repositories) sudo aptitude install deluge-coresudo aptitude install deluge-webuisudo aptitude install deluge-console If we install packages downloaded from the site, then most likely the problem of unsatisfied dependencies will arise. We get out of the situation as follows: sudo apt-get -f install Let's launch deluged Launching the web face deluge --ui web By the way, we run this command on behalf of our user, not as root. Because in this case the web interface will not work. Why, I haven’t figured out yet. But after running this, one console will disappear, because this command is executed there. In order for the command to be executed and remain hanging in the background, we write deluge --ui web& If you need the web interface to be always available, push this command somewhere into autorun, but so that it is executed with the rights of a regular user. By the way, I recommend pushing the launch of the deluged daemon into autorun. The web interface runs on port 8112. Let's go via a browser to the desired server on this port. The default password is deluge. Configure. Several design options are offered. Ajax option is the most beautiful. But it doesn't have all the features. For example, you cannot specify for a specific torrent where to download a file. You can only specify a common folder for all torrents. This feature is present in other skins. Let's move on. It is possible to use a GUI shell for deluge, launched on any computer other than the server (and even on the server, if a graphical environment is installed there). There are GUI shells for both Linux and Windows. But before using the GUI shell, you need to allow this to the daemon. We do this in any of two ways:

  1. Via web interface. in settings - Deluge - Service - Allow remote connection (check the box)
  2. Via the console interface. We write deluge --ui console. Then config allow_remote True.

The web interface is often inconvenient to use. But this is purely IMHO. Since I have Windows on my desktop (Windows Web Server 2008), let’s install the client under Windows. Go to the official website of the project, download the version for Windows. It is recommended to download the same version as the daemon installed on the server. Download and install. The installer will also prompt you to install GTK+ Runtime. We agree. After the client has been installed, we go into its settings:

  1. Launching the client
  2. Go to "Preferences -> Interface" and uncheck "Classic Mode".
  3. Restart the client. The Connection manager window should appear
  4. Remove the line from localhost. By clicking the "Add" button, enter the IP of the server (in our case, the box). Leave the port the same.

Here I was stuck for a while. In addition to the IP address, I had to enter a username and password. Let’s say I could set the password through the web interface. What user should I write? I wrote my own and the password set through the web interface. No big deal. I wrote my own and his password in the system. Never mind... I dug around. So, we do this:

  1. We go on the server to the home directory of our user (from which we run deluge)
  2. Next, go to the /.config/deluge directory
  3. Open the auth file
  4. In the second line we write the username and password in the format user:password (and I note that we are writing this information from a fool)
  5. Restart deluge - deluged restart
  6. On a computer with Windows, go to Connection Manager, enter this user and his password in the connection settings.
  7. Click "Connect"
  8. Voila, the client is connected.

Thus, we got the usual way of processing torrent files - we open them with a torrent client (GUI face) and choose what to do. But there is another way. I also tried this method:

  1. Create a folder on the server, say /home/user/torrents
  2. We share it in samba.
  3. In the settings of deluge, we set it through the same web interface so that it will automatically take torrents from this folder.
  4. And then, we simply save the torrent files into this folder.

Tell me how to make apf-firewall closed for most ports, but samba works locally, and a torrent client, for example Deluge, works.
Distribution: Debian Jessie
Kernel: 3.14-2-amd64
The mode in which the firewall turns off after 5 minutes is disabled. I configured it as written here: https://www.debian.org/releases/slink/i386/ch-init-config.ru.html Vuurmuur is not offered - it is a crooked utility, and a bearded one at that.

Well, as an option, you can argue why a firewall is not needed on a home PC.

Deluge disables the Internet (WiFi)

Hi all. I'm trying to download something via Deluge - a torrent tracker in xubuntu 14.04.1, and my Internet connection turns off after 15 seconds, or rather the Internet is simply stupidly unavailable, Deluge also stops downloading. I have to restart WiFi and then wait again for 10-15 seconds. Something, in short, not good. Maybe someone knows how to solve the problem.

deluge and root tracker

service autostart in opensuse 13.1

I don't understand anything. I installed Deluge, downloaded the script, put it in init.d, created a symlink in rc5.d in YAST - service manager (service manager), the service appeared, I set it to Enabled, I saved it, I came in again, and it was Disabled again. What the? It starts normally without glitches, but does not want to start with the system.

UPnP works in Transmission, but does not work in Deluge and qBittorrent.

On the router (Fedoro19-router) for UPnP there is linux-igd, default.

I run Transmission on the client, on the router in iptables -L the forwarded ports are visible, the linux-igd logs are eloquent. Hood.

On the client I run qBittorrent or Deluge (upnp enabled, of course) - ports are not forwarded, there are no incoming connections, iptables on the router is silent, linux-igd logs are silent. Bad.

Before this, I noticed that with box routers (such as asus, tp-link), transmission, on the contrary, does not work with UPnP, but qBittorrent does.

What to spin? Or at least say: “UMVR, linux-igd and qBittorrent (or Deluge).”

Deleted (28.02.14 13:25:31)

Torrent client for high load

I would like to ask hardcore players with 1000+ active distributions which client is currently optimal for such a scenario. I only consider server and demonic clients with adequate system requirements.

Of particular interest are memory and processor consumption, resistance to non-trivial torrents (long file names), resistance to errors and their consequences during downloading, grouping of distributions instead of a solid list.

Currently under the supervision of Transmission, Deluge, qBittorent. But everyone has their faults. qBittorent does not have a normal face for client-server interaction (maybe it’s already been added, I couldn’t find it), it doesn’t understand long names (more than the FS allows).. Deluge (especially the guy) starts to get stupid on 100+ torrents, frequent jambs with rehashing (before definitely were). Transmission molds all distributions into a linear list without any grouping, which on the specified scale will “inspire”, does not understand long names.

Deluge has trouble with speakers

The columns downloaded, uploaded and some others are not displayed as you do not mark them. Those that are by default (for example #, name, size, state) can be easily turned on and off. What to do? Maybe this can be fixed in the configs? But I don’t know which file to look in.
If suddenly this is an eternal deluge bug that is not fixed, then suggest alternatives. I am partially familiar with them. From those that I know and visually liked - kTorrent for example. But I have a third gnat, and holding heavy sneakers is said to be bad.

Deluge how to make it so that torrent is automatically launched from the user in arch-Linux

Autorun Deluged daemon as user “deluge”

There is a server with debian 7.2. systemd initialization system.

Required: launched at system startup, deluged from the user “deluge”, access to the daemon through the windows GUI via standard port 58846.

Access to the folder with torrents is allowed to the user deluge, mounted using the Sambaclient in /mnt.

Installed deluged, deluge-console. Allowed remote access. I created deluged.service and placed the script from the official wiki in it:

Description=Deluge Bittorrent Client Daemon After=network.target User=deluge Type=simple ExecStart=/usr/bin/deluged -d WantedBy=multi-user.target

adduser --disabled-password --system --home /home/deluge --group deluge

echo "deluge:pass:10" >> ~/.config/deluge/auth

I turn on deluged.service:

systemctl daemon-reload systemctl enable deluged.service systemctl start deluged.service

The daemon starts, works, and occupies the port. But he doesn’t want to let it through the Windows GUI. I change the user to root in deluged.service and it works.

What am I doing wrong? Does the deluge user need any rights?

deluged daemon won't unload

In deluge I specify exit&stop the daemon or first stop it from the menu. I've been waiting for some time. And still he is active in the top. Doesn't respond to regular kill, only with a strap-on. What are your ideas? Package: deluge

Deluge and mysticism

Something strange just happened. I listen to Internet radio. And suddenly it starts to lag. I look at the speed graph. I see that something has eaten up almost the entire strip. I start looking at ports and turning off various daemons. I look at the speed that deluge consumes through deluge-console. The reported speed is not even close to the actual speed. Iftop says that there are many connections and not to the deluge daemon port. I still disable deluge. The speed dropped sharply. For the sake of experiment, I turned the demon on and off a couple of times. The traffic clearly correlated with the daemon being turned on/off. What was it?!

How to delete .torrent after adding it in Deluge?

Looking for a new torrent downloader

Responsibilities:
- work around the clock as a demon;
- have a visual interface for adding/removing torrents that would connect to the daemon;
- the ability to configure the reception of connections from clients via a Unix socket and/or a specific range of network interfaces or IP addresses of these interfaces;
- multi-user authentication, preferably with access restrictions;
- no problems with the user interface;
- clients must be able to receive and display information in a classic full tabular form;
- client-server should not be implemented on the http(s) protocol;
- be native to Linux.

A short history of what I used before:
A long time ago I used vuze aka azureus - I didn’t like the interface.

Then there was deluge, which I used successfully until, after another reassembly of the world, fir problems emerged. The sharing interface is close to ideal, keep that in mind.

Then I decided to try rtorrent, which I mastered, although I was tired of dragging all the open downloads from the share onto it. rtorrent is cool, but only I can work with it, and there is also the rest of the family.

Therefore, after rtorrent, I tried sharing again, but again there were fir problems. Then I created a thread similar to this one and switched to transmission-daemon and transmission-remote-gtk. The problem with the latter is that in the add torrent menu it does not allow you to normally select a folder, forcing you to press in each path manually. The latest versions have moved to gtk+3 than finally
confirmed my desire to get off him. No, I’m not against gtk3 as such, I just think that gtk is a fucking glukodrome, and I don’t even have a theme for the third version.

Today I installed the deluzh. This time both the server and the client worked, I was pleasantly surprised by the simplification of the authentication organization (previously it was necessary to generate passwords through the console, now the plaintext is in a file), but I was disappointed by the lack of sane settings for the interface on which the connection listens for connections. Deluzh can do two extremes - either he listens to the localhost, or to 0.0.0.0. However, there was one surprise in store for me - when I tried to add a file, I discovered that the file selection dialog almost never worked correctly, except when the path was in the position of the last selected one. // Isn’t it for this reason that a similar element in the transmission is made in the form of a wretched beater?

Deleted (23.01.13 20:31:28)

Sort by adding.

Deluge does not transfer files of completed downloads

Using Deluge 1.3.5 from the repository. Distribution - archlinux x86_64. I set in the settings the directory for downloading and the directory for completed distributions. Does not work. I also connected the AutoAdd plugin, which also has a similar setting - it doesn’t transfer and that’s it. Torrents begin downloading as soon as the .torrent file appears in the desired directory.

I tried using both the daemon and the “classic interface” - no difference. I even tried to remove deluge, all its settings, and install it again - it doesn’t work, I also collected it from AUR, to no avail. I already set the rights to the directory for completed downloads to 777, it doesn’t help, that’s not the problem. Once upon a time, everything worked , and then somehow, I didn’t even notice when, it stopped.

Has anyone encountered a similar problem? And how to overcome it? It is not recommended to use transmission.

Deluge in combination with PC-Ubuntu + Server-NAS4Free (FreeBSD)

I will try to express myself correctly and clearly. Due to the fact that Transmission Remote GUI works poorly on Ubuntu 12.10 (for me personally), I decided to create something similar to this with other software. The choice fell on Deluge. Found the instructions http://dev.deluge-torrent.org/wiki/UserGuide/ThinClient Made it Installing Deluge On FreeBSD

In point Private IP: entered the IP of the local server (NAS), let’s say for example it is 192.168.68.68

ifconfig | grep -e "inet addr" | grep -v "192.168.68.68" | cut -f2 -d":" | cut -f1 -d" "

Deluge adding extension for unfinished files

priorities of files in torrent, downloading

There is a torrent file, it has a directory structure, the files are named by their hash. I already have some files on my computer. You need to set priority “0” to the files in the torrent that are present. Python language, torrent library - libtorrent from rasterbar. I dug into the source code of deluge (it is written in python and uses the same library). I will receive a torrent file or magnet link, but that’s not the point.

Why switch to KTorrent?
KTorrent is devoid of the above-mentioned shortcomings of Deluge, but is not inferior in functionality and responsiveness. It consumes about the same amount of memory, despite kde's libraries. As for other torrent clients, they do not reach the functionality of Deluge and KTorrent. Only qBittorrent could become an alternative, but it is banned on pornolab and still creates empty directories (the problem is solved with “empty” files).

So, while studying regular expressions and Unix console utilities, I wrote a script for transferring Delyugov’s downloads and distributions. I would like to draw your attention to three things:

  • The status of files not marked for uploading in multi-file distributions will not be transferred (i.e., all will be marked by default).
  • When you start KTorrent, all transferred distributions/downloads will be stopped and you will need to re-hash them by selecting each distribution and pressing SHIFT+C (I haven’t found a faster way. In some torrent clients it’s enough to click “start all”, but KTorrent in this case will be re-downloaded, not re-hashed).
  • Performance tested on Ubuntu 12.04, Deluge 1.3.5, KTorrent 4.1.3

#!/bin/bash #Deluge2KTorrent script #written by takiz aka dadd printf "%s\n" "...wait..."; #we filter out the paths to files from torrents.state and fix the Russian encoding egrep "^S.\/" ~/.config/deluge/state/torrents.state | sed -e "s/^..//;s/.$/\//;s/\//#/g" > paths; t=`cat paths`; printf "%b\n" $t > paths; #we filter out torrent names and remove duplicates, one from each pair egrep "(22,99)" ~/.config/deluge/state/torrents.state | sed -e "s/^..//;s/.$//" | perl -ne "print unless $U($_);$U($_)=1;" > torrents; #create a temporary script file to create directories and run printf "%b\n" "#!/bin/bash\nmkdir ~/.kde/share/apps/ktorrent/tor(1..100500)" > temp1.sh; chmod 774 temp1.sh; strok=`sed -n "$=" torrents`; sed -i -e "s/100500/"$strok"/" temp1.sh; ./temp1.sh; #create a copy script and run printf "%s\n" "#!/bin/bash" > temp2.sh; chmod 774 temp2.sh; cat torrents | awk "(print $0".torrent ~/.kde/share/apps/ktorrent/tor"NR"/torrent)" | sed "s/^/cp ~\/\.config\/deluge\/state\//" >> temp2.sh; ./temp2.sh; sleep 10; #create a template stats printf "%b\n" "AUTOSTART=0\nOUTPUTDIR=" > stats; #create stats files with paths a=2; while read f2; do sed -e "1,/.*/(n;s/\(.*\)/\1$f2/)" stats >stats$a; a=$(($a + 1)); done< paths; sed -i -e "s/#/\//g" stats*; #добавляем в скрипт копирования пути stats и запускаем cat temp2.sh | awk "{sub(/\~\/[^ ]*\.torrent/, "stats"NR)}1" | sed "s/\/torrent/\/stats/;s/cp st/mv st/" >tmpfile; mv tmpfile temp2.sh; chmod 774 temp2.sh; ./temp2.sh; sleep 5; #delete temporary files rm paths torrents stats temp1.sh temp2.sh; printf "%s\n" "ok";

Check the bug in Deluge

Most likely this only applies to Fedora.

1. Download.torrent
2. Specify any download folder.
3. Wait for the download to finish.
4. Whatever you indicate in step 2, we see your files in /home/username/

I’ll file a bug report if it appears in anyone else, if not, I’ll look for the problem myself.
P.S. The problem appeared, it seems to me, after the long-awaited update to 1.3.5.