Opened 9 years ago

Closed 8 years ago

Last modified 7 years ago

#4692 closed Enhancement (invalid)

RPC, Getting the torrent metainfo

Reported by: drdo Owned by:
Priority: Normal Milestone: None Set
Component: Daemon Version: 2.42
Severity: Normal Keywords: RPC
Cc:

Description

Would it be possible to add a torrent-get field to get the torrent metainfo? (Just like adding torrents sending the metainfo directly)

Change History (9)

comment:1 Changed 9 years ago by livings124

  • Milestone changed from 2.50 to None Set

comment:2 Changed 9 years ago by jordan

What's the use case for this?

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

comment:3 Changed 9 years ago by drdo

Transferring torrents from one daemon to another. Also, the daemon creates torrent files on disk with umask 0077, is it possible to change this?

comment:4 Changed 9 years ago by killemov

The JSON-rpc currently provides a magnetLink property for a torrent. Is that what you mean?

comment:5 Changed 9 years ago by jordan

I'm not following this. What's the use case for transferring torrents from one daemon to another?

comment:6 Changed 9 years ago by killemov

Well one very specific use case is related to transmission-daemon not able to continue downloading once missing files have been detected. (Remove torrent and try again ...) When it's possible to get the torrent file from the daemon itself there is no need to re-download the torrent from the source or ssh into the server to copy/remove/re-add the torrent.

comment:7 Changed 8 years ago by jordan

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

comment:8 Changed 7 years ago by unsignedint

I have a use-case for this (I also think that killemov's use-case is valid too)

It is handy to be able to use Transmission as a ".torrent getter" for magnet URIs. I would like to use Transmission to load up a list of torrents (from magnet uris, urls or base64 encoded data as supported by torrent-add) and instead of downloading the files, just use transmission to scrape the tracker and return a peer/seed/complete count and all the other goodies (like a list of the actual files in the torrent in the case of magnet files) and basically just use it to monitor stats on the files.

Implementing this would allow Transmission to be used as the backend to a "magnet to torrent" converter webservice, as you would be able to add a magnet and then return the corresponding .torrent file. Currently you cant do this from Transmission, you have to monitor its download dir using something else and grab the .torrent file

Would it be difficult to add the "metainfo" to a torrent-get response if it was requested?

comment:9 Changed 7 years ago by unsignedint

Ok I gave this a crack (please bear in mind I am not a C programmer). I am having an issue though, *way* more base64 data than should be is showing up in the RPC response, but the correct data is showing in the console log statements before and after adding to the response dict (proving that the dict isnt ruining the data). I am at a loss to explain why this is happening. The correct data *is* showing up in the response, but appended to it is about 10 times more random data.

Steps to produce: 1. Compile. 2. Run transmission-daemon. 3. Add torrent from magnet and wait for metadata to complete. 4. Do a "torrent-get" rpc call with "metainfo" as one of the fields.

Index: libtransmission/rpcimpl.c
===================================================================
--- libtransmission/rpcimpl.c	(revision 14215)
+++ libtransmission/rpcimpl.c	(working copy)
@@ -711,6 +711,22 @@
         tr_variantDictAddReal (d, key, st->metadataPercentComplete);
         break;
 
+      case TR_KEY_metainfo:
+        {          
+          if (tr_torrentHasMetadata(tor)) {    
+            size_t len = 0;
+            uint8_t *file = tr_loadFile(inf->torrent, &len);
+            char* b64 = tr_base64_encode(file, len, NULL);
+            tr_logAddInfo("Before dict: %s", b64); //prints the correct base64
+            tr_variantDictAddStr(d, key, b64);
+            const char* after;
+            tr_variantDictFindStr(d, key, &after, NULL);
+            tr_logAddInfo("After dict: %s", after); //still prints correct base64
+            tr_free(b64);
+          }
+          break;
+        }
+
       case TR_KEY_name:
         tr_variantDictAddStr (d, key, tr_torrentName (tor));
         break;
Note: See TracTickets for help on using tickets.