Opened 12 years ago

Closed 9 years ago

#3253 closed Enhancement (invalid)

Prefetching of magnetized metadata right away

Reported by: ghreat Owned by:
Priority: Low Milestone: None Set
Component: Transmission Version: 1.93+
Severity: Minor Keywords: patch needed, metadata, magnetized
Cc:

Description

I think it would be good if transmission fetches the torrent metadata when adding a magnetized transfer regardless of whether or not you want to download the torrent right away. That way you can decide which parts you want to download before starting the torrent, see how big it is, etc.

Right now it won't fetch the metadata until the torrent is started/unpaused.

Attachments (1)

prefetchMagnet.patch (3.4 KB) - added by cfpp2p 9 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 follow-up: Changed 12 years ago by livings124

  • Resolution set to invalid
  • Status changed from new to closed

There is little difference between getting the metadata and downloading. You still need to connect to trackers (or DHT, PEX, etc.), retrieve and connect to peers, and so on. Doing all of this, and then essentially pausing is messy at best; ban-worthy at worst.

comment:2 in reply to: ↑ 1 Changed 12 years ago by ghreat

Shame, as it is annoying that it starts to download the parts you don't want (as well as the parts you do) before you have the chance to choose.

comment:3 Changed 12 years ago by deadeyes

I also would like this feature to be build in. Now I have to start downloading before I select file.

So down on usability and a no-go for using magnet links.

comment:4 Changed 9 years ago by ewtoombs

  • Priority changed from Normal to Low
  • Resolution invalid deleted
  • Severity changed from Trivial to Minor
  • Status changed from closed to reopened
  • Version changed from 1.93+ to 2.61+

It is not messy. It is not even close to ban-worthy. Metadata retrieval is a perfectly valid reason to communicate with peers. And anyway, it is very (very very very) likely that the file in question is about to get started in earnest about ten seconds after the metadata is fetched and the desired files are selected. A ten second gap between metadata fetch and download is not ban-worthy. Not even a metadata fetch without a subsequent download. Not even close.

Here's the current way to selectively download from magnetised swarms. You start the download, nurse it for half a minute until the metadata has been retrieved (yes, it takes that long for some of us), frantically pause the torrent before it allocates anywhere up to 100 gigs of empty space on your hard drive, select the files you want, start it again, and finally delete all of the empty files it created that you never wanted to download, if any, before you had the time to pause the damned thing. THAT's messy.

Metadata prefetch is a valuable feature that should be implemented, as it would massively facilitate selective downloading from magnetised swarms.

comment:5 Changed 9 years ago by livings124

  • Version changed from 2.61+ to 1.93+

comment:6 Changed 9 years ago by porg

+1. Would love to have this feature. Often angered about the automatic download start of torrent parts I don't desire at all. Put the user into control!

comment:7 Changed 9 years ago by jordan

  • Resolution set to invalid
  • Status changed from reopened to closed

I agree with livings124 on this one

comment:8 Changed 9 years ago by porg

livings124 & jordan, to me you seem to have a technical/performance perspective/bias.

  1. Why not first only fetch metadata,
  2. then pause ("giving up the good established connection")
  3. let the user choose what S/HE wants (sovereignty!)
  4. then resume ("at the time penalty of re-establishing a connection" )
  5. … some time passes by ...
  6. Later unselect unwanted parts within Transmission, or remove unwanted files with your fiel browser (to gain HD space again). Can be more time consuming then (2) the pause would take.

From a usability POV, the balance of 2/4 is clearly in favor of 4. How is it from a technical POV? With that new given arguments, can you still defend your rejection?

comment:9 Changed 9 years ago by cfpp2p

  • Keywords patch needed added

Logically it doesn't make sense to have the option to DE-select files with magnet links with transmission as it stands right now. It is left up to random whether the DE-selected will actually NOT be allocated anyway. NOW the above really doesn't make sense at all either. The only way I see to remedy is to allow the pre-fetch of magnet metadata so that the option to DE-select is not left to random.

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

comment:10 Changed 9 years ago by ewtoombs

  • Resolution invalid deleted
  • Status changed from closed to reopened

livings124 & jordan: To me as well, it sounds as though you have rejected this unmistakable improvement because it is very difficult to implement with the way Transmission is currently designed. If this is true, I understand your reaction. I myself also have more important things to do, honestly. But at least acknowledge that this feature is strongly desired and is ultimately what the user ends up having to do themselves, only in a very manual way (see my original comment). You don't have to implement this enhancement, but the enhancement should still nonetheless stay unresolved (and unassigned of course) so that some ambitious altruist who does can find it more easily, when filtering tickets for unresolved enhancements.

Last edited 9 years ago by ewtoombs (previous) (diff)

Changed 9 years ago by cfpp2p

comment:11 follow-up: Changed 9 years ago by cfpp2p

Here is a simple patch that adds a "prefetch-magnets-enabled": setting to settings.json. When this is set to true EVERY magnet is automatically paused after the metadata is 100% acquired. A better patch would include a patch for rpcimpl allowing RPC to change the prefetch-magnets-enabled": setting and also take into account download queuing. But this has been a nice functionality for me and works well with #532.

comment:12 in reply to: ↑ 11 Changed 9 years ago by ewtoombs

Replying to cfpp2p:

Here is a simple patch that adds a "prefetch-magnets-enabled": setting to settings.json. When this is set to true EVERY magnet is automatically paused after the metadata is 100% acquired. A better patch would include a patch for rpcimpl allowing RPC to change the prefetch-magnets-enabled": setting and also take into account download queuing. But this has been a nice functionality for me and works well with #532.

Wow, what a great idea. Actually, this is all we really need. That and a single check box in the configuration settings: "Automatically pause magnet: torrents after metadata is downloaded?" or words to that effect. What I had in mind was much more complicated. It involved downloading the metadata, then displaying the list of files where one would see them in the "Open" dialog if it were a regular torrent file. It is a little nicer, but much more complicated. I have a question though. Which version should this patch be applied to? I will guess the most recent edition in version control, for now. Thankyou so much for the idea and for the patch!

comment:13 Changed 9 years ago by jordan

  • Resolution set to invalid
  • Status changed from reopened to closed

cfpp2p's patch would be a good start if livings and I agreed with the feature, but I think the feature is more bad than good.

My main complaint with this feature is initiating network traffic without the user's permission. This has happened in the past for example when people didn't understand DHT's network overhead.

In addition, there's the question of fixing it to *not* automatically pause magnet links, of how stalled magnet links should behave wrt queueing, and of course of exposing this on/off switch via the Mac, GTK+, Qt, and RPC interfaces.

Note: See TracTickets for help on using tickets.