Jump to content

uTorrent can't handle big torrent file


raananan

Recommended Posts

Posted

I just downloaded a big torrent file (the .torrent file is actually 1.8 MB) and tried to open it with uTorrent and I got a message that tells me "Unable to load ... .torrent". I was forced to open this torrent file with Azureus.

Azureus works fine with that file so the problem is not in the file I guess. I don't think I can post here the link to the torrent file but if you want a link to this file send me a private msg.

Thanks

Posted

µTorrent won't open torrents with more than 65535 pieces by design (because it's retarded to have that much). With a 4MB piece size and 65535 pieces, you can do about 255GB (and the max piece size is 16MB so you can do about 1TB really...). You should tell the torrent maker to not be retarded and use a reasonable piece size. And you know, let the client do it automatically.

Posted

On the tracker where I'm a moderator, the maximum .torrent file size is 1 MB -- that's 1 MB decimal, not 1 MiB. Someone tried to post a torrent of a 4.4-GiB DVD in 64-KiB pieces; since it was nearly 1.5 MB (and Azureus's cruft didn't help), he couldn't. [That's over 72000 pieces, so it also would have exceeded µTorrent's limit.] We told him to set the piece size larger, to at least 512 KiB but preferably 1 MiB or 2 MiB. He reluctantly re-created it with 96-KiB pieces and it came in just under the maximum. That must have been really fun for the peers' clients, doing all that negotiating and exchanging those long have and want lists. Then again I'm not sure that he ever seeded the thing anyway.

Posted

A torrent creation utility should even prevent people from using 128-KiB pieces for 10-GiB torrents. Any piece size smaller than 1/65535 of the content should be locked out of the choices; or the creation should abort when the utility realizes there is too much content for 65535 pieces of the selected size.

Posted

It makes sense, but still, this should not be something that limits the program. I didn't tried it in all the programs and I won't try it, but I think that most of the programs will handle this kind of torrent. Limiting your self to a "smart" torrent makers it's not something good. If this kind of thing was limited in the bittorrent definitions then this limit is reasonable.

The minimum thing to do here is to change the error message to be more clear, something that will say to the user to change the torrent or something else.

Posted

it happened to me before..I know what should you do.

I gusse you click open rather than save when you click any torrent from any website.

if this dialog appeared...try to save the torrent on you PC and then open it by utorrent.

it shall work smothly..if it didn't then it must be something else.

  • 2 weeks later...
Posted

Did you try to redownload the torrent? it supposed to be working...

unless..this torrent is UPD torrent not HTTP one..if so...

try to find another one since utorrent can't work with UPD files yet..

give me the link of that torrent...I will try it for you...and figure out the solution...

I hope it dosen't need a password to access it :)

  • 10 months later...
Posted

I am aware of the fact that using over 2^16 chunks is retarded on small torrents. However in the case of bigger ones it might not be. I am not an expert regarding to the way bittorrent works so I do not know the optimal chunk size for each content size. Still I know that much that it does vary and for very big torrents like over 100GB (Yes, they do exist and the client should be able to handle it fine) it might not be so retarded to use over that amount of chunks. And in future the sizes will just go up. It might not be optimal to just increase the chunk size limit from 16MB (assuming that works on most/all clients).

I had a case with a 136GB torrent. I made it with BitTornado using default settings on btmakemetafile. This gave me a torrent with 2MB chunk size and thus over 2^16 chunks. So of course the torrent did not work with utorrent. In this case it came to my attention that there was a problem and I did make a new torrent, wich btw did take a lot of time due to the size, with manually specified chunk size of 4MB. So if the chunk size selection was locked to automatic there would have been no way to make a working torrent with that program. This gives problems on the case of torrent making program that isn't as intelligent as the makers thought. And to say, if there isn't any 2^16 chunks limit on bittorrent specs then that could very well be a practical case even on such maker that would have locked chunk size to automatic. I'm just lucky they don't lock it.

In this case the problem wasn't that big as it could be fixed. But what if the creator of the torrent doesn't know or care about the problem? Then the downloaders just can't use utorrent for the download. They have to decide between not to download or to use other program. I would assume most would decide to use other program like did happen in my case until I made a new torrent to fix the problem.

We do not live an in ideal world where it would be feasible to expect every torrent making program is intelligent enough to use 'suitable' chunk count limits solely decided by coders of single client while all other clients to my knowledge do work with bigger chunk count. Therefore I would assume it would be best for utorrent to work on torrents that do have possibly not so ideal chunk count, but still clearly within the specs I assume.

Posted

Going over 65536 chuncks for a torrent causes LOTS of additional overhead bandwidth to trackers and seeds/peers alike.

However with a 136 GB torrent, that's not really avoidable except to split it up into multiple torrents.

  • 6 months later...
Posted

The 65k piece limit is IMO annoying for large torrents since people with inadequate bandwidth will have to struggle to download even one piece in timely fashion to get a hash, and if they can't be online 24/7 it becomes even more unlikely, and I've not heard of BT clients that actually store impartial piece information (as in, we've downloaded this and that part of this here piece - sure they _write_ that partial data to disk, but do they store the information when exiting anywhere?) Still, 65k piece limit is troublesome for large torrents where the piece size exceeds 0.5 or 1MB, and there is no increased traffic to the tracker caused by this, only prolonged, and although the number of have messages will be greater than with the 65k limit, it still is quite likely exactly same amount of traffic as with a smaller torrent with the same number of pieces. That actually means the smaller torrent will have higher traffic because of the have messages simply because it _can_ have smaller piece sizes. So the logic on saving bandwidth anywhere is ridiculous. The most noticeable downside of the limit is that it significantly slows down detection of bad peers in large torrents.

P.S. uTorrent 1.7.2 crashes completely and utterly when I try to load 1.8M torrent. No crash dump or anything, just stops responding and have to kill the process to get anywhere after that.

Edit/In case I forgot to mention: The piece size limit only causes additional traffic when it's smaller than for other torrents, which large number of pieces doesn't inherently cause, only small piece size which you're obviously already allowing as long as the number of pieces is below 65k. Also, additional traffic to trackers doesn't occur since the number of pieces nor their size has no effect on the announce frequency nor the size of the announces (bitfields aren't sent to trackers, you know). Ergo, I see no real reason to limit the number of pieces.

Posted

Admittedly, a tracker doesn't had out the .torrent file itself -- but it's definitely a part of a typical tracker website's bandwidth issues. So if a .torrent file itself is 1.8 MB then for 1000 people to download it is 1.8 GB. (after protocol overheads it's probably even more) This becomes non-trivial pretty quickly when experiencing the slashdot effect. (huge numbers of new arrivals far out of proportion to previous rates)

A 1.2 GB file torrent could be broken up into 16 KB pieces, thus resulting in more than 65k pieces. This would be pointless overkill and would increase the bandwidth needed to trade it considerably more than the typical 256 KB/512 KB/1 MB piece size (for large torrents). Even if many poisoners are present, it is not necessary to make extremely tiny piece sizes.

Posted

(Erm, the file was actually 1.3M in size, not 1.8... anyway)

Unfortunately the "is no longer valid issue" is quite untrue when uTorrent crashes on such files.

Well, I ran the .torrent through my own decoder (:P) and got some info on it.

Piece size: 4M

Pieces: 1000 + 1 partial

Files: 19309

So, the number of pieces wasn't the issue, but there were some files with possibly corrupted pathnames. Otherwise the torrent was error-free :)

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...