Problem with Transmission after update to 4.0.5a

[Cubytus]

Hi there,

I just updates Transmission as it's the app I use most, but not the firmware as it's still a delicate and complicated process requiring Windows and TFTP.

After restarting the client, I noticed that, while my transfers were still there, download speed is lower (no more than 5MBps instead of the 7 my connection is capable of), and it takes a while for the GUI to update the details of the transfer when displayed. More worryingly, upload is reduced to 0.

Transmission also displays the "Connection failed" warning very frequently, especially on refreshing the page. Sometimes running transfers don't show in the GUI. It's overall very sluggish.

From the command line side,

Code: Select all

htop

reveals transmission-daemon is taking most of the CPU power (78 to 100%).

Any idea what is happening?

[Jocko]

Hi Cubytus,

I just updates Transmission as it's the app I use most, but not the firmware as it's still a delicate and complicated process requiring Windows and TFTP.

No way... To update the firmware just use the firmware update menu from fvdw-sl GUI :shocked

[Jocko]

Hi again,

Just made an additional test, so got a nice dwld speed : ~7,4M/s and transmission used only 23MB of memory...

tr4.0-speedok.jpg

[Cubytus]

My result as to RAM consumption is pretty similar: 38MiB resident, over a much larger number of files. Your CPU usage is also pretty high. The Cloudbox is no powerhouse, but it seems rather high for 5 transfers, 3 of which are active.

One difference though, your view shows transmission-da as child process of transmission-daemon, not sure if that makes any difference or if it reveals something else.

Captura de Pantalla 2024-04-01 a la(s) 13.12.57 .png

Not sure what mdadm is doing here on a single-disk NAS…

As for the update alert, I'm pretty sure I saw it somewhere in the GUI, but now can't find it… Sorry if I misunderstood something, you mean the initial install over original LaCie firmware (or when changing disks) must be done with Windows/TFTP, and that subsequent upgrades can be done in the GUI?

As I read in another topic, since you have image files available for different CPUs, why not make them accessible? At present, it seems it would be easier for many people to just image a blank hard drive rather than use a hardware Windows computer. Many modern computers don't have Ethernet anymore anyway.

[Jocko]

Hi

So several information:

Not sure what mdadm is doing here on a single-disk NAS…

mdadm is a daemon to handle raid events. So no need on a cloudbox. If it is running that would mean it finds an ARRAY configuration in the file /rw_fs/etc/mdadm.conf. So check that

Code: Select all

cat /rw_fs/etc/mdadm.conf

If that is, do:

echo /etc/mdadm.0 > /rw_fs/etc/mdadm.conf

After restarting it should be no longer running

One difference though, your view shows transmission-da as child process of transmission-daemon, not sure if that makes any difference or if it reveals something else.

Indeed up to now I did not notice it. Need to search why (maybe I do not use the same kernel version (for 18.3) as yours. Anyhow, it is a cosmetic issue because the right command line is really running. See

Code: Select all

root@Acrab:/ # ps -U rd
  PID TTY          TIME CMD
 3671 ?        00:00:03 transmission-da
root@Acrab:/ # cd /proc/3671
root@Acrab:/proc/3671 # cat comm
transmission-da
root@Acrab:/proc/3671 # cat cmdline
/usr/local/bin/transmission-daemon-g/share/1100/tr-daemon-w/share/1100/mldonkey/incoming/files
root@Acrab:/proc/3671 #

My result as to RAM consumption is pretty similar: 38MiB resident, over a much larger number of files. Your CPU usage is also pretty high. The Cloudbox is no powerhouse, but it seems rather high for 5 transfers, 3 of which are active.

Yes all seems to be ok. With transmission CPU usage is not really related with the app but the number of simultaneous peer you allow

Sorry if I misunderstood something, you mean the initial install over original LaCie firmware (or when changing disks) must be done with Windows/TFTP, and that subsequent upgrades can be done in the GUI?

That's exactly it and its menu is here :

upgrade-FW.jpg

As I read in another topic, since you have image files available for different CPUs, why not make them accessible? At present, it seems it would be easier for many people to just image a blank hard drive rather than use a hardware Windows computer. Many modern computers don't have Ethernet anymore anyway.

Yes we are working on this way but of course only for a first intallation. Later the user must use the fw upgrade feature

[Cubytus]

Hi Jocko,

thanks for the tips.

So check that

Code: Select all

cat /rw_fs/etc/mdadm.conf

Indeed there is:

Code: Select all

# cat /rw_fs/etc/mdadm.conf
CREATE owner=root group=root mode=0666 auto=yes metadata=1.0
PROGRAM /usr/bin/mdadm-events
DEVICE /dev/sd* /dev/se*

MAILADDR admin@domain.net

Not sure what it's doing here as, long ago when I installed fvdw firmware, I don't recall using any specific option. Maybe it was a bug back then, or in one of the patches? There isn't even a USB port that could have been considered 2nd HDD.

I'll do as you say to disable it. Not that it's taking a great deal of CPU power, but I guess that every little bit helps.

Indeed up to now I did not notice it. Need to search why (maybe I do not use the same kernel version (for 18.3) as yours.

Mine is reported in the GUI as 4.14.133.

Anyhow, it is a cosmetic issue because the right command line is really running. See

Code: Select all

root@Acrab:/ # ps -U rd
  PID TTY          TIME CMD
 3671 ?        00:00:03 transmission-da
root@Acrab:/ # cd /proc/3671
root@Acrab:/proc/3671 # cat comm
transmission-da
root@Acrab:/proc/3671 # cat cmdline
/usr/local/bin/transmission-daemon-g/share/1100/tr-daemon-w/share/1100/mldonkey/incoming/files
root@Acrab:/proc/3671 #

Now that's weird: I don't get the same result in htop than the command line. Mine is:

Code: Select all

# ps -U rd
  PID TTY          TIME CMD
11244 ?        22:23:51 transmission-da
root@fvdwsl-base:/share/1000/tr-downloads/TL # cd /proc/11244
root@fvdwsl-base:/proc/11244 # cat comm
transmission-da
root@fvdwsl-base:/proc/11244 # cat cmdline
/usr/local/bin/transmission-daemon-g/share/1000/tr-daemon-w/share/1000/tr-downloads

As you say, seems to be a cosmetic issue.

That's exactly it and its menu is here :

upgrade-FW.jpg

:woohoo

Still, why would there be such overall sluggishness in Transmission? I did as you suggested in another topic to send everything to the HTTPS port, but only Transmission's GUI gives me timeouts.
Should I upgrade, or try to solve the issues first?