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.
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?
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).
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.
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.
I searched and found this:
How to delay the VCS startup after a reboot on RHEL 7.3
Try add this on rtorrent.service
TimeoutStartSec=100
ExecStartPre=/bin/sleep 50before 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.
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).
Define the download folder in the settings of the add-on
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?
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
Have you tried setting wait for network in LibreELEC network settings?
It is set, same effect with wait for network enabled and disabled;(
Are you using this Mounting network shares [LibreELEC.wiki] ?
I'm not sure what you mean by using this? Can you explain?
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 ??
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?
I installed couch potato and sonarr from the official repo but what are the ports for these 2 to access the webui?
