Magnet links are still paused when added (4.0)

[PetersenLars]

What is the issue?

After having this issue since the first 4.0 beta build and updating to the new release, something is still preventing magnet links to automatically start when added. I tried removing preferences and reinstalling, but unfortunately that didn't help. Any other things I could try?

Which application of Transmission?

macOS app

Which version of Transmission?

4.0(280ace12f8)

[CrimsonVex]

I am also having this issue on windows, Transmission 4.0.0 (280ace12f8)

[ckerr]

CC @sweetppro, @Coeur

[Pentaphon]

I am also having this issue on windows, Transmission 4.0.0 (280ace1)

I am also seeing this behavior on Windows 11. Never really used magnets but I did just now and I was shocked to have it show up as paused after downloading the metadata from X peers.

[Coeur]

I noticed this:

• if you kept Transmission open the whole time, then magnet links will start after getting metadata
• if you closed and reopened Transmission, then magnet links will be paused after getting metadata

[mad-tunes]

I've just updated to 4.0.0 (280ace12f8) and see the same. Running as a service on windows server 2022 I've got 'Start added torrents' in preferences ticked & settings.json includes "start-added-torrents": true, but they're left paused. Same when I have the torrent options dialog show and set torrents to start individually from there. Unfortunately this breaks the 'workflow' of using it with the *arr apps to automate downloads

[Pentaphon]

This should really go in the 4.0.1 milestone. I just confirmed it on my 2nd Windows machine.

https://github.com/transmission/transmission/milestone/12

[sweetppro]

@ckerr the fix I provided was macOS specific. It looks like it also needs to be implemented for other systems.

[ckerr]

@sweetppro the person reporting this bug is using the macOS app

[PetersenLars]

Yes exactly, I'm on a Mac mini M1 running on Mac OS 13.1.

[monchote]

I'm having the exact same issue on Linux.

[ckerr]

Yes, I do think it's a problem that exists on multiple platforms :dizzy:

[ehickox]

I am on 4.0.0 and still seeing this on Intel macOS 12.6.

I have "Start when added" enabled. But it does not seem to work.

[GunbleR]

@sweetppro the person reporting this bug is using the macOS app

Had it on fbb98ad. (after https://github.com/transmission/transmission/pull/4528) Tried on freebsd 13.0 (truenas) jail. also on ubuntu 22.04.1 vm.

.torent files start correctly. setting "start-added-torrents": true,

[pstadler]

Same happens for me with docker using linuxserver/transmission:latest (4.0.0). No problem with the latest 3.x release.

[ckerr]

Self-assigning, but I'll probably need an assist on the macOS gui parts.

[programatix]

Similar to @pstadler, docker image linuxserver/transmission:4.0.0 is showing this issue. About shows Transmission 4.0.0 280ace12f8 It's running in my Synology NAS. Was okay before the update from version 3.

As a note, the magnet link did start the download when added, but it will pause after getting the metadata.

So this issue is not platform specific.

[ckerr]

So this issue is not platform specific.

It is and isn't. The macOS client adds torrents into the system in a slightly different workflow than the RPC / Qt / GTK clients so it's kind of two bugs in one :dizzy:

[zero-custom]

a temporary solution: edit settings.json, enable script-torrent-added-enabled, add a new script

#!/bin/sh

sleep 1
/usr/bin/transmission-remote -t $TR_TORRENT_ID -s

[programatix]

a temporary solution: edit settings.json, enable script-torrent-added-enabled, add a new script

#!/bin/sh

sleep 1
/usr/bin/transmission-remote -t $TR_TORRENT_ID -s

Doesn't seem to work for me. Could it be due to mine being password protected. I tried running it at command line and I get,

Unexpected response: <h1>401: Unauthorized</h1>

Updated: I'm missing the --auth user:pass option. Thus, it should be as follow,

/usr/bin/transmission-remote --auth user:pass -t $TR_TORRENT_ID -s

[subhashay]

I'm also facing the same issue on linuxserver docker. Thanks for the workaround for now!

[salvor-hardin]

The number of peers also doesn't seem to work. It goes up to the default 50 and it ignores everything added to the GUI or even the settings.json file.

Adding the peers to the command does fix it as a temp solution /usr/bin/transmission-remote -t $TR_TORRENT_ID --peers 200 -s

[GaryElshaw]

The number of peers also doesn't seem to work. [snip]

@salvor-hardin Please file that as a separate issue, it needs to be examined.

[ckerr]

testers needed, please see the potential fix at https://github.com/transmission/transmission/pull/4856 for links to binaries

[JulienSambre]

a temporary solution: edit settings.json, enable script-torrent-added-enabled, add a new script

#!/bin/sh

sleep 1
/usr/bin/transmission-remote -t $TR_TORRENT_ID -s

Hi! I probably did something wrong, because magnet torrent are still getting paused when metadata has been downloaded.

I added in the config file this :

    "script-torrent-added-enabled": true,
    "script-torrent-added-filename": "/config/fix_paused.sh",

And put this in fix_paused.sh :

sleep 1
/usr/bin/transmission-remote -t $TR_TORRENT_ID -s

I'm using the linuxserver docker image. Do you know what am i missing?

edit : found the mistake : i forgot to add #!/bin/sh at the beginning of the script file => work like a charm now ;).

[brandon-daniels]

Just confirming I have this issue as well. I'm using the linuxserver/transmission docker image. I look forward to the fix! Good work devs

[drizuid]

Just a note from us at Linuxserver.io, this upstream fix won't make it into our container until this is a "release" and/or picked up by alpine in their edge repo. That said, the work-around shown above could be made into a persistent docker mod until that time. https://www.linuxserver.io/blog/2019-09-14-customizing-our-containers if someone would like to create a mod to perform the work-around and PR it, i think it'd help a lot of people.

[SNBogdanov]

I don't know how it should be in 4.0.1 but in transmission-4.0.0-dev+r9d1a141482-x64.msi from Feb 21, 2023 torrent from magnet link stopped to download info completelly. It behave same way as in v 3.0, went to queue to download info if I checked to start, or paused if not.

[Coeur]

@SNBogdanov yes, expected. We had the choice of either a regression for some users, going back to Transmission 3 behavior, or a "many lines change" to address it. We went with the Transmission 3 behavior. The many lines change is in a PR for Transmission 4.1: #4874

[maxz]

We had the choice of either a regression for some users, going back to Transmission 3 behavior, or a "many lines change" to address it. We went with the Transmission 3 behavior.

But that is not how Transmission 3.0 behaved. The magnet links there were active after adding them.

Hopefully this will be fixed for good in 4.1. I tried mitigating it by starting the torrents after adding them via the RPC interface, but this won't work if the info dict has not been retrieved yet and there is no callback or anything alike to help with determining the right time without polling the state repeatedly.

[Coeur]

@ckerr would you want to review https://github.com/transmission/transmission/pull/4874 for an inclusion in 4.0.1 or 4.0.2, to address those concerns?