Changing variable value on the fly through the command line

[wakaru]

Hi there;

I'm running qBittorrent on a headless linux server without X as described here:
http://sourceforge.net/apps/mediawiki/q ... a_X_server

This means I only have access to the basic funcionality of the torrent-client via web interface.

I am planning to create a shell script to control the value for the variable ConnectionGlobalDLLimit on the fly, this is, while the qbittorrent-nox is running.

I know the above variable value is set by the config file ~@USER/.config/qBittorrent/qBittorrent.conf, but simply editing the value of the variable ConnectionGlobalDLLimit and saving the config file will not apply the changes.

Is there any way to force qBittorrent to re-read the value of the variables from the config file qBittorrent.conf without closing it and reloading it afterwards so I can accomplish what I want?

Thanks very much in advance.

[nevernow]

qB is a pretty good client, but why don't you use rtorrent in CLI environments?

[wakaru]

To be honest with you, I am quite new to Linux and I thought qBT would be an easier and better option considering my circumstances.

I have not tried rTorrent yet though. Can it do IP-blocking? This is a must for me.

I've seen rTorrent has a couple of 3rd Party GUI options, which would help in controlling it through Web interface.

[Peter]

rTorrent is quite outdated and there is only a release every a few year or so.

You should stick to qBittorrent ... however .. cli access... you should open a new ticket about this on Launchpad Bugtracker.

(Also, check Transmission if Chris says he won't implement it or if its just impossible to implement it.)

[nevernow]

I see nothing particularly wrong with rTorrent. Certainly it's not constantly updated, but that's not a sign of poor quality. It does what it's supposed to do. I do not use it on a daily basis (in fact, I use qB! because I don't think it's the best choice for a desktop environments. But I prefer smaller applications doing less things better than lots of similar apps all marching towards bloat and "full-featuredness".

qB is a graphical application and I think it should aim at perfecting the interface side - also considering it builds upon a core BT library - and not creating a CLI client from scratch which in the end would share little more than a name with the current qB.

On the other hand, qB is not my application, so it's ultimately chris's choice.