Opened 9 years ago

Closed 6 years ago

Last modified 5 years ago

#4710 closed Enhancement (wontfix)

Automatically parse a text file in "watched" folder for magnet links

Reported by: akira28 Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.42
Severity: Normal Keywords: Magnet
Cc: basso.zeca@…, amontero@…


Now that TPB is abandoning torrent files it will be difficult for solutions based on the "watched" folder (using Dropbox for example). A solution could be to search for .txt files, named after the torrent name, and containing the magnet link for the torrent. Then if it's correct apply the same behaviour chosen for .torrent (destroy the txt or leave it there). Another solution could be a single txt file (magnets.txt ?) containing a link each line.

Change History (22)

comment:1 Changed 9 years ago by livings124

This doesn't make sense. Just click the button in prefs to open magnet links in Transmission by default.

comment:2 Changed 9 years ago by livings124

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

comment:3 Changed 9 years ago by showrss

  • Resolution wontfix deleted
  • Status changed from closed to reopened

It does make a lot of sense.

For instance, many people use automating software and scripts to automatically download torrent files to the «Watch» folder. Transmission automatically adds torrents from there.

If torrents start disappearing (as it seems they will — that isn't a bad idea, but yet not every client is ready for that) a good measure would be to allow loading magnet links in a similar way as we currently do with files.

That would be a simple text file containing the magnet link, which Transmission would then treat in a similar way as it does with other .torrent files in the watch folder.

For instance, headless transmission instances could survive a little longer. Only a few (well, I suppose, for now I can't name any) non-desktop clients support magnet links.

As a note, watch folders and seeds being a file is a strong point for torrent versus other file sharing solutions. Just try to keep both solutions valid whether is with magnets or with torrents.

(As a note: I maintain showRSS, donate as an individual to this project and use Transmission on a daily basis on my two Macs. Definitely this feature would mean a lot for the cause supporting magnets — for example, we can generate «magnet files» on the fly).

comment:4 Changed 9 years ago by akira28

Maybe I didn't explain myself. This happens when you don't have access to your transmission (NAT?), or when using tools like flexget+showrss

comment:5 Changed 9 years ago by jordan

transmission-via-dropbox is a nice combo that some people use.

I agree it would be nice to have an equivalent mechanism in the magnet link world, but I'm not sold on the idea of scanning text files. For one thing, the advantage of the "dropbox" approach is that you can save a .torrent to a dropbox folder directly from a web browser. What's the equivalent of that in the magnet link world? "save as" doesn't work for magnet links.

comment:6 Changed 9 years ago by MariusTh86

While "Save as" doesn't work, I believe most browsers do support dragging and dropping links from the browser to the desktop. For example, dragging a magnet link from Safari on a Mac to my desktop created the file "Get this torrent.inetloc", which would lead to the magnet link.

Maybe something can be done using this?

comment:7 Changed 9 years ago by rb07

This can be accomplished with a script (transmission-remote allows adding magnet links).

Something like this untested little script:

# Read the last line of file, and try to add it to transmission-daemon
# Assume transmission-remote is in the PATH.

TR_OPTIONS=" -n admn:psswrd --downlimit 500 --uplimit 50"

# Exit if there is no file
[ ! -f "magnets.txt" ] && exit

cat $FILE |
while read m
  transmission-remote $TR_OPTIONS --add "$m"

# Remove the file
rm $FILE

It needs more work to avoid reading files that are being written to. Some kind of synchronization between the writing program and this script.

comment:8 Changed 9 years ago by mk.fg

On the "doesn't make any sense" topic - I have transmission only on a remote, constantly-enabled box, not on a laptop or tablet, but I do mount sshfs from that box.

Opening RPC port for these clients have three disadvantages - +1 potentially exploitable port, needs +1 (from shared-fs) separate auth, needs rpc client (transmission-remote, for example) on a client. Using web interface doesn't have the last disadvantage (although something that'd do POST to it might be considered to be a client as well), but suffers from the rest.

Magnet links otoh don't have a canonical file format (afaik), so watching for them would require creating yet another transmission-specific format/protocol, so honestly, I think rb07's "interface script" approach is a good enough solution.

comment:9 Changed 9 years ago by killemov

Maybe have a more public discussion here: ?

As for some technical insight, I would recommend (urge) using the .magnet suffix for any text file containing magnet links and use the .magnet.added suffix for processed files.

comment:10 Changed 8 years ago by livings124

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

This is better suited by a script, as discussed in the linked forum thread.

comment:11 Changed 8 years ago by killemov

  • Resolution wontfix deleted
  • Status changed from closed to reopened

The linked forum thread has had no real input whatsoever since I started it. The lack of input might be an indicator of the level of importance of this issue. There is no decision or even grounds for a decision whatsoever in the mentioned forum thread.

It all comes down to developers doing the work once or users doing the work themselves each and every time. As mentioned before, the script solution is a mere workaround. I could write a patch for it myself, but I would need a pretty solid OK on the acceptance of it before I even consider doing it.

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

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

This is something very few users would use, which is why it's better suited for a script.

comment:13 in reply to: ↑ 12 Changed 8 years ago by basso.zeca

  • Cc basso.zeca@… added

Replying to livings124:

This is something very few users would use, which is why it's better suited for a script.

Actually no user will use it if it is not implemented. This would e extremely useful for instance in a headless RaspberryPi? in conjunction with Dropbox or BTSync watch folder or whatever.

comment:14 Changed 8 years ago by pathetic_loser

  • Resolution wontfix deleted
  • Status changed from closed to reopened

As for me, I would use this feature for sure. That's exactly what I need. Sure, it's possible to do via scripts + RPC but it's really complicated for "Average Joe". On other hand even Average Joe could want to get recent stuff from some subscription. And since more and more people moves from torrent files to magnet lings (as they're far more convenient), such feature is really welcome. Forcing people to reinvent the wheel for watching magnets is not a great idea at all.

