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)
Change History (29)
comment:1 Changed 10 years ago by User294
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: ↓ 11 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: ↓ 12 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.
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).
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.
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); + }
comment:18 follow-up: ↓ 19 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
---
comment:20 follow-up: ↓ 21 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: ↓ 22 Changed 7 years ago by x190
---
comment:22 in reply to: ↑ 21 ; follow-up: ↓ 23 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. :-)
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.
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.