magnet download not verified for existing data

[tman]

Using transmission daemon 2.21 on fonera 2.0n device. I'm adding a magnet link by uploading URL 'magnet:?xt=urn:btih:<hash>', while I have all data on disk for the corrresponding torrent. Bug: data is not verified but downloaded again.

[User294]

I guess this is because torrent metadata are missing when user just adds torrent. So torrent can't be verified as T does not knows parts hashes at this moment. Verification should be re-run after metadata received and validated so torrent could be actually verified as well.

[jordan]

...?

If you have the data already, why are you adding the torrent via a magnet link instead of via a .torrent file?

I guess this magnet-of-existing-data case should be taken into account, but it seems like such a strange use case... :)

[tman]

the reason can be multiple:

• i have the data from a private tracker, don't have a public torrent file and don't want to search for it
• some torrent index sites offers only magnetlinks, no torrent files (btdigg, magnetdownloads, ...)
• i have the torrent file but it contains a dead tracker. The magnet link can contain several live trackers
• it's easier to upload a magnet link to the daemon from a mobile phone (just enter url, no file upload)
• and finally: just because it alredy works if I stop it right after it found peers and I verify the data manually. but this is not the right way to always keep an eye on the torrent status.

[jordan]

ticket #4567 has been closed as a duplicate of this ticket.

[leonardogyn]

i was about to open a bug request about this behavior, that still happens on latest Transmission version as today (2.50 (13236)), but seems it was already reported by other users :)

i would also add a new reason for something like this happening: i accidentaly 'removed from list' a torrent that was being download and i do not have a .torrent file, just the magnet link. Sorry guys, my fault, but it can happen ... So, after readding the torrent through magnet link, it starts downloading it from scratch, ignoring the data i have already downloaded.

asking for a manual 'torrent verification' seems to be enough to make Transmission 'recognizes' the local data and continues exactly from where it stopped. But if a manual verification is not requested, download is always started from scratch.

dont know if it matters, but im running Transmission 2.50 on a Mac OS Lion 10.7.3

[cfpp2p]

with a patch enabling #4808 it is pretty easy to fix this ticket also.

[twilsonb]

I encountered this issue today with Transmission 2.77 (14031) on Mac OS X 10.8.2 (12C2034).

I had moved the files from a torrent downloaded using a magnet link, and I used the original magnet link to restart the torrent. But it just re-downloaded from the start.

I didn't know I could manually reload a torrent, so I ended up saving the magnet link as a torrent file, then using the torrent file to trigger the desired behaviour.

What I really wanted was a way to indicate to Transmission where I'd moved the files to. I'm not sure if this exists.

[x190]

Replying to twilsonb:

What I really wanted was a way to indicate to Transmission where I'd moved the files to. I'm not sure if this exists.

Transmission->File->Move Data File To... (select enclosing directory not data directory or file) and verify data as required.

[twilsonb]

Replying to x190:

Replying to twilsonb:

What I really wanted was a way to indicate to Transmission where I'd moved the files to. I'm not sure if this exists.

Transmission->File->Move Data File To... (select enclosing directory not data directory or file) and verify data as required.

That method didn't work for me - perhaps it was because I moved the files myself, and then told Transmission, or perhaps I needed to trigger a manual re-verification.

[rb07]

See note in comments.

[rb07]

Anyone willing to help test this proposed fix?

The attachment I added does fix the problem, but it is triggering an assertion on my tests (in peer-msgs.c, the "assert (msglen + 1 == msgs->incoming.length)", just once, when the torrent goes from magnet, to 'torrent', so it may be unrelated -- and happens both on the original download, and on the no-download 2nd use of the magnet).

[rb07]

Don't use the patch I posted, it actually crashes the program (in verifyTorrent()), it looks like something is missing.

[x190]

---

[x190]

---

[cfpp2p]

In response to rb07:

Anyone willing to help test this proposed fix?

and testing by x190

attached magnetVerify.patch is a new proposed patch that works fine in preliminary testing.

Please comment how it works for you.

update:

need: refreshCurrentDir (tor) in some cases.

magnetVerify-v2.patch attached (awaiting moderation approval) fixes using/toggle incomplete directory issues

+
+  if (tor->magnetVerify)
+    {
+      tor->magnetVerify = false;
+      tr_logAddTorInfo (tor, "%s", "Magnet Verify");
+      refreshCurrentDir (tor);
+      tr_torrentVerify (tor, NULL, NULL);
+    }

[cfpp2p]

incomplete toggled fixed

[rb07]

Interesting, but I have a question:

In torrent-magnet.c there is a "tor->isStopping = true" in your patch, it seems wrong, it should be set to the option chosen by the user (its actually already set to that)... but you are probably forcing it so your patch works (i.e. force all magnets to stop). It should be transparent, no change on current operation except the verification. Is this correct? or I'm missing something.

[x190]

---

[rb07]

Works fine (previous version, not tested comment:19).

Good work cfp p2p!

From a user point of view it works different than starting with regular torrent files, but its not much of a difference, and its all in the dynamics (i.e. when the metadata finishes downloading, it goes through a "have 0%", then verifying, then seeding -- there is no "finished downloading" message, and the corresponding execution of the script like there is when you use a file).

Is the last comment a new version of the patch? tr_bool? really? ;-)

[x190]

---

[rb07]

Replying to x190:

Does my version help with the 'not changing user settings for running after verify'?

Your version I didn't test.

I agree that startAfterVerify was useless since it already is set, but I don't agree with the other changes.

The original (current) Transmission code has many redundant (useless) parts (like running verify before the metadata is downloaded -- some of which I eliminated some time ago while testing magnet prefetch, and this.) But that is off-topic, unless as you noted, a patch adds more useless code.

cfp p2p's patch doesn't stop the torrent independent of the user's setting. That's what I meant by "works fine"; it does the job, and it does it correctly. I tested both cases: straight download, and pause before download, both go through verify, both work as expected.

[x190]

Replying to rb07:

Replying to x190:

cfp p2p's patch doesn't stop the torrent independent of the user's setting. That's what I meant by "works fine"; it does the job, and it does it correctly. I tested both cases: straight download, and pause before download, both go through verify, both work as expected.

Thanks for testing cfpp2p's patch and confirming it works as expected. :-)

[jordan]

The patch WfM as well.

I'm a concerned about all the state flags accumulating in the tr_torrent struct, but let's not block this ticket any longer.

[jordan]

Added to trunk in r14234.