Jump to content

"* Problem with torrent: Not a .torrent file " at Demonoid


sparkyfark

Recommended Posts

I was using build 3.1.0.26586 to create a .torrent of a folder that was 11.7 GB. Every time I tried uploading to demonoid, it would return the error message "* Problem with torrent: Not a .torrent file". My file extensions are not hidden and it did end in ".torrent" and had the uTorrent icon. Demonoid would not accept it as a legitimate .torrent file, no matter how many times I recreated it specifically following the FAQ, no matter how many different browsers I tried to submit it from.

Someone suggested I had the same problem as a friend who had a large torrent, using the same build. This person rolled back to build 2.2 and the problem went away. I rolled back to 2.2 as well, created the torrent, and demonoid accepted it first time.

Link to comment
Share on other sites

  • 2 weeks later...

I just hit this issue using uTorrent 3.1 build 26616, and it's doing something that the upload validator doesn't like. Here's the bad file:

http://dl.dropbox.com/u/16716391/Coast%20to%20Coast%20AM%202011.torrent

Compare to the good file:

http://dl.dropbox.com/u/16716391/Coast%20to%20Coast%20AM%202011-221.torrent

You can use this site to parse the torrent:

http://i-tools.org/torrent/exec

The non-working one has a piece size of 8K. In 2.2.1, the highest piece size is 4K. I tried using 4K piece size on 3.1 and see it still fails. But the other difference is this:

Non-standard fields in 'info' (3)

file-duration

file-media

profiles

Analysis here:

http://forum.utorrent.com/viewtopic.php?pid=626732#p626732

Demonoid.me needs to fix the tbdev build they are using. Here's a thread on how to:

http://www.tbdev.net/topic/25020-utorrents-v31-fix/

In benc.php line 87:

if (preg_match('/^i(\d+)e/', $s, $m)) {

change to:

if (preg_match('/^i(-{0,1}\d+)e/', $s, $m)) {

I've posted the above on their forum:

http://fora.demonoid.me/index.php?topic=215553.msg1086163

Link to comment
Share on other sites

  • 1 month later...

Also dc.ru-board.com can't read this non standard fields - this contradicts the description of the block structure of a torrent file as described in the official specification of the torrent protocol v1.0 - http://bittorrent.org/beps/bep_0003.html and I already wrote about the problems with these units, but I was told "it's not ours, Your problem and fix problems in their servers," and closed the topic by the base:

YOUR SOFTWARE, BY REFUSING TO LOAD THE TORRENTS UTORRENT IS GENERATING, IS IN VIOLATION OF PROPER BEHAVIOR FOR BITTORRENT SOFTWARE. YOUR REFUSAL TO ACCEPT THIS FACT PROVES THAT PEOPLE SHOULD NOT BE USING THE TRACKER YOU ADMINISTER BECAUSE YOU DON'T ACTUALLY UNDERSTAND IT.

Closing as a bug in the tracker software and the client software that chokes on the torrents created with current 3.1.2 and not in uTorrent.

That is, violation of program standards specifications is not a bug, an issue tracker.:)

Link to comment
Share on other sites

The spec also requires you to ignore unrecognized fields for future compatibility. Torrents are intended to be very extensible, as is the BitTorrent protocol itself, and there's tons of fields as it is that aren't part of the official spec that are de facto standards.

It is absolutely your bug.

Other client devs agree, too.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...