Aware of the issues people have had with whitelists & remote interfaces, but I seem to be having subtly distinct problems: the 403 is reliably ‘resolved’ by checking for updates, and will seem to work for an update or two, but after a few more days, meaning another power cycle or two, the 403 issue returns. Another update, and it’ll go away for a while. Anyone else seeing this?
Updating is probably nothing to do with your problem - because there have not been any updates to transmission for quite a while.
Are you sure it’s not just the reboot that many updates require that is causing it to start working again for a while ?
When it doesn’t seem to be working, what do you see if you go into My OSMC -> Service ? Does it show the transmission service as not running ?
Thanks for rapid response. Will hopefully be able to replicate and advise whether reboot is sufficient. Service always appeared to be started through ‘top’, and I could enable/disable via the OSMC skin, so I’m pretty confident the service was running (wouldn’t the response be 404 if it wasn’t? Just stopped the service: looks like I get a ‘could not connect to server’)
Do you have your download directories on an external drive ? When the problem is there can you check to see if the drive is still mounted under /media ?
We are currently chasing a bug that causes external drives to intermittently fail to mount for a small percentage of users.
Download folder local to the Vero, so I don’t think that’s a factor. Having checked top again when the problem manifests itself, I wonder whether the issue is the user running the service: there are two transmission-daemon processes running. One is running as the osmc user, the other as debian-+. Starting to hit the limits of my linux knowledge I’m afraid.
Looking in the OSMC UI, the service shows as running.
Sounds like you might have installed both the app store version of transmission (which runs as the osmc user) and the normal Debian version ? (which I believe runs as debian)
Post some debug logs from the log uploader and we should be able to see if this is the case.
Powered on the Vero to continue the investigation, and the web UI responded with an authentication request as I believe it should, having modified /home/osmc/.config/transmission-daemon/settings.json Logs uploaded to pastebin using the uploader (uploaded everything, since I couldn’t see a specific ‘debug log’ option I’m afraid).
Still seeing two processes, the ‘double installation’ sounds like a good theory: going through my notes, I suspect the Debian version may have been installed whilst the builds were being discussed as a command line install, and then not removed when the app store version was published. So, I attempted to remove the Debian version sudo apt-get remove armv7-transmission-app-osmc, rebooted, and there are no instances of the service (My OSMC > Services shows no client available, let alone running/stopped). New logs uploaded.
App store > install Transmission client (and see in the progress messages that the package name matches above), reboot, and once again I’m getting two processes (My OSMC > Services shows the client running), with the web UI again giving a 403. Logs uploaded for a third time. Given that both processes appear to be installed by the single app-store request, and stopped by a single systemctl command, is it possible that the install is looking at two repositories, one of them being the jessie-devel repository mentioned in the testing thread? I’ve tried an uninstall & reinstall with the jessie-devel repository commented out of the sources list, and it doesn’t change the behaviour (still two processes, 403 in web ui), so is it possible there’s some residual elements of the double install when I try removing, either through command line or App Store?
This is actually the OSMC version of transmission that you removed.
The Debian version is called transmission-daemon which you can see in your log file is removed but not purged:
rc transmission-daemon 2.84-0.2 armhf lightweight BitTorrent client (daemon)
Try purging it as well, which will remove any remaining config files and init scripts that might have been trying to run it:
sudo apt-get purge transmission-daemon
(Backup your transmission configuration first if you have spent a lot of work setting it up, just in case)
When running
ps auxwf
I only see one transmission daemon running:
osmc 502 0.5 0.7 27828 5752 ? Ssl 11:00 0:02 /usr/bin/transmission-daemon -f --log-error --allowed *.*.*.*
So you definitely shouldn’t be seeing two processes running.
What might be happening is that even though you removed transmission-daemon previously, unless you purge the package as well, the configuration files will remain, which includes the legacy /etc/init.d/ startup script. Normally on a removed package this script would run but would find the actual executable file missing thus terminate without doing anything.
However the executable file does exist due to the OSMC version of transmission being installed. So it could be that the init script for the debian transmission and the systemd service for the OSMC transmission are both trying to run at once - which ever one starts first will get control of the web interface port, potentially at random if they both start at very similar times.
Edit: just studied your log a bit further and I think my theory is correct - you have TWO copies of transmission starting up with slightly different configurations:
Sep 24 08:26:57 osmc transmission-daemon[489]: [2015-09-24 08:26:57.314 BST] Couldn't bind port 51413 on 0.0.0.0: Address already in use (Is another copy of Transmission already running?) (net.c:371)
Sep 24 08:26:57 osmc transmission-daemon[489]: [2015-09-24 08:26:57.314 BST] Couldn't bind port 51413 on ::: Address already in use (Is another copy of Transmission already running?) (net.c:371)
Sep 24 08:26:57 osmc transmission-daemon[489]: [2015-09-24 08:26:57.314 BST] UDP Couldn't bind IPv4 socket (tr-udp.c:263)
Purging the transmission-daemon package should be enough to fix this, but if not let us know.
Thanks for managing to point out that I’d removed the wrong version without implying that I’m a complete idiot…
Purge seems to have resolved the issue (have been through 3 power cycles since). Suspect this isn’t going to be an issue many others encounter, but appreciate the diagnosis walkthrough.
Easy enough mistake to make. 
You’d be surprised how many people do run into this issue. For whatever reason many people try to manually install the standard transmission package without even realising there is one all pre-configured for OSMC and ready to go, in the app store.
Confirming that it is necessary to purge the old package completely for the OSMC version to work correctly is new though - I don’t think this has been talked about in other threads dealing with this issue. (I don’t use transmission myself, so haven’t looked into this issue before)