Thoradia Add-ons

  • yeah, it seems the problem with rtorrent occurs when rtorrent service shutdown is enforcecd by system and not by user (weird!). If its manually enforced by any of the below, it's fine:

    systemctl stop service.rtorrent.service

    systemctl start service.rtorrent.service

    systemctl restart service.rtorrent.service

  • Hi!

    I'm having some issues with Deluge on my Odroid C2 running CoreElec. Basically it grinds to a halt after a few minutes. It can go from ~5MiB/s download to ~2KiB/s Download and just stay there. When I run the 'top' command I can see that "kworker/u8:1" takes around ~70% CPU. I tried searching for it and in order to figure out what exactly that kworker thing is doing I seem to need perf which as far as I know can't be installed on CoreElec?

    If I restart my Odroid C2 it works just fine for several minutes, then that kworker/u8:1 shows back up, first at ~15% CPU and deluge seems fine, then 30%, then 50% and when it reaches 70% deluge basically breaks. The downloads grind to a halt and I can't add new torrents, they get added but they get stuck in "Checking 0.00%" forever.

    My setup is an Odroid C2 running CoreElec 8.95.6, I have two external drives connected to a powered USB hub, a Sony Wireless Adapter to communicate with my DualShock 4 controller, network through Ethernet and power through the EU power supply from hardkernel.

    Any idea what the issue is here or how I could go about troubleshooting it?

    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.

    Edited once, last by Sanya (March 2, 2019 at 3:37 PM).

  • 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

  • See with Deluge dev if this is a bug

    Consider using qBittorrent

    qBittorrent doesn't have any standalone client as far as I understand? A standalone client is a requirement for me, I hate using web-interfaces, rather clunky IMO (biggest reason is that I haven't been able to get them to act as handlers for magnet links, and I use a lot of magnet links and it would be a PITA to copy paste that many magnet links, maybe I've just gone about it wrong?) I'll continue monitoring to see if the issue occurs again and test more with different torrents to see if the issue is dependent on torrents and then consider making a bug report when I have more data. For all I know it could be some setting I use in Deluge that only becomes relevant for certain torrents, maybe a certain number of connections or something? Are there any recommended settings for Deluge on an Odroid C2?

    Edited once, last by Sanya (March 3, 2019 at 12:06 PM).

  • Another thing I noticed is it the download folder always change to default (/storage/.kodi/userdata/addon_data/service.transmission/downloads) when I reboot the system. At least in Transmission client.

    thoradia what you think about this issue and januszmirek issue too? You think is related with the torrent client and not with your add-ons?

    If yes where is the file settings.json of Transmission, maybe there I can change the folder (I searched but don't finded).

  • thoradia

    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?

  • thoradia what you think about this issue and januszmirek issue too? You think is related with the torrent client and not with your add-ons?

    If yes where is the file settings.json of Transmission, maybe there I can change the folder (I searched but don't finded).

    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.

    Edited once, last by januszmirek (March 4, 2019 at 2:00 PM).

  • 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.

    thoradia  januszmirek

    I searched and found this:

    035524.html

    How to delay the VCS startup after a reboot on RHEL 7.3

    Try add this on rtorrent.service

    Code
    TimeoutStartSec=100
    ExecStartPre=/bin/sleep 50

    before ExecStart command.

    I don't know if it work, I'm not at home now to test. This is to make the service wait 50s before starting.

    You can found the services on /.config/system.d

    About settings.json: I think this is the configuration file of Transmission, but don't know for sure.

  • No joy;(. I tried

    TimeoutStartSec=50

    tExecStartPre=/bin/sleep 50


    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.

  • 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] ?

  • No joy;(. I tried

    TimeoutStartSec=50

    tExecStartPre=/bin/sleep 50


    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?

  • thoradia

    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

  • januszmirek you use radarr/sonarr? Maybe this is causing you issue (image). If yes, try not rename files to test.

    Or if rtorrent have no especially function that you use, try to migrate for Transmission. I use it with external disk and had no issues about this.

    And if nothing this solve try uninstall and install again torrent client (and maybe LibreELEC itself), because here is working normal!

    (Raspberry Pi 3b hardware here)

  • Milhouse builds are early development builds

    You should be happy anything runs on them

    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 ??

    Edited once, last by witek666 (March 9, 2019 at 11:18 AM).

  • The issue with the slowdowns and high cpu usage of kworker seems to still occur sadly. At this point I've pretty much given up on using deluge on the odroid C2.

    Can qBittorrent web interface be used as a handler for magnet links such that clicking magnet links causes them to be opened in qBittorrent? I guess I should try and see if qBittorrent exhibits the same issue first.

    Edit: Sadly the same issue seems to be occurring with qBittorrent. This suggests to me there's probably something wrong with my Odroid C2, my USB-hub (tested two different ones) or my hard-drive? I doubt it's the hard-drive since the same issue occurs on the other hard-drive I have connected as well. So it's probably either my Odroid C2 or my USB-hub, in case it's the USB-hub then it's an issue that has happened between two different ones (same model, have two of them.) This is probably beyond the scope of this thread at this point but any thoughts of how I could go about troubleshooting this further?
    Edit 2: I'm currently testing with the other drive and the chromecast unplugged from the USB-hub in case it's an issue with power consumption between the two or something like that.
    Edit 3: I feel stupid. My USB-hub is rated at 2A output. A Chromecast itself can draw up to 2A as I understand it. Most likely two harddrives and a chromecast was too much power draw for the USB-hub which resulted in this problem.
    Edit 4: Downloaded fine with just the one harddrive connected, two harddrives caused problems though.

    Edit 5: Down to just the one harddrive yet the issue just happened again. I think it's about time to give up on this.

    Edit 6: Could it perhaps be the drive itself? In that case, how do I test it?

    Edited 6 times, last by Sanya (March 9, 2019 at 9:17 PM).