Transmission and cron (OSMC vs Main Repository versions)

General Discussion
1

Hello,

I already have cron and transmission installed before they were available on the app store.

Should I not install the store version?

Is there an advantage in having the OSMC store versions vs the main repository version?

Thanks

2

Transmission is not ready just yet in the App Store. When we do ship Transmission, it will be the latest and greatest. The Debian version may lag behind.

Cron is just a metapackage for Debian cron.

Using official OSMC App Store packages ensures proper updates

S

3

Thanks for your reply Sam.

That explains why installing the cron meta package (which only have references to existing debian packages, but no actual software) didn’t affect my system, as all dependency of the meta package were already installed.

When transmission is available, unistalling the debian package and installing the store one should keep my transmission config in place, right? (settings.json)

One more questione but unrelated. Are you looking at a VNC OSMC app store version, as existing VNC versions on debian as you previously explained don’t work on OSMC?

Thanks again!

4

Hi Sam, is there anything known about the timeline for releasing the App Store packages? I can’t wait to start playing around with Sickbeard and Transmission!

5

Transmission is out and should be good now. Sickbeard etc should follow soon.

Sam

1 Like
6

I’m getting:
“Error installing: armv7-transmission-app-osmc (2.8.4-3)”
"Please report this on the OSMC forum.

I should also mention that I had the transmission-daemon installed and was working fine, I just wanted to install the OSMC one, so first I uninstalled the transmission daemon, and then I installed from gui this one but failed.

Any help?

Thanks

7

Did you properly purge the old version?

Can you replicate this issue on a fresh install?

Can you upload your logs?

2.8.4-3 is the old version. Please try installing again. We ship 2.8.4-5 now.

Sam

8

on one of my OSMC cleaner install, with no previoys transmission-daemon installed, the installation completed just fine.

I then purged all transmission packages and autoremoved the dependencies and then installed fine on the system I had trouble with.
Specifically I did:

sudo apt-get purge transmission-*
sudo apt-get autoremove
sudo apt-get clean (although pretty sure clean is not needed)

Thanks

9

one more questions, transmission starts as:

/usr/bin/transmission-daemon -f --log-error --allowed 0.0.0.0

the --allowed 0.0.0.0 option resets the following in settings.json to

"rpc-whitelist-enabled": true,
"rpc-whitelist": "0.0.0.0",

so I’m wondering can I edit /lib/systemd/system/transmission.service

from

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

to

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

in order to permanently set

"rpc-whitelist-enabled": false,

I guess my real question is will updates overwrite my changes in /lib/systemd/system/transmission.service?

Also I don’t quite understand why it was configured this way in the first place as it makes pretty much transmission unusable as far as I understand it.
I can’t even specify whitelist acls it seems!

Am I mising something here?

10

Did you actually try it to see whether anyone could connect ?

Whitelisting 0.0.0.0 should allow all IP addresses to connect…

11

doesn’t look like that’s the problem I had, nothing could connect.

403: ForbiddenUnauthorized IP Address.Either disable the IP address whitelist or add your address to it.If you're editing settings.json, see the 'rpc-whitelist' and 'rpc-whitelist-enabled' entries.If you're still using ACLs, use a whitelist instead. See the transmission-daemon manpage for details.

removing the option works just fine after disabling the whitelist

it would then make sense to just disable whitelisting in my opition and let everybody get on with their settings.

12

to allow any ip and force enable whitelisting you should use

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

I’ve tested it, that will allow any.

If I may why don’t you just remove the option and let people decide how to use it.

Anyway can you please let me know if updates will overwrite the changes in /lib/systemd/system/transmission.service

Thanks

13

Yes updates would overwrite any change you made there.

If you want to replace a systemd service script with a custom version you should place it in /etc/systemd/system which will always override those default system provided entries in /lib/systemd/system.

14

Thanks.

Was the 0.0.0.0 set in error?
Will an update fix this as clearly as it is, doesn’t allow connections from anywhere.

15

I’m not directly involved in working on the transmission package so I can’t answer that. I do know that it is being worked on to get it fixed and working properly though.

16

I created a custom transnmission.service in /etc/systemd/system/, then i removed the sym link transnmission.service in /etc/systemd/system/multi-user.target.wants/ pointing to /lib/systemd/system/transmission.service and recreated it pointing to the new custom script in /etc/systemd/system/transmission.service.

All working now.

Thanks

17

You don’t need to change the symlinks - simply:

sudo cp /lib/systemd/system/transmission.service /etc/systemd/system/

Then edit the copy under /etc. Systemd always looks in /etc in preference to /lib regardless of where the symlinks point.

18

ok thanks for clarifying that, but there is no negative effect in changing the symbolic link though, is there.