Fortunately I have enough of the rar parts to extract the data I want but damn.
You must log in or register to comment.
And don’t forget, when it finishes to seed that SOB for a long long time
The seas are treacherous to go about alone
it took me forever to grab star-crossed season 1 since it’s very niche and cw cancelled it like before it ended because it only had 1 seeder and everyone was trying to get it; now it has two potential seeders and i’ve been seeding for like a year just so nobody else goes through the pain.
sigh the pain of trying to get obscure nbc sitcom boston common for five months now
Sigh, the last 3 seasons of Becker for me…
I’m still waiting on early 2000s flac files of GOB.
try soulseek for those
Trying to get an audio copy of the Witcher prequels here
All the mainline books were easy, but these last couple have been a pain.
How and why does this happen? I have more torrents stuck at 99.9% than anywhere else combined.
Most of the time it is due to Cross-seeding and additional or manipulated files.
I.e. the 99% torrent contains an additional file like an nfo or srt that was not in the original upload on a different site. People cross-seeding the original torrent don’t have that file, so you can only get 99% from them. And if the uploader of the torrent with the additional file stops seeding, there’s no one you can get it from.
Or if it is stuck at 99% without additional files, it’s possible that the file that was uploaded was manipulated. Stripped UID or other metadata that was changed. So there will be a mismatching piece that you can’t get from the cross-seeders. And again, if the uploader stops seeding the manipulated file, you can only get 99% from the cross-seeders.
My theory is that either its from people deleting associated files like .srt and .txt or companies intentionally sabotaging torrents so that it looks like they’re being seeded still but not fully.
In any case, the times this has happened to me I’ll try to play the file and most times it works still.
Stupid protocol can’t send the big file if the small file next to it is missing. Gotta have the whole block.
I’m probably one of the people causing this issue to others. I always uncheck info, text, subtitle and other minor files that are not needed for the video/game, and so while me and presumably others are seeding the game files, rarely anyone seeds the info files, which end up being that 0.01%
This is how I found the torrent for “God of Cookery (1996)” ending and can totally relate. If you see Shaolin Soccer and Kung Fu Hustle, this one is worth seeing.
A man of exquisite taste, bravo.
It’s the file headers, right? Without those, they are unreadable. 🫠
It’s never that .txt file that says where it was originally uploaded
I’m missing the NFO file, 250KB of one of the rar parts and 300KB of a video sample.
I had one at 62% for years I watched peers come and go but never lost hope. Today it’s at 99%. All I’m missing are some padding files so basically 100%.
There’s me and one other peer who seems to be willing to seed until the end of time. My ratio keeps climbing so I assume someone somewhere is thankful
I’ve replied this to another comment already, but it is probably this:
Most of the time it is due to Cross-seeding and additional or manipulated files.
I.e. the 99% torrent contains an additional file like an nfo or srt that was not in the original upload on a different site. People cross-seeding the original torrent don’t have that file, so you can only get 99% from them. And if the uploader of the torrent with the additional file stops seeding, there’s no one you can get it from.
Or if it is stuck at 99% without additional files, it’s possible that the file that was uploaded was manipulated. Stripped UID or other metadata that was changed. So there will be a mismatching piece that you can’t get from the cross-seeders. And again, if the uploader stops seeding the manipulated file, you can only get 99% from the cross-seeders.
250KB of one of the rar parts
Ouch!
I wonder how viable it would be to bruteforce it. Not a serious proposal but still fun to think about
It absolutely could be brute forced, we litrally have the hash of the chunk. I’ve thought about it before too, if one seeder is constantly giving, or refusing to even give, the chuck because of the hash mismatch, odds are it’s only a bit flipped somewhere.
Another option that I’ve done before is find the file elsewhere, and switch it out. Seed for a long time then, you weren’t the only person at 99.9%.
SHA1 has a fairly even distribution, it produces 160 bit digests, so each possible variation of a chunk will have a roughly 2-160 probability to hit your hash. Now assuming you have some insane computing device that can do an exahash per hour (that’s 1018 hashes, a lot more than any modern hardware can do), finding one would take around 1.7E+26 years. Now the funniest part. Assuming your chunk is 32KiB large (practically nobody uses such small chunks today, so it’s the best-case scenario), there are 2^(32×210×23)/2160 possible variations of the chunk that would produce your exact hash. That’s roughly 1.1E+78865 fitting chunks with only one being correct. And it takes you 1.7E+26 years to get to just one of them.
absolutely could be brute forced
Yea, I wouldn’t say that.
This is why recovery info for archives is a boon - sadly it’s pretty out of fashion.
This should be the next cryptocurrency proof of work algorithm
Bitcoin uses two rounds of SHA256 if I recall correctly.
The problem is there will be multiple solutions that result in the same hash (collisions), but only one of them will be correct
And it would take an extremely long time to find them all, I don’t even think a modern GPU could do it in a lifetime
It looks like bittorent version 2 hashes with sha-256 at a 16kb resolution.
pieces root
For non-empty files this is the the root hash of a merkle tree with a branching factor of 2, constructed from 16KiB blocks of the file. The last block may be shorter than 16KiB. The remaining leaf hashes beyond the end of the file required to construct upper layers of the merkle tree are set to zero. As of meta version 2 SHA2-256 is used as digest function for the merkle tree. The hash is stored in its binary form, not as human-readable string.
Seems like that should be easily parallelizable and can fit into thread memory on a modern GPU.
It would just depend on how many 16kb blocks are remaining in that 0.1%
Well the hashes are always much smaller than the actual data, otherwise downloading the hashes would take just as long as downloading the data lol.
So 16KB blocks means 131072 bits per block, subtract the 256 bit hash size and that means 2^130816 hash collisions
That’s a lot lol, you’ll never find which one is the correct one. Even if you instantly had a list of all values that match the desired hash, you’d have to check them all and somehow determine which one was correct.
3 months waiting for 4mb left, I contemplated trying to brute force that last bit
If it were 1 bit, that would be easy. But 4 million bytes? Oof.
Oof
