No YouTube was just an example, id love to be able to use a lot of the USA/Canada addons on kodi via this method. when I use openvpn manager it messes up my live tv. This seemed like the perfect solution, Also if someone's watching an addon via openvpn manager it blocks me from being able to stream to my phone from outside the house.
Only few programs support specific interfaces (eg qbittorrent)
Some support proxies
Maybe has something in systemd to make services work this way
I'll keep searching, and reporting here, if I find something.
If not, maybe disable automatic updates and wait for your update the add-on is not a bad idea too.
I will revert to Mono and set MemoryMax=200M which should be enough to auto-update after Jackett is restarted
I tried this, but don't work like I thinked. When jackett need more memory, and this makes it exceed the 400Mb of limits.slice, only jackett is reboot, not sonarr or radarr like I thinked (and jackett can't update).
But, for what I saw, even 300MB isn't enough for update v0.11.15 (released today).
Jackett updated to 0.11.15 here, but nuked my RPi3 first
I will see what I can do
But not now
I found that the plugins where actually missing from \\libreelec\Kodi\addons\service.deluge\lib\python2.7\site-packages\deluge-1.3.15-py2.7.egg\deluge\plugins
Copied them from a backup and they are working again.
Why were the plugins removed? Must have happened during an update.
Thank you for the feedback
Changes in the build system caused the issue
This will be fixed in when deluge is rebuilt
In Milhouse 302 this has been added to openssl: update to 1.1.1b - this may break some addons
Is it possible to adapt transmisison and the rest of the Thoradia accessories to update for this change ??
I am rebuilding the add-ons
Again, Milhouse builds are development builds
Expect things to break
I remembered something...
When I was search about set memory limits I found this: Resource control with systemd • /dev/schnouki
At that time I test but don´t worked, because, I think, the cgroup_enable=memory was not set. Maybe this is a solution for us!
This consist on set a memory limit for a group of services. I think this way we can set something like MemoryMax=400Mb for Sonarr, Radarr and Jackett.
I think if we set this, when Jackett have to update it will crash another services (sonarr, radarr) and after this back to normal!
I don't know if work this way, but maybe it work
Perhaps is better test this way now and see the results before try this.
I will see what I can do
Anyone know what "Linux ARM builds" mean, if anything, for people running these addons on low powered devices like the RPi?
I know Jackett currently uses Mono, will native Linux builds improve/change anything?
Native, as opposed to Docker
Jackett was switched from Mono to .Net Core yesterday
The add-ons run fine on RPi 3
Is it possible to transfer my previous couchpotato settings file to the thoradia couchpotato? I am really not in the mood to redo the entire thing.
I have my old couchpotato.ini file but cant seem to find where I need to copy it to.
couchpotato configuration is at /storage/.kodi/userdata/addon_data/service.couchpotato and is accessible via smb.
Transmission stopped working after MILHOUSE GENERIC LibreELEC.tv Leia build # 0303 and LibreELEC.tv Leia build # 0302. They operate on older people all the way up to LibreELEC.tv number Leia build # 0301
What can you do about it?
Milhouse builds are early development builds
You should be happy anything runs on them
No joy;(. I tried
and it seems as if web client was indeed delayed, as you cannot access it for first 50 seconds. But when you navigate to plugins>services (within first 50 seconds;)) the qbittorrent service is shown as active;( even though you can't access it from webui. Of course all files were broken after restart;( Tried on rtorrent - same.
Have you tried setting wait for network in LibreELEC network settings?
In my case, rtorrent stores default save path correctly even after restart. But I had to modify rtorrent.rc file for this to work. No json file edit was needed in my case.
On another note and sadly enough, I tried today qbittorrent and issue of rechcking/rehasking files persists with qbittorrent as well;(
Again, I'm starting to believe that this is actually libreelec issue and in which order it mounts the external drives vs starting services. This is another service after deluge, rtorrent and transmission that acts exactly the same after restart. Of course, if a service is stopped manually and libreelec is restarted, everything is fine;(
Also, note this: with say around 50 torrents active, after the reboot, only about 20 return rehash error whilst the rest is seeding ok. That would further point towards issue with timing. It appears as if only some of the files were checked (and returned as missing) seconds after the reboot (when drive was not yet mounted), and then as soon as external usb drive is mounted (a few seconds later), the rest of files returns positive check and torrents are being seeded with no errors.
If someone could provide some hints on how to delay particular service start I could play with it and report back with findings. I don't believe every single tested torrent client has the same problem.
Are you using this Mounting network shares [LibreELEC.wiki] ?
Define the download folder in the settings of the add-on
Sadly this issue has reappeared again. It actually started a week or so ago. I've been trying to solve it but I've come up short. My previous solution was to re-install thoradia repository and deluge and re-position my USB-hub. That doesn't seem to help now, I even exchanged the USB-hub to make sure that wasn't the cause of the issue. Reinstalled Deluge, yet still the same issue. Basically after a few seconds to a few minutes of downloading it grinds to ~0-30KiB/s and when I type "top" it shows that "kworker/u8:" is taking ~20-60 %CPU, the issue with Deluge and kworker taking cpu seems very much linked since they occur at the same time. I don't really know what to do now, any thoughts?
Edit: Uhh huh.. So, I removed the torrent I've been trying to download and added another one instead and it finished without any issues. Could it simply be that specific torrent that was broken or something? I feel like deluge should be able to handle these things, I feel like there's a bug here somewhere.
See with Deluge dev if this is a bug
Consider using qBittorrent