[TESTING] Transmission app

Works for me too (after the settings.json modification). Thanks for your work !

settings.json modified

{
“alt-speed-down”: 50,
“alt-speed-enabled”: false,
“alt-speed-time-begin”: 540,
“alt-speed-time-day”: 127,
“alt-speed-time-enabled”: false,
“alt-speed-time-end”: 1020,
“alt-speed-up”: 50,
“bind-address-ipv4”: “0.0.0.0”,
“bind-address-ipv6”: “::”,
“blocklist-enabled”: false,
“blocklist-url”: “http://www.example.com/blocklist”,
“cache-size-mb”: 2,
“dht-enabled”: false,
“download-dir”: “/home/osmc/Downloads”,
“download-queue-enabled”: true,
“download-queue-size”: 5,
“encryption”: 0,
“idle-seeding-limit”: 30,
“idle-seeding-limit-enabled”: false,
“incomplete-dir”: “/home/osmc/Downloads”,
“incomplete-dir-enabled”: false,
“lpd-enabled”: false,
“message-level”: 1,
“peer-congestion-algorithm”: “”,
“peer-id-ttl-hours”: 6,
“peer-limit-global”: 200,
“peer-limit-per-torrent”: 50,
“peer-port”: 51413,
“peer-port-random-high”: 65535,
“peer-port-random-low”: 49152,
“peer-port-random-on-start”: false,
“peer-socket-tos”: “default”,
“pex-enabled”: false,
“port-forwarding-enabled”: true,
“preallocation”: 1,
“prefetch-enabled”: 0,
“queue-stalled-enabled”: true,
“queue-stalled-minutes”: 30,
“ratio-limit”: 2,
“ratio-limit-enabled”: false,
“rename-partial-files”: true,
“rpc-authentication-required”: false,
“rpc-bind-address”: “0.0.0.0”,
“rpc-enabled”: true,
“rpc-password”: “”,
“rpc-port”: 9091,
“rpc-url”: “/transmission/”,
“rpc-username”: “”,
“rpc-whitelist”: “127.0.0.1”,
"rpc-whitelist-enabled": false,
“scrape-paused-torrents-enabled”: true,
“script-torrent-done-enabled”: false,
“script-torrent-done-filename”: “”,
“seed-queue-enabled”: false,
“seed-queue-size”: 10,
“speed-limit-down”: 100,
“speed-limit-down-enabled”: false,
“speed-limit-up”: 100,
“speed-limit-up-enabled”: false,
“start-added-torrents”: true,
“trash-original-torrent-files”: false,
“umask”: 18,
“upload-slots-per-torrent”: 14,
“utp-enabled”: true
}

Wouldn’t it be more secure to leave the whitelist enabled, and add your local network to it, wildcards are allowed, so…

“rpc-whitelist”: “127.0.0.1, 192.168.0.*”,

Not sure how best to automate this though, would need updating if local network changed.

No, because OSMC is designed to be behind NAT anyway, so provided this isn’t port forwarded, it will be safe

S

i change “rpc-whitelist-enabled”: false, but after reboot it changes to “true”

You probably need to edit the file while the transmission service is shut down otherwise it overwrites your changes on exit.

Before editing the file issue this command:

sudo systemctl stop transmission.service

Edit your file then reboot. See if that helps. BTW you can also stop/disable transmission via the Services section of OSMC settings.

“rpc-password”: “”,
“rpc-port”: 9091,
“rpc-url”: “/transmission/”,
“rpc-username”: “”,

if i understand this correctly, the username/PW combo should be empty. but if ic call my kodi IP at port 9091 transmission keeps asking me for identification and does not accept it if i just hit Enter twice … anybody has the same problem?

cheers

Look at “rpc-authentication-required”: false,

Having stopped the service manually at the command line and changed my RPC settings, confirmed the app works for me too. Don’t understand the interface options to stop or start the service via OSMC settings, so was trying to “sudo systemctl start transmission-daemon”, and have been led to start reading about masking services but haven’t learned why this would be desirable. If anyone cares to explain why it’s masked, I’d love to learn. Thanks

Thanks, it’s works for me. :smile:

Hi

I have made some changes to Transmission here:

Sam

Hello Sam,

the any value for rpc-whitelist should be ... instead of 0.0.0.0.

Please see also post below:

Thanks

Hello Sam,
I just upgraded the transmission package to your latest build.
As nirvana80 points out, 0.0.0.0 means no clients can connect to the daemon with rpc.

Moreover, the whitelist settings in settings.json are now forced to 0.0.0.0 and true when transmission service is started. So even if you stop the transmission service and change these settings, they are overwritten again.

So as of now transmission is rather useless I am afraid :wink:

thanks

OK,

I’ve changed it once again in this commit here:

and re-compiled the App Store version and pushed it to Release. Can you try it now? You can update via My OSMC → Updater or do a sudo apt-get update && sudo apt-get dist-upgrade

Sam

Sorry,
I see that you have put three dots … as setting now, but that is still not working as not correct to be a wildcard. The asterisk fell away in the post above, correct setting should probably be “*.*.*.*”

I assume this since before your changes today a setting of “192.168.*.*” worked fine for connecting clients within my LAN (subnet 192.168.1.x).
Or you can simply set
“rpc-whitelist-enabled”: false,

Best solution would of course be that these are only initial settings in the first settings.json file created during install or startup of the service, and if the user changes it manually it never gets overwritten again.

thanks

Argh…

OK, I’ll change it.

Yes – in an ideal world you could do it in a postinst, but seems to be problematic… Transmission crashes if we predefine settings.json and I never got a lot of feedback so this will do for now. You can override the ExecStart with an environment ‘drop in’ or by putting a new unit in /etc/system which will take precedence.

S

The update I got just now still doesn’t have the correct wildcard, it has:

ExecStart=/usr/bin/transmission-daemon -f --log-error --allowed ...

while it should be:

ExecStart=/usr/bin/transmission-daemon -f --log-error --allowed *.*.*.*

however as a work around for people who want to use whitelisting or turn it off, I would just create a custom script without the --allowed option as explained here:

click here for the entire post

read the rest of the post if not clear.

It’s fixed now.

For some reason, I only saw … in someone’s post. Possibly a formatting issue.

Pre-generating settings.json if it does not exist already in post-inst would be ideal, and I tried this originally, but user’s reported that it just ‘crashes’, so I wasn’t sure how we can reliably prefill settings.json.

OSMC should be kept behind NAT for obvious reasons, so things should be OK.

S

Confirmed working perfectly alright.

Regarding why the asterisks did not show up in previous post, and only …, it is this forum’s message editor that removes the asterisks.
To show asterisks properly in my post above, I had to use the HTML code as taken from http://www.ascii.cl/htmlcodes.htm

Thanks for confirming.

Sam