After update to OS 7.0 transmission 4.0.3 runs but cannot connect to trackers

Similar issue has been reported in OS 7.0 is in RC, but it seems passed unnoticed.

No changes to the configuration or firewall rules have been made - just an update.

Transmission daemon runs and reports no errors or warnings in system log (with message-level=3 Debug), just one line:
transmission: Starting with 1031744000 virt mem.

And yet web interface shows that no tracker is accessible - all are stuck at Updating...

Summary

Model: Turris Omnia
Architecture: ARMv7 Processor rev 1 (v7l)
Target Platform: mvebu/cortexa9
Firmware Version: TurrisOS 7.0.0 3547565f245479dc1643ea66828fb55635d49051 / LuCI openwrt-22.03 branch git-24.067.02332-4c1ddfb
Kernel Version: 5.15.148
transmission-daemon: 4.0.3-5

2 Likes

Uninstalling transmission, removing old config, rebooting, installing with default options did not help.

Port is forwarded and checked succefully from web interface.
Pinging any tracker outside of transmission works fine.

There must be something going on with new OS.

Could anybody from turris team shed a light on what might be causing this, please?

At the very least please advise how to install previous version of transmission (where to get turris specific .ipk files).

Thanks.

Hi Hopper,

yes, the same problem was already in RC2.

Old packages are in the archive at Index of /archive/

I myself stayed on the TOS 7 RC1 version where there was no problem yet, but the transmission doesn’t work quite right. CPU is 100% busy.
It’s certainly not a priority for the team and they probably won’t address it.

You have to get your linux ISOs from somewhere…somehow

@czlada
Thank you for the link to the archive.

Tried installing older version (from OS 6.5.2) - but it won’t get installed, complaining about missing dependencies (which seem to be part of OS and are not available as a separate .ipk files).

So rolling back seems like the next best option. But will this revert to old packages or they are not part of the snapshot and then factory reset is the only way out?

And don’t forget to disable automatic updates.

Rollback 7.0.0 → 6.5.1. One click in snapshot a reboot. Disable automatic updates. Transmission work well. :partying_face:

Model: Turris 1.x
Arch: e500v2
Platform: mpc85xx/p2020

1 Like

Guys, do you have some serious solution, other than downgrade for god knows how long and turning automatic updates off? :thinking:

EDIT:
I deployed Transmission to LXC container and it works.

If anybody is interested, I can paste code for the replication.

2 Likes

I have the same problem.
I’m interested in knowing your code

Thanks.

1 Like

@pete here is the testing ipks of transmission v3. For me seems to be fully functional, tried distros torrents.

Reup on google disc:

https://drive.google.com/drive/folders/1inJnwvfk7BMAR5v9BiYmIPKBaUfartHo?usp=sharing

After download untar it and via SFTP send it to router.
Here you can use command: opkg install --force-reinstall transmission…
Then reboot or restart daemon service.

You don’t need to install everything what is in the package, transmission-web and transmission-daemon should be enough. But feel free to test the others, if you are using remote and cli as well.

Testing on your own risk! And let me know if it works for you.

1 Like

Thanks for the super quick turnaround!

I’ve installed daemon and web as per your instructions, but I’m still seeing the high CPU load:

Verified that correct version is installed

  • UI looks like the old version again
  • /usr/bin/transmission-daemon --version shows:
    transmission-daemon 3.00 (bb6b5a062e)

edit: torrents are downloading (and seeding) just fine, just the CPU usage is high

if you try this what @miska recommended?

Tried with that, but still the same 100% CPU.

/usr/bin/transmission-daemon -f -g /srv/transmission --log-error --log-info --log-debug --no-portmap --no-utp

tried disabling dht, utp, encryption, blocklists… still 100% CPU

All right thanks for the info, I will try to investigate more and let’s see if something will appear.

2 Likes

Here’s first lines of the log:

[2024-04-26 12:34:11.734] Transmission 3.00 (bb6b5a062e) started (session.c:769)
[2024-04-26 12:34:11.734] Cache Maximum cache size set to 2.00 MiB (128 blocks) (cache.c:260)
[2024-04-26 12:34:11.734] RPC Server Adding address to whitelist: 127.0.0.1 (rpc-server.c:956)
[2024-04-26 12:34:11.734] RPC Server Adding address to whitelist: 192.168.11.* (rpc-server.c:956)
[2024-04-26 12:34:11.734] RPC Server Adding address to whitelist: 10.111.111.* (rpc-server.c:956)
[2024-04-26 12:34:11.734] RPC Server Serving RPC and Web requests on 192.168.112.1:9091/transmission/ (rpc-server.c:1243)
[2024-04-26 12:34:11.734] RPC Server Started listening on 192.168.11.1:9091 (rpc-server.c:834)
[2024-04-26 12:34:11.734] RPC Server Whitelist enabled (rpc-server.c:1249)
[2024-04-26 12:34:11.734] Bound socket 16 to port 52813 on 192.168.11.1 (net.c:462)
[2024-04-26 12:34:11.734] Bound socket 17 to port 52813 on :: (net.c:462)
[2024-04-26 12:34:11.734] Port Forwarding Stopped (port-forwarding.c:196)
[2024-04-26 12:34:11.734] DHT Initializing DHT (tr-dht.c:338)
[2024-04-26 12:34:11.734] Couldn't read "/srv/transmission/dht.dat": No such file or directory (utils.c:263)
[2024-04-26 12:34:11.734] DHT Generating new id (tr-dht.c:389)
[2024-04-26 12:34:11.734] DHT DHT initialized (tr-dht.c:413)
[2024-04-26 12:34:11.734] Using settings from "/srv/transmission" (daemon.c:646)
[2024-04-26 12:34:11.734] Saved "/srv/transmission/settings.json" (variant.c:1221)
[2024-04-26 12:34:11.734] Watching "/srv/transmission/watch" for new .torrent files (daemon.c:698)

@pete
High load was already in TOS6. But the download worked.

@TomasZak
Why wasn’t it solved in TOS7 RC2 when I reported it?

@czalda feel free to test the older transmission ipk that @TomasZak linked above. Just to see if the download works for you (for me it worked).

Thank you, I already have the version installed from Index of /archive/
TomasZak sent a Omnia version

1 Like

So you have downloads working, but CPU load is still high (on this older version)?