Opened 7 years ago

Last modified 3 years ago

#4808 new Enhancement

Make it possible to choose what files to download after getting magnet metadata

Reported by: OsamaK Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.42
Severity: Normal Keywords: patch-needed
Cc: djvasi@…, abacabadabacaba@…, jdkatz23@…, trac.transmissionbt.com@…, hohyeis@…

Description

When a magnet link is used, there is no option to choose what files to download without waiting for the metadata to be fetched then pausing Transmission after it starts download all files.

I suggest adding an option into the "Torrent options" dialog that is shown when a magnet link is added that says something like "Fetch metadata then show torrent options" or "Fetch metadata then ask" below "Start when added".

Attachments (1)

get-mag-files.patch (4.7 KB) - added by cfpp2p 7 years ago.

Download all attachments as: .zip

Change History (33)

comment:1 Changed 7 years ago by synthesis77

Just signed up to file this bug (oddly, I couldn't find it before). In any case, this would be great to have. Transmission just hung because it exceeded my disk free space downloading a magnetized transfer. Since I didn't have a chance to pick files once the metadata had downloaded, it allocated space for all 20 files.

OsamaK's right on here -- it needs another option besides "Start when Added". I'd recommend adding a "Download Metadata when Added" checkbox before the "Start when Added" box.

Also occurs on 2.50.

comment:2 Changed 7 years ago by rameshkumar

This feature is really needed. Anyway other clients are solving this problem by downloading the requisite data from magnet links (at a higher priority than all other downloads by the client in order to quickly download) to allow user to select files to be downloaded in a pop up window and then letting the user add the torrent job from there.

Now for some magnets it may be fast to download info but for some it may be slow. So I suggest giving users an option to enable/disable this feature. Also one can set a time limit for pop up prompt so that if info is not received in that time, it will be added to the job list after notifying the user.

comment:3 Changed 7 years ago by gbentley111

  • Cc gbentley111@… added
  • Component changed from Transmission to Mac Client
  • Owner set to livings124
  • Priority changed from Normal to High
  • Version changed from 2.42 to 2.50+

I also would like this issue to be fixed in an upcoming build. I am running nightly builds and as of March 28, 2012 it still has not been fixed. Otherwise, Transmission is great!

comment:4 Changed 7 years ago by livings124

  • Component changed from Mac Client to Transmission
  • Owner livings124 deleted
  • Priority changed from High to Normal
  • Version changed from 2.50+ to 2.42

comment:5 Changed 7 years ago by jordan

  • Type changed from Bug to Enhancement

comment:6 Changed 7 years ago by vasi

  • Cc djvasi@… added

comment:8 Changed 7 years ago by x190

See comment:2 of this ticket for what is needed.

comment:9 Changed 7 years ago by hobarrera

A "download metadata only" that pauses the torrent (instead of starting downloads) after downloading the metadata sounds like an easier solution. It also covers cases in which metadata takes way too long to download for a user to wait around.

Changed 7 years ago by cfpp2p

comment:10 Changed 7 years ago by cfpp2p

Here is a patch that that adds "prefetch-magnets-enabled": setting to settings.json, AND when this is set to true torrents pause AFTER the metadata is acquired only IF torrent is started in a paused state:

i.e. web client:http://www.computerfixpro.com/start-when-added.JPG

RPC: "torrent-add" "paused" | boolean if true, don't start the torrent

tranmsission-remote --start-paused

settings.json "start-added-torrents": false,

Queuing is correctly followed in that a queued torrent will NOT pause after retrieving metadata. Pausing then resuming a torrent still in the retrieving metadata state cancels the pause after metadata acquisition.

With "prefetch-magnets-enabled" false default behavior remains.

note: some third party add-on clients like transmission-remote-GUI always load the torrent in a paused state while waiting in the 'parameters window when adding a new torrent'. Wait for the metadata acquisition there then check/uncheck the Start torrent box for correct behavior.

Last edited 7 years ago by cfpp2p (previous) (diff)

comment:11 Changed 7 years ago by rb07

I don't think this should be a "preference", neither an option, it seems to be a flaw:

If you load a torrent using an URL and the option "start paused" is set, Transmission downloads the metadata, creates the torrent, and sets its state to paused.

Now if you load a torrent using a magnet link (which is just another kind of URL), with the option "start paused" set, transmission doesn't download the metadata, it just uses the partial metadata on the magnet and puts some kind of in-place torrent (which usually doesn't even show the torrent name, no file list to choose), and sets the state to paused. This "in-place torrent" is what all the complaints are all about.

To me that is inconsistent operation, URL and magnet should behave the same. Besides, the "in-place torrent" is not useful.

comment:12 Changed 7 years ago by cfpp2p

rb07

Now if you load a torrent using a magnet link (which is just another kind of URL), with the option "start paused" set, transmission doesn't download the metadata, it just uses the partial metadata on the magnet and puts some kind of in-place torrent (which usually doesn't even show the torrent name, no file list to choose), and sets the state to paused. This "in-place torrent" is what all the complaints are all about.

with patch get-mag-files.patch the metadata IS downloaded as you describe for:

If you load a torrent using an URL and the option "start paused" is set, Transmission downloads the metadata, creates the torrent, and sets its state to paused.

