Opened 10 years ago

Closed 7 years ago

#4089 closed Bug (fixed)

magnet download not verified for existing data

Reported by: tman Owned by: jordan
Priority: Normal Milestone: 2.83
Component: Transmission Version: 2.21
Severity: Normal Keywords: magnet upload not verified
Cc: abacabadabacaba@…, jdkatz23@…, basinilya@…, eschava@…

Description

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.

Attachments (3)

torrent-magnet.diff (485 bytes) - added by rb07 7 years ago.
See note in comments.
magnetVerify.patch (1.4 KB) - added by cfpp2p 7 years ago.
magnetVerify-v2.patch (1.5 KB) - added by cfpp2p 7 years ago.
incomplete toggled fixed

Download all attachments as: .zip

Change History (29)

comment:1 Changed 10 years ago by 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.

comment:2 Changed 10 years ago by 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... :)

comment:3 Changed 10 years ago by 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.

comment:4 Changed 9 years ago by jordan

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

comment:5 Changed 9 years ago by 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

comment:6 Changed 8 years ago by cfpp2p

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

comment:7 Changed 8 years ago by abacabadabacaba

  • Cc abacabadabacaba@… added

comment:8 Changed 8 years ago by eris23

  • Cc jdkatz23@… added

comment:9 Changed 8 years ago by basinilya

  • Cc basinilya@… added

comment:10 follow-up: Changed 8 years ago by 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.

comment:11 in reply to: ↑ 10 ; follow-up: Changed 8 years ago by 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.

comment:12 in reply to: ↑ 11 Changed 8 years ago by 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.

Changed 7 years ago by rb07

See note in comments.

comment:13 Changed 7 years ago by 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).

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

comment:14 Changed 7 years ago by rb07

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

comment:15 Changed 7 years ago by x190

---

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

comment:16 Changed 7 years ago by x190

---

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

Changed 7 years ago by cfpp2p

comment:17 Changed 7 years ago by 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);
+    }
Last edited 7 years ago by cfpp2p (previous) (diff)

Changed 7 years ago by cfpp2p

incomplete toggled fixed

comment:18 follow-up: Changed 7 years ago by 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.

comment:19 in reply to: ↑ 18 Changed 7 years ago by x190

---

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

comment:20 follow-up: Changed 7 years ago by 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? ;-)

comment:21 in reply to: ↑ 20 ; follow-up: Changed 7 years ago by x190

---

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

comment:22 in reply to: ↑ 21 ; follow-up: Changed 7 years ago by 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.

comment:23 in reply to: ↑ 22 Changed 7 years ago by 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. :-)

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

comment:24 Changed 7 years ago by eschava

  • Cc eschava@… added

comment:25 Changed 7 years ago by jordan

  • Milestone changed from None Set to 2.83
  • Owner set to jordan
  • Status changed from new to assigned

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.

comment:26 Changed 7 years ago by jordan

  • Resolution set to fixed
  • Status changed from assigned to closed

Added to trunk in r14234.

Note: See TracTickets for help on using tickets.