Option to Automatically Verify Local Data on Completion

[cfpp2p]

patch adds settings.json element "reverify-torrents-tries" which if greater than zero will reverify on completion until successful 100% verify or reverify-torrents-tries times at which time torrent is paused with error 'Reverify count exceeded - pausing torrent -- resetting retries'. After this error message restarting the torrent then again starts with original reverify-torrents-tries count. Default is 0, edit settings.json "reverify-torrents-tries": 0, to greater than 0 to enable reverify.

Code: Select all

Index: quark.c
===================================================================
--- quark.c	(revision 14206)
+++ quark.c	(working copy)
@@ -277,6 +277,7 @@
   { "rename-partial-files", 20 },
   { "reqq", 4 },
   { "result", 6 },
+  { "reverify-torrents-tries", 23 },
   { "rpc-authentication-required", 27 },
   { "rpc-bind-address", 16 },
   { "rpc-enabled", 11 },
Index: session.c
===================================================================
--- session.c	(revision 14206)
+++ session.c	(working copy)
@@ -351,6 +351,7 @@
   tr_variantDictAddReal (d, TR_KEY_ratio_limit,                     2.0);
   tr_variantDictAddBool (d, TR_KEY_ratio_limit_enabled,             false);
   tr_variantDictAddBool (d, TR_KEY_rename_partial_files,            true);
+  tr_variantDictAddInt  (d, TR_KEY_reverify_torrents,               0);
   tr_variantDictAddBool (d, TR_KEY_rpc_authentication_required,     false);
   tr_variantDictAddStr  (d, TR_KEY_rpc_bind_address,                "0.0.0.0");
   tr_variantDictAddBool (d, TR_KEY_rpc_enabled,                     false);
@@ -423,6 +424,7 @@
   tr_variantDictAddReal (d, TR_KEY_ratio_limit,                  s->desiredRatio);
   tr_variantDictAddBool (d, TR_KEY_ratio_limit_enabled,          s->isRatioLimited);
   tr_variantDictAddBool (d, TR_KEY_rename_partial_files,         tr_sessionIsIncompleteFileNamingEnabled (s));
+  tr_variantDictAddInt  (d, TR_KEY_reverify_torrents,            s->reverifyTorrents);
   tr_variantDictAddBool (d, TR_KEY_rpc_authentication_required,  tr_sessionIsRPCPasswordEnabled (s));
   tr_variantDictAddStr  (d, TR_KEY_rpc_bind_address,             tr_sessionGetRPCBindAddress (s));
   tr_variantDictAddBool (d, TR_KEY_rpc_enabled,                  tr_sessionIsRPCEnabled (s));
@@ -812,6 +814,8 @@
     tr_sessionSetDeleteSource (session, boolVal);
   if (tr_variantDictFindInt (settings, TR_KEY_peer_id_ttl_hours, &i))
     session->peer_id_ttl_hours = i;
+  if(tr_variantDictFindInt (settings, TR_KEY_reverify_torrents, &i))
+    session->reverifyTorrents = ( i > 0 ) ? i : 0 ;
 
   /* torrent queues */
   if (tr_variantDictFindInt (settings, TR_KEY_queue_stalled_minutes, &i))
Index: session.h
===================================================================
--- session.h	(revision 14206)
+++ session.h	(working copy)
@@ -120,6 +120,8 @@
 
     uint8_t                      peer_id_ttl_hours;
 
+    int                          reverifyTorrents;
+
     tr_variant                   removedTorrents;
 
     bool                         stalledEnabled;
Index: torrent.c
===================================================================
--- torrent.c	(revision 14206)
+++ torrent.c	(working copy)
@@ -869,6 +869,7 @@
   tor->uniqueId = nextUniqueId++;
   tor->magicNumber = TORRENT_MAGIC_NUMBER;
   tor->queuePosition = session->torrentCount;
+  tor->reverifyTorrent = tor->session->reverifyTorrents;
 
   tr_sha1 (tor->obfuscatedHash, "req2", 4,
            tor->info.hash, SHA_DIGEST_LENGTH,
@@ -2184,6 +2185,17 @@
               tr_torrentCheckSeedLimit (tor);
             }
 