with the patch provided the magnet link torrent is complete and you can choose the files to download

so I don't understand what you are doing? rb07 -- are you referring to the current transmission implementation or the provided patch. If you are referring to current transmission implementation I agree, a flaw.

Last edited 7 years ago by cfpp2p (previous) (diff)

comment:13 Changed 7 years ago by rb07

cfpp2p:

I'm not talking about your patch, I'm talking about the current release.

But talking about your patch I think its wrong, as I said, it is not a preference, its just a flaw that should be corrected.

I understand where the flaw comes from, the URL is faster (usually) to download than the magnet, but as your patch proves it is not a problem. In other words, it should behave like what your patch does always (when "start paused" is set), not as a preference.

comment:14 Changed 7 years ago by x190

"(when "start paused" is set), not as a preference."

Agreed. That should work for Mac Client users as well.

comment:15 Changed 7 years ago by abacabadabacaba

  • Cc abacabadabacaba@… added

comment:16 Changed 7 years ago by cfpp2p

With a patch to enable the enhancement wanted with this ticket it is pretty easy to fix #4089 also.

comment:18 Changed 7 years ago by eris23

  • Cc jdkatz23@… added

comment:19 Changed 6 years ago by nate4096

+1

I just spent about 10 minutes scouring for the option, not believing it could be missing. I'd say it happens more often than not that I want to cherry pick specific files within a torrent. It's bad enough to wind up with partial files at all, but the instant allocation of the entire file size makes the situation even worse.

I really like the look and feel and Transmission (I'm on Mac), but this lack of magnet file selection is so severe an impediment to my torrenting workflow that I'll likely be switching away in the meantime. It's just too much effort to workaround this issue.

comment:20 Changed 6 years ago by x190

nate4096: You might want to test this unofficial build which should have those features.

comment:21 follow-up: Changed 6 years ago by gbentley111

x190: do you know if those features are also in the latest nightly build (14038)? The link you sent was for build 13960.

comment:22 in reply to: ↑ 21 Changed 6 years ago by x190

Replying to gbentley111:

x190: do you know if those features are also in the latest nightly build (14038)? The link you sent was for build 13960.

They are not. These are unofficial builds that have been well-tested by a small group who hope to see these features become official eventually. :-)

comment:23 Changed 6 years ago by mike.dld

  • Keywords patch-needed added; patch needed removed

comment:24 Changed 5 years ago by iiiGerardoiii

This feature must be added ASAP, I repeat, this feature must be added ASAP.

comment:25 Changed 5 years ago by Renara

I just posted issue #5664 which was closed as a sort-of duplicate of this issue. In my proposal I was more concerned with getting torrent metadata when a download queue is in use, as currently the torrent will sit there with no metadata until it gets a slot in the queue.

Anyway, I just wanted to note that I think the best behaviour would be that magnet URIs are added in a special "prefetch" state. This is essentially the same as any active magnet URI now, but will allocate peers at a higher than normal priority up to some limit (25% of global peers?), leaving any other peers to be taken by active torrents first only being allocated to prefetching torrents if nothing else requires them. Basically we want to avoid large numbers of magnetised transfers eating up resources and starving active torrents, while still making an effort to prioritise them so they can get their metadata sooner. Now I don't know how Transmission allocates peers to metadata downloads, but I think there should be some upper limit on peers assigned to do-so, after all you only need one peer in theory to download metadata from, though a limit of say 6 might help to speed up the process.

Once the metadata is fetched, I think there should be a separate setting that determines whether magnetised transfers are started straight away, paused, or paused with a dialogue (for GUI clients). The latter two options of course allowing settings such as files to be tweaked before the transfer actually begins. If a download queue is active then they should be added to this as normal once started properly.

comment:26 Changed 5 years ago by gene_wood

  • Cc trac.transmissionbt.com@… added

comment:27 Changed 5 years ago by dakiri

  • Cc hohyeis@… added

comment:28 Changed 5 years ago by gbentley111

  • Cc gbentley111@… removed

comment:29 Changed 4 years ago by seyyed

Hi guys,

Could someone update this patch?

Thanks

comment:30 follow-up: Changed 4 years ago by geoff-codes

I cannot believe this hasn't been implemented. Came here just like the dozens before me to request this same thing. Looks like its a defacto wontfix?

Anyway, just as well, just found http://magnet2torrent.com, which works for my purposes.

comment:31 Changed 4 years ago by apistoletov

Opened 4 years ago

I cannot believe this hasn't been implemented. Came here just like the dozens before me to request this same thing. Looks like its a defacto wontfix?

comment:32 in reply to: ↑ 30 Changed 3 years ago by cfpp2p

Replying to geoff-codes:

I cannot believe this hasn't been implemented. Came here just like the dozens before me to request this same thing. Looks like its a defacto wontfix?

Anyway, just as well, just found http://magnet2torrent.com, which works for my purposes.

At #6096 there's a patch to integrate directly magnet2torrent type processing into the web client.

Also if a magnet becomes hung for whatever reason
"It never downloads the meta data (size and file names)."
( https://forum.transmissionbt.com/viewtopic.php?f=4&p=73292#p73283 )
the #6096 patch could help alleviate that too.

Note: See TracTickets for help on using tickets.