Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using parsed torrent not working correctly #471

Closed
frankh opened this issue Oct 29, 2015 · 9 comments
Closed

Using parsed torrent not working correctly #471

frankh opened this issue Oct 29, 2015 · 9 comments

Comments

@frankh
Copy link

@frankh frankh commented Oct 29, 2015

var parsedTorrent = {
  "infoHash": "60e6b17767106247e1...",
  "name": ... etc
};

client.add(parsedTorrent, function (torrent) {
  console.log('Client is downloading:', torrent.infoHash);
}

This raises an error "e.created.getDate()" undefined is not a function. After some digging it turns out that e.created is a date string, so I manually wrapped it in new Date().

It now technically worked, except it seems like it just used the infoHash and created a magnet link. The whole reason I used a parsed torrent was to speed up the download by skipping the magnet step

@madd512

This comment has been minimized.

Copy link

@madd512 madd512 commented Oct 29, 2015

Did you supply one or more trackers? Without those it won't be able to get peers anywhere except the DHT.

@frankh

This comment has been minimized.

Copy link
Author

@frankh frankh commented Oct 30, 2015

Yes I supplied a tracker.

Also, maybe I'm just misunderstanding something, but shouldn't the first callback ("got torrent metadata") fire instantly for a parsed torrent?

From briefly stepping through the code it seemed like it just took the infoHash and ignored the rest of the data, just fetching everything from the DHT

@DiegoRBaquero

This comment has been minimized.

Copy link
Member

@DiegoRBaquero DiegoRBaquero commented Dec 11, 2015

@feross

This comment has been minimized.

Copy link
Member

@feross feross commented Jan 3, 2016

Also, maybe I'm just misunderstanding something, but shouldn't the first callback ("got torrent metadata") fire instantly for a parsed torrent?

Yes, it should fire very fast, but not on the same tick. The 'torrent' event always fires on the next tick to give users a chance to attach event listeners on the event.

From briefly stepping through the code it seemed like it just took the infoHash and ignored the rest of the data, just fetching everything from the DHT

That should not happen.

It would be a lot easier to debug this issue with a complete code example. Also, to confirm, you're using this in node.js, not the browser, right?

@DiegoRBaquero

This comment has been minimized.

Copy link
Member

@DiegoRBaquero DiegoRBaquero commented Jan 3, 2016

@feross This is just because the 'info' property is required. I stumbled upon this issue when creating the BMagnet demo server.

If you include 'info': {} in your parsed torrent, it should work. It did the job for me.

Check https://github.com/feross/webtorrent/blob/master/lib/torrent.js#L291-L292 now

@feross

This comment has been minimized.

Copy link
Member

@feross feross commented Jan 3, 2016

Ah, right. This is expected behavior if it's not a real "parsed torrent". But I have no idea why he was getting an exception. I don't think "created.getDate()" appears anywhere in the webtorrent code.

@DiegoRBaquero

This comment has been minimized.

Copy link
Member

@DiegoRBaquero DiegoRBaquero commented Jan 3, 2016

Re-read the original issue and it is really weird.

created.getDate() is only in https://github.com/feross/parse-torrent-file/blob/master/test/encode.js#L13 in the whole webtorrent and its deps tree

@feross

This comment has been minimized.

Copy link
Member

@feross feross commented Jan 3, 2016

Yeah, let's close this for now.

@frankh If you have more details to share about what triggered this bug, please leave a comment or open a new issue.

@feross feross closed this Jan 3, 2016
@lock

This comment has been minimized.

Copy link

@lock lock bot commented May 5, 2018

This thread has been automatically locked because it has not had recent activity. To discuss futher, please open a new issue.

@lock lock bot locked as resolved and limited conversation to collaborators May 5, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.