comment:15 Changed 8 years ago by livings124

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

This is still an obscure feature that can already be managed through scripts. Building in support for every torrent setup is not something we want to do.

comment:16 Changed 8 years ago by shindigg

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Still reasons to support this.

  1. There has been a fair amount of desire expressed in discussions elsewhere:
  2. Given how often Transmission in used in in embedded systems and media centers, this is particularly useful in common use cases.
  3. This could also be done in a more standardized approach by watching for .webloc (Mac) or .weblink (Windows) files which are simple formats for saving URLs. Those formats are created when dragging a magnet link to a desktop from a browser.
  4. This would enable Transmission to support the have greater parity of features for .magnets and .torrent files
    • Watch folder for magnet link
    • Default location same as magnet link

comment:17 Changed 8 years ago by livings124

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

Sorry, this is still outside the scope of the app, and can be easily handled with scripts.

comment:18 follow-up: Changed 7 years ago by x190

For a patch see:


    diff -rupN orig2/daemon/daemon.c orig/daemon/daemon.c
    --- orig2/daemon/daemon.c       2014-10-13 22:24:47.619262656 +0300
    +++ orig/daemon/daemon.c        2014-10-13 22:24:59.835910372 +0300
    @@ -264,7 +264,16 @@ onFileAdded (tr_session * session, const
         char * filename = tr_buildPath (dir, file, NULL);
         tr_ctor * ctor = tr_ctorNew (session);
    -    int err = tr_ctorSetMetainfoFromFile (ctor, filename);
    +    int err;
    +    if (tr_str_has_suffix (file, ".torrent"))
    +        err = tr_ctorSetMetainfoFromFile (ctor, filename);
    +    else {
    +        char * link;
    +        size_t    len;
    +        link = (char*)tr_loadFile (filename,&len);
    +        err = tr_ctorSetMetainfoFromMagnetLink (ctor, link);
    +        tr_free(link);
    +    }
         if (!err)
    diff -rupN orig2/daemon/watch.c orig/daemon/watch.c
    --- orig2/daemon/watch.c        2014-10-13 22:24:47.619262656 +0300
    +++ orig/daemon/watch.c 2014-10-13 22:25:06.229233796 +0300
    @@ -85,7 +85,7 @@ watchdir_new_impl (dtr_watchdir * w)
                 const char * name = d->d_name;
    -            if (!tr_str_has_suffix (name, ".torrent")) /* skip non-torrents */
    +             if (!tr_str_has_suffix (name, ".torrent") && !tr_str_has_suffix (name, ".magnet") ) /* skip non-torrents */
                 tr_logAddInfo ("Found new .torrent file \"%s\" in watchdir \"%s\"", name, w->dir);
    @@ -135,7 +135,7 @@ watchdir_update_impl (dtr_watchdir * w)
             while (i < len) {
                 struct inotify_event * event = (struct inotify_event *) &buf[i];
                 const char * name = event->name;
    -            if (tr_str_has_suffix (name, ".torrent"))
    +            if (tr_str_has_suffix (name, ".torrent") || tr_str_has_suffix (name, ".magnet") )
                     tr_logAddInfo ("Found new .torrent file \"%s\" in watchdir \"%s\"", name, w->dir);
                     w->callback (w->session, w->dir, name);
    @@ -216,7 +216,7 @@ watchdir_update_impl (dtr_watchdir * w)
                 if (!name || *name=='.') /* skip dotfiles */
    -            if (!tr_str_has_suffix (name, ".torrent")) /* skip non-torrents */
    +            if (!tr_str_has_suffix (name, ".torrent") && !tr_str_has_suffix (name, ".magnet") ) /* skip non-torrents */
                 len = strlen (name);

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

comment:19 Changed 6 years ago by devon

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I recently submitted a ticket (enhancement) regarding the option to disable all network traffic (including DHT) especially using the scheduler (this has been another popular request). It was dismissed suggesting to using a cron job to start and stop transmission. However using the script for adding magnet links as suggested would only work while transmission is running. I could get it to run after transmission has started but then if I want to add one when it is already running, i'd have to check if transmission was running or not and either que it or add it. This starts to become more than just a simple one line script. It also becomes more than simply copying a config file for setting up other servers.

As was mentioned, it would make more sense to incorporate this kind of useful functionality into transmission and document it then for each person to have to search/figure out/re-invent the wheel for each setup. Judging by the amount of attention this has received (and these are only the people devoted enough to bother making an account and adding their feedback), I'd say this is a worth while investment to improve an already great tool.

comment:20 Changed 6 years ago by livings124

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

I'm standing by being suited for a script.

comment:21 in reply to: ↑ 18 Changed 6 years ago by cfpp2p

but of course there is a patch that works quite nicely ;)

comment:22 Changed 5 years ago by amontero

  • Cc amontero@… added

Swithcing from .torrent files to magnet URIs while using a convenient/custom/geeky sync-via-files solution brought me to this thread when googling. I just expected this to be present, out of expecting feature parity between files/magnet and I must confess that surprised me.

Just +1 to magnet links watching, in case feedback about the use-case is worth sharing.

I understand the 'more code to maintain' position, but the feature benefits outweigh the costs and it's not an unreasonable thing to expect from the UX, IMHO. Scripts can become unreliable and cumbersome to some users and this would make happy a lot of users. I agree with magnet-link backers, and would like to ask developers to reconsider this. TIA.

Note: See TracTickets for help on using tickets.