[TESTING] Transmission app


#61

Hi

I have made some changes to Transmission here:

Sam


#62

Hello Sam,

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

Please see also post below:

Thanks


#63

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


#64

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


#65

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


#66

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


#67

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.


#68

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


#69

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


#70

Thanks for confirming.

Sam


#71

Just use the preformatted text function to display text without alteration. (Select a text range then press the </> button)


#73

Hi! I’ve been experiencing a few random stops of the transmission service (probably due to me tinkering around with retrosmc, flexget and couch potato on the same pi2) so I’m writing a bash script to check the health of my services and restart them if needed. For flexget for example I simply run

flexget daemon status

And then check the return to see if the daemon has stopped. Now I’m wondering if there’s a similar command that can be run to check if the transmission service is running? Or is it safe to just now and again run the

sudo systemctl start transmission.service

even if the service is already running?


#74

If the daemon is actually crashing then systemd has built in ability to act as a watchdog and restart the service if it crashes. See here for an example of a service that is configured to restart automatically:

The lines Restart and RestartSec are the ones of interest. Here is the documentation for these options:

http://www.freedesktop.org/software/systemd/man/systemd.service.html

Normally you would use Restart=on-failure which will only restart it if the daemon exits with an error code, or you could use Restart=always which will always restart it even if it’s a clean exit.

Create a file called /etc/systemd/system/transmission.service.d/local.conf and add:

[Service]
Restart=always
RestartSec=5

This will apply these options in addition to those in the main service unit file at /lib/systemd/system/transmission.service in a way that won’t get wiped out during upgrades.


#75

Thank you! Works great! So why isn’t some form of this included in the default install? :wink:


#76

Got a problem

osmc@osmc:~$ sudo apt-get update
Hit http://mirrordirector.raspbian.org jessie InRelease
Hit http://apt.osmc.tv jessie InRelease
Hit http://mirrordirector.raspbian.org jessie/main armhf Packages
Hit http://mirrordirector.raspbian.org jessie/contrib armhf Packages
Hit http://mirrordirector.raspbian.org jessie/non-free armhf Packages
Get:1 http://apt.osmc.tv jessie/main armhf Packages/DiffIndex [2023 B]
Ign http://apt.osmc.tv jessie/main Translation-en
Ign http://mirrordirector.raspbian.org jessie/contrib Translation-en
Ign http://mirrordirector.raspbian.org jessie/main Translation-en
Ign http://mirrordirector.raspbian.org jessie/non-free Translation-en
Fetched 2023 B in 16s (124 B/s)
Reading package lists... Done
osmc@osmc:~$ sudo apt-get install armv7-transmission-app-osmc
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  armv7-transmission-app-osmc
0 upgraded, 1 newly installed, 0 to remove and 128 not upgraded.
Need to get 0 B/2702 kB of archives.
After this operation, 19.4 MB of additional disk space will be used.
(Reading database ... 26026 files and directories currently installed.)
Preparing to unpack .../armv7-transmission-app-osmc_2.8.4-8_armhf.deb ...
Unpacking armv7-transmission-app-osmc (2.8.4-8) ...
dpkg: error processing archive /var/cache/apt/archives/armv7-transmission-app-osmc_2.8.4-8_armhf.deb (--unpack):
 trying to overwrite '/lib/systemd/system/transmission.service', which is also in package armv6l-transmission-app-osmc 2.8.4-8
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/armv7-transmission-app-osmc_2.8.4-8_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
osmc@osmc:~$

#77

You’re trying to install the armv7 (Pi 2) version of transmission over the top of the armv6 (Pi 1) version of the package which seems to be already installed.

You can’t do that. Any particular reason you’re trying to install it from the command line instead of the App store ? The App store takes care of installing the correct version for your hardware, and it seems to be installed already anyway.


#78

Yeah I realised my stupid mistake after I posted the problem.

But doing a sudo apt-get upgrade did corrupt OSMC


Configuring Transmission needs a HowTo
#79

Could you please add information on screen when/after installing Transmission:

  1. where to find the settings.json file?
  2. how to stop transmission so that you can edit the settings.json file?

Otherwise the app is a bit useless. I installed it, had to google and found this topic which shows the location of settings.json in post #49. Haven’t figured out how to stop transmission though (and restart it).


#80

sudo systemctl stop transmission


#81

I also just remembered that you can manage all OSMC services via My OSMC -> Services

Sam