Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#3519 closed Bug (fixed)

Webseeds don't work

Reported by: Svenstaro Owned by: charles
Priority: High Milestone: 2.20
Component: libtransmission Version: 2.04
Severity: Normal Keywords: webseed web seed
Cc: Svenstaro, uckelman@…

Description

I've created a torrent using mktorrent and have added a webseed to it. This webseed is picked up fine in uTorrent and Deluge but Transmission simply doesn't notice the web seed. I tried svn trunk as well as several older version (down to 1.7) and it never appears to work. I also enabled the debug statements in webseed.c but they are never called.

I suppose it might be a parsing problems and Transmission does not even notice that the a webseed is in the torrent.

I'm attaching the torrent in question to the report.

Attachments (3)

swi-prolog-5.10.1-1-x86_64.pkg.tar.xz.torrent (663 bytes) - added by Svenstaro 6 years ago.
single-webseed.diff (923 bytes) - added by gostrc 6 years ago.
downloaded.vmod.png (41.4 KB) - added by charles 6 years ago.
took about a minute to download

Download all attachments as: .zip

Change History (29)

Changed 6 years ago by Svenstaro

comment:1 Changed 6 years ago by wereHamster

I'm lazy, I'll just copy what I said in the irc channel:

<wereHamster> standard: 'url-list' = either a single item or a list of normal URLs. 
<wereHamster> T code: if( tr_bencDictFindList( meta, "url-list", &urls ) )
<wereHamster> so when url-list is a single item, T won't load it
<wereHamster> file: libtransmission/metainfo.c, function: geturllist()
<wereHamster> basically: T only loads the url-list if it's a list. But the standard says it can also be a single item. But in that case T ignores that and won't load it.
<wereHamster> so you need to add code that checks if the value for url-list is a single item (string) and parse that
Last edited 6 years ago by jordan (previous) (diff)

Changed 6 years ago by gostrc

comment:2 Changed 6 years ago by gostrc

I have attached single-webseed.diff which adds support for a single string in url-list.

It seems like there are more bugs, now transmission won't download from the webseed at all...

comment:3 Changed 6 years ago by charles

  • Keywords backport-2.0x added
  • Milestone changed from None Set to Sometime
  • Status changed from new to assigned
  • Version changed from 2.04+ to 2.04

single-webseed.diff applied to trunk by r11186

comment:4 Changed 6 years ago by Svenstaro

  • Cc Svenstaro added

comment:5 Changed 6 years ago by charles

Svenstaro, is this the only showstopper for using libtransmission in your project? If this is the only make-or-break feature I could see bumping this ticket's priority up.

comment:6 follow-up: Changed 6 years ago by charles

Judging from the lack of a response for 9 days, it doesn't look like this is a pressing issue for Svenstaro's project.

comment:7 in reply to: ↑ 6 Changed 6 years ago by ipsecguy

Replying to charles:

Judging from the lack of a response for 9 days, it doesn't look like this is a pressing issue for Svenstaro's project.

Maybe I can motivate...

I am also looking into using Bittorrent for file distribution from a HTTP based system so webseeds would help a lot in a smooth transition (also to convice people that BT is not so different from what they know).

Torrents created by mktorrent or via burnbit.com containing webseed URLs (one or more does not matter, insofar this does not seem to be related to the single URL/URL-list issue and patch) are not used by tranmission (on 2.10 and 2.10+ nightly on Mac as well as 1.93 on ubuntu) at all, for both IP and DNS based HTTP server addresses.

Best ipsecguy (Andreas)

comment:8 Changed 6 years ago by uckelman

Hi, the fact that web seeds don't work is a big deal for the VASSAL project, as we were planning to begin distributing our game modules using BitTorrent?. I was hoping to use the command-line version of transmission on our seedboxes, but the fact that web seeds don't work is preventing me from making any progress on this. When can we expect this to be fixed?

comment:9 Changed 6 years ago by uckelman

  • Cc uckelman@… added
  • Severity changed from Normal to Major

comment:10 Changed 6 years ago by charles

  • Keywords backport-2.0x removed
  • Milestone changed from Sometime to 2.20
  • Priority changed from Normal to High
  • Severity changed from Major to Normal

Since there seems to be more interest in this feature than there used to be, I'll bump its priority a bit. However you shouldn't expect that to turn into end-user benefit overnight. No matter what we do right now, most Ubuntu, Fedora, and OpenSuSE users won't see the benefits until they roll out the next versions of their distros next spring.

It's interesting (and encouraging) that content providers are showing more interest in using webseeds. For a long time now they've gotten a lot of lip service but few actual users :)

comment:11 follow-up: Changed 6 years ago by uckelman

So, I'm finding that the problem is worse than I initially thought:

If you have a .torrent with a url-list in it, whether that url-list consists of a single url, or a list of urls, 2.04 won't see the non-web-seed peers.