+          if( tor->session->reverifyTorrents )
+          {
+              if( tor->reverifyTorrent-- )
+                  tr_torrentVerify (tor, NULL, NULL);
+              else
+              {
+                  tr_torrentSetLocalError (tor, "%s", _("Reverify count exceeded - pausing torrent -- resetting retries"));
+                  tor->reverifyTorrent = tor->session->reverifyTorrents;  /* reset reverify tries */
+              }
+          }
+
           if (tr_sessionIsTorrentDoneScriptEnabled (tor->session))
             torrentCallScript (tor, tr_sessionGetTorrentDoneScript (tor->session));
         }
Index: torrent.h
===================================================================
--- torrent.h	(revision 14206)
+++ torrent.h	(working copy)
@@ -263,6 +263,8 @@
 
     int                        uniqueId;
 
+    int                        reverifyTorrent;
+
     struct tr_bandwidth        bandwidth;
 
     struct tr_swarm          * swarm;

[avip2u]

Hi, I am new to Transmission and not an experienced programmer. I am running the "version" of Transmission that runs on a QNAP. I have run about 30 torrents so far - - as I said I am new to Transmission but not new to torrent-clients in general - - and I have had about 5 or so torrents "complete" and start seeding, and even complete seeding, but when I view the details it says something like:

Downloaded: 998.0 MB (1.04 MB corrupt)

This is an actual copy & paste from the right-side details window.

A couple of these were fixed by manually 'reverifying'. I have a couple that I've reverified several times with no change, yet. STILL CORRUPT

I read a couple of other threads, where people discovered this as long as 4 or 5 years ago, and started arguing about this "BUG" and whether it was a legitimate fix to "Auto-Re-verify". I would just like to say:

• - It is definitely a BUG, fixing it at its "root cause" is a worthy goal
  
  - The re-verify solution is definitely a "partial fix" (I don't care at all about the "philosophy" - - my torrent is no longer corrupt = FIXED!)
  
  - I would love to have the OPTION to "try fixing it" by auto-reverify a set # of times and then if it is still corrupt, TELL ME so I don't further propagate the corruption.
  
  - Developers please allow progress towards BOTH "solutions" (a) fix the root cause (b) allow the work-around until the root is solved. It's a shame the work to fix this was not started 4 or 5 years ago.
  
  - Personally I think one (1) auto-reverify is a worthwhile precaution in ALL cases on ALL downloads, even if the program initially thinks it's 100% not corrupt... it doesn't take all that long even on very large files. And the larger the file, the more likely you're not sitting at your screen watching & waiting for it to complete. And also the more likely you probably want to ensure all that time spent downloading it was not wasted meaning your file is partly or even a tiny bit corrupted.
  
  - Of course, the program could leave this option "off" by default for those users that "object to the philosophy", which to me basically means you don't mind some of your torrents to be corrupt?!

To all the higher ups / developers / whatever, please stop arguing and make the software work more seamlessly or smoothly or whatever you want to call it.

To cfpp2p:
I would love to implement your patch on Transmission for QNAP. I would have no clue how to do so but if you could dumb down the instructions for a n00b I would be so grateful.
Thanks!

[avip2u]

I just re-checked and I have 3 torrents that are stubbornly not responding to manual re-verfiy.

I could PM someone the hash(es).

[avip2u]

Transmission re-downloads pieces that are found to be corrupt and then provides those numbers for informational purposes only.

Umm, it certainly doesn't look like that, and some of them, when I "re-verify local data", that message goes away.

Is there an official documentation somewhere that says "It's OK, no Really, it Really Is" ?

[Vallimar]

I found this additional bit to be necessary in order to compile on current 2.82.

Code: Select all

--- libtransmission/quark.h.rev	2013-10-19 21:59:37.908980224 -0400
+++ libtransmission/quark.h	2013-10-19 22:00:22.002316492 -0400
@@ -287,6 +287,7 @@ enum
   TR_KEY_rename_partial_files,
   TR_KEY_reqq,
   TR_KEY_result,
+  TR_KEY_reverify_torrents,
   TR_KEY_rpc_authentication_required,
   TR_KEY_rpc_bind_address,
   TR_KEY_rpc_enabled,

[cfpp2p]

Vallimar,

I found this additional bit to be necessary in order to compile on current 2.82.

Thank you for pointing this out !

https://trac.transmissionbt.com/ticket/4649#comment:41