TLDR: Is there a way I can just choose files to seed automatically instead of downloading again first?
Pretty new to using torrents and I have a bunch of files I’ve been able to download over time through magnet links. Some of which I was unable to seed for long periods of time so removed but would like to be able to still seed them again.
It doesn’t look like I have torrent files for them and I tried copying the. Torrent file to another folder when using magnets to see if I could get it from that. I was able to get some from that but it seems to just start a Download again. Can anyone explain this process a little bit better for me so I can offer up my files at later times too?
Yes, is possible and not that hard, you add the torrent back into your client pause it (or dont even let it start downlaing) and point it to the already downloaded files by changing the download folder, after that just verify the files in the client, it sould see the already downloaded files and verify that they are the same, once that is done you can continue seeding.
Ah okay. That would make sense. I assume this does require the actual torrent file though or does this also work by using the magnet link and doing the same process?
If the tracker(s) defined in the mag link are still active and have the torrent metadata, then yes a magnet link should also work fine; you just have to add the magnet link, wait for the torrent to update with the torre t name/size in your client before pausing, then do the folder redirect.
Great. Thanks for clarifying!
Depends on your torrent client. Be careful that the client does not accidentally overwrite your files, replacing the completed content.
In qBittorrent you add the torrent without starting the download, and then let it or make it re-check [existing] files. it should then progress the check to completion with the correct files and file names in place.
If you have the torrent added and then put/move the files correctly, you can use the context menu “force re-check”.
When you then start that complete torrent, you’re seeding.
As simple as what I’m about to suggest is, it is priceless.
This is an example when copy > paste. Copy the file content, perform the methods shared in this thread, then once you’ve verified that everything is running properly you can delete the original copy.
If it bunks and overwrites, no biggie, you planned for that.
I’d love to say that I’d never made the mistake of choosing CUT when I should have chosen COPY, but I guess sometimes we learn things the hard way. 💀
If you already have the exact files, sure. If not, then no.
I assume renames affect the “exact” part of it right?
Renames are OK in pretty much all clients.
- Open .torrent file
- Select correct destination directory
- Add Paused
- Right-click each file/directory in the “Content” tab and rename
- Recheck to make sure all files are found by the client and their contents have not changed; select “Do not Download” for missing or incomplete files, the correct chunks will still be seeded
- Start seeding
You can also use a torrent file editor to get the file names right before importing into a client. Useful for batch operations. HOWEVER, the info hash will be different so it won’t be recognized by the tracker. You can upload such file to your own tracker, though.
Yes. The hash has to be the same. They have to be identical files down to the last bit. Otherwise when you go to recheck the torrent, it’ll only be a partially completed torrent and you can only seed what you have finished.
Nope, file names can be different. It’s only the contents that are hashed. If there is a difference, the entirety of every affected chunk is unseedable and the chunk needs to be redownloaded (if allowed by the use). Then there’s the infohash that includes filenames but that’s not important.
This entirely depends on your client and the version of libtorrent that it uses. To say with exactitude you would need to know these things. Since we don’t, it’s more accurate to say that it breaks torrent verification.
Additionally, there are renames which can still break verification. Like changing file extensions.
I’m willing to take the risk. It’s like saying “your web browser supports WebGL”. Unless you’re on Opera Mini or something text-based or ancient, we can assume it’s true.
How does changing an extension break verification? It’s just a rename again. I have successfully changed an extension using qBittorrent before and the check passed again. Via its web interface, even!
And no client hashes filenames because they just aren’t what is hashed. I think even TUI ones have internal support for different filenames even if they don’t have a rename function because you can reach limits of your filesystem (path length, character support etc.)
Yes you’ll need everything to be exactly as you received it including extra things like .txt files and the like. This is to prevent someone from replacing a legitimate file with something malicious.
You’re wrong, partially. Stand by while I illustrate.
Neither file names nor extensions are included in content hashes.
Let’s first see how a torrent file is created, using quick-and-dirty bitmaps I just drew. File sizes will be in whole MiB (1 MiB = 1 pixel width) for convenience.
So you have a file tree you wanna share.
The client will arrange the files in some order. I think you can create a valid torrent file with any ordering but let’s just assume it’s by path, alphabetical. (We are supposing each file is a whole number of MiB, in reality it can be any whole number of B)
Now file contents are concatenated.
Then split into 14MiB chunks (in practice 2, 4, 8 or 16MiB but I forgot to account for border while drawing lol) and zero-padded (grey) to fill the last chunk.
v2 .torrent files can be aligned (where large files always start at chunk border) but this is not allowed/encouraged in most trackers due to hit-and-miss support by clients.
Now a hash is calculated for each chunk, creating a hash map. I’ll assume you know what hashing is.
The file list, hash map, tracker info and other data I didn’t bother drawing gets packed into the .torrent file. On private trackers, each user will send a unique user ID as a parameter of the announce URL so that transfers can be tracked and users get credited for seeding.
Any modern torrent client will let you change the names of files on your drive, provided you tell it the new filename so it can keep track of which files described in the .torrent file correspond to which files on your filesystem (therefore the recommended way is to rename within the client). Then it will be able to reconstruct the chunks so it can send them as other people request them while you seed.
Theoretically, you should be able to also change the directory structure but I don’t know a GUI client that will let you. Maybe you can try symlinks or path traversal shenanigans like/../S01E01.mkvto un-folder the seasons for example.
Others in the swarm will never know what new file names you used or about other files on your system. They only request and offer the contents of chunks, and will only accept them if the chunk resolves to the known hash.For example, someone willing to download just “S02/E01_Sit.mkv” from you will request chunks 72 to 84. Your torrent client will pull the first 7 MiB of chunk 72 from the end of “Season 1/S01E03.mkv” and the other 7 MiB from the beginning of “Season 2/S02E01.mkv”. The recipient will get all 14 MiB from you, check that the hash matches and discard the first 7 MiB, saving the last 7 MiB into “S02/E01_Sit.mkv” followed by the contents of chunks 73 through 83 and the first 13 MiB of chunk 84. I could draw the request-transfer-check-save process with my graphics but it’s been done before and I need to sleep so no more pics.
Note that in the example above, the file Cover.jpg went missing. Its chunk will therefore not be reconstructible (in practice, the first 2 MiB that can’t be read from disk will be interpreted as all zeros and the hash will not match) and will not be advertised as available while seeding. (In fact, the user will still be listed as “leeching” in the swarm because they don’t offer all chunks for download.) It doesn’t matter that 12/14 MiB of the first chunk is available - other users will not accept incomplete chunks because they don’t match the hash and that means they have been altered, possibly maliciously. As a result, if this user is the only remaining peer in the swarm and then someone joins to download the files, they will never be able to get anything from the first chunk and their copy of “S01/E01_Lorem.mkv” will be incomplete (clients will either make the first 12 MiB of the file all zeros, creating a completely unplayable MKV file, or store the good parts in a .part file and wait for the first chunk forever - the latter can be more frustrating because if the LAST few MiB are missing in otherwise good video files they don’t appear even though they would be almost fully playable with the first approach). However, the torrent can “heal” if a seeder appears in the swarm and provides the a correct copy of the first chunk and the missing “Cover.jpg” file is restored (unless it’s set to “Do Not Download”).
Edit: if you’re the user who deleted “Cover.jpg” (please don’t be) your client will probably detect it on restart or when reannouncing and alert you with a red row in the table and you have to take manual action to re-enable announcing for the torrent. Your options are:
- If someone else has all of the first chunk, you will be able to redownload it and have the torrent complete again.
- Set the file (and the next one) to “Do Not Download”, recheck and just accept that you will never seed the first chunk again.
- Find the file on your filesystem, DDL site etc., put it where the torrent client expects it (or you can use the internal Rename tool if the path is the same except filename) and recheck the torrent to see if the file is indeed correct.
Do you now understand why file-chunk alignment I spoke about above is critical if people keep losing files like NFOs?
What is correct is that you cannot edit the filenames in the torrent file (even though torrent editors exist) because then its hash (known as “infohash”) would be different and the tracker would not recognize it. You’d need to reupload it but it would be likely detected as duplicate. You’ll only encounter infohashes in magnet links: they are used by the magnet link handler to verify that the torrent the server responded with is the one you wanted.
So when I download only some files from a torrent, it’s likely that I can’t seed all of those files to the next person? I have done partial leeches before and left them seeding under the impression that I could at least seed exactly those files if anyone else wanted them. If that’s impossible (or at least unlikely to work because of chunking), then I might download the whole thing next time (or just leave the swarm).
Your client must have downloaded entire chunks, including parts of adjacent files to those you wanted. I think most clients will discard them but it’s possible they are stored somewhere hidden to enable seeding them again. Pretty much every client will tell you something like “66 chunks (have 11)” and/or progress on a per-file basis, from which you can deduce which of these behaviors is used. Badly written ones will make a file as big as the previous episode to the one you want and fill it with zeros so that the few MiB are physically in the right spot. Obviously, that fills your drive with junk unless compression is enabled at filesystem level.
It’s always better to seed something even if it’s not an entire file. Peers are usually upload-bandwidth-limited so being another person providing just a few chunks helps download speeds. Unless you meddle with their progress files, torrent clients will not announce (offer for download) chunks they cannot reassemble. Only people who have 100% of the data are listed as “seeders” in the swarm.
If you can’t find the original .torrent, one way to find it again is to use BiglyBT client’s Swarm Discoveries feature to search its DHT for the exact file size in bytes (of the main media file within). You may be able to find one or more torrents and simultaneous seed them with Swarm Merging too.
As well as the force recheck method others have mentioned, you can also tell BiglyBT to use existing files elsewhere when adding the torrent, which can copy the data onto there for you without risking overwriting the original files.
Can’t help with your question, but thank you for your service.