So it looks like having a web seed at all prevents transmission from downloading a torrent, even if there are regular peers to download from!

It would be nice if this could at least be fixed soon.

comment:12 in reply to: ↑ 11 ; follow-up: Changed 6 years ago by charles

Replying to uckelman:

So, I'm finding that the problem is worse than I initially thought:

If you have a .torrent with a url-list in it, whether that url-list consists of a single url, or a list of urls, 2.04 won't see the non-web-seed peers.

From looking at the code, I don't think that this is correct. the code that pulls the announce list is separate from the code that pulls the webseed list.

It would be nice if this could at least be fixed soon.

Could you provide a .torrent to test this with? I'm not seeing this behavior.

comment:13 in reply to: ↑ 12 Changed 6 years ago by uckelman

Replying to charles:

Replying to uckelman:

So, I'm finding that the problem is worse than I initially thought:

If you have a .torrent with a url-list in it, whether that url-list consists of a single url, or a list of urls, 2.04 won't see the non-web-seed peers.

From looking at the code, I don't think that this is correct. the code that pulls the announce list is separate from the code that pulls the webseed list.

It would be nice if this could at least be fixed soon.

Could you provide a .torrent to test this with? I'm not seeing this behavior.

Sure:

http://www.vassalengine.org/torrent/00-2Fleet.vmod.torrent http://www.vassalengine.org/torrent/2Fleet.vmod.torrent

The first one has the url-list as a one-element list, the second as a single string. For the first, transmission shows the web seen in the peers tab, but never downloads from it. For the second, transmission shows nothing in the peers tab.

Right now, there's one real peer. (If you try within the next 12 hours or so, it should still be up.)

comment:14 follow-up: Changed 6 years ago by charles

Thanks for providing the test .torrent files!

Using Transmission 2.10 I'm able to download both of these torrents from the 208.39 peer. However I notice you're using a pretty old version (1.93) to serve these files. You should consider upgrading to 2.11.

comment:15 in reply to: ↑ 14 ; follow-up: Changed 6 years ago by uckelman

Replying to charles:

Thanks for providing the test .torrent files!

Using Transmission 2.10 I'm able to download both of these torrents from the 208.39 peer. However I notice you're using a pretty old version (1.93) to serve these files. You should consider upgrading to 2.11.

1.93 is the default version for Fedora 13, which that peer is.

It perplexes me that you're able to download from those. I wonder what's wrong with my 2.04 client, then?

comment:16 in reply to: ↑ 15 ; follow-up: Changed 6 years ago by charles

Replying to uckelman:

I notice you're using a pretty old version (1.93) to serve these files. You should consider upgrading to 2.11.

1.93 is the default version for Fedora 13, which that peer is.

Sure. But if you're asking me to test things with your seeder, you need to understand that you're serving files with a release of Transmission that's seven releases old.

comment:17 in reply to: ↑ 16 Changed 6 years ago by uckelman

Replying to charles:

Replying to uckelman:

I notice you're using a pretty old version (1.93) to serve these files. You should consider upgrading to 2.11.

1.93 is the default version for Fedora 13, which that peer is.

Sure. But if you're asking me to test things with your seeder, you need to understand that you're serving files with a release of Transmission that's seven releases old.

I've now upgraded the seeder to 2.04.

Changed 6 years ago by charles

took about a minute to download

comment:18 Changed 6 years ago by xCrucialDudex

still present in up-to-date ArchLinux?

transmission 2.13 (11501) gtk2 2.22.1-1 glib2 2.26.1-1

https://forum.transmissionbt.com/viewtopic.php?f=9&t=11058

comment:19 Changed 6 years ago by jordan

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed in trunk by r11632

Last edited 6 years ago by jordan (previous) (diff)

comment:20 Changed 6 years ago by jordan

GTK+ fix in r11638

comment:21 Changed 6 years ago by jordan

r11705: the GTK+ client's activity filter didn't test for webseed activity.

comment:22 Changed 6 years ago by jordan

r11707: the web client's activity filter didn't test for webseed activity.

comment:23 Changed 6 years ago by jordan

  • Summary changed from Webseeds do not work to Webseeds dont work

comment:24 Changed 6 years ago by livings124

  • Summary changed from Webseeds dont work to Webseeds don't work

comment:25 Changed 6 years ago by ipsecguy

Looks fine here, at least with a single webseed in the list and one from burnbit.com. Great work guys!

comment:26 Changed 5 years ago by jordan

jordan * r11820 libtransmission/webseed.c:

(trunk libT) #3519 "Webseeds don't work" -- handle nonresponsive webseeds

Don't keep trying to use nonresponsive webseeds or it will generate unnecessary network traffic and kill us during endgame.

Note: See TracTickets for help on using tickets.