These are chat archives for anacrolix/torrent

14th
Jun 2018
Matt Joiner
@anacrolix
Jun 14 2018 00:41
i'm doing my development in the dev branch now
and here we set bep20 and peerid (filled with random chars) - https://github.com/elgatito/elementum/blob/master/bittorrent/service.go#L231
Matt Joiner
@anacrolix
Jun 14 2018 04:20
thanks
while syncthing does not
it's probably not a problem anyway
huh.. there is already a library in go - https://github.com/huin/goupnp
Matt Joiner
@anacrolix
Jun 14 2018 04:27
i think i went with syncthing because it was the easiest to get running
feel free to do a PR if you find something better, or want to add close semantics using syncthing
Denis
@elgatito
Jun 14 2018 04:28
nah.. it's fine so far. maybe someone will make a proper testing with seeding a torrent and accessing that seed outside of a network. i'm fine with how it looks like
Matt Joiner
@anacrolix
Jun 14 2018 04:30
most traditional clients have a value that tells you if your forwarding is working
i can expose something like that, basically determine if we've gotten incoming connections from outside the local network
you can sample it and show it somewhere if you want
Denis
@elgatito
Jun 14 2018 04:35
i'm fine with how it's now
Denis
@elgatito
Jun 14 2018 04:59
https://paste.ubuntu.com/p/nSjNFDFpdQ/
got a panic in assertNoPendingRequests
added same torrent twice, then dropped one, while another one was still downloading
Denis
@elgatito
Jun 14 2018 06:59
there is a Torrent.Stats() call, which sometimes is locked for more than 10 seconds
Denis
@elgatito
Jun 14 2018 07:36
finally, have released version with /debug/bundle, should be easier to get proper debug outputs in one click
Matt Joiner
@anacrolix
Jun 14 2018 07:40
cool name lol
Denis
@elgatito
Jun 14 2018 07:40
/debug/bundle ?
Matt Joiner
@anacrolix
Jun 14 2018 07:41
if Torrent.Stats takes that long, it will help to see the /debug/lockTimes after it
yeah /debug/bungle
bundle*
Denis
@elgatito
Jun 14 2018 07:42
as well as the bug with download, coming to 0kb, it happen rarely
Matt Joiner
@anacrolix
Jun 14 2018 07:44
that panic, i'm still not able to reproduce
are you able to tell if it occurs after a torrent is closed/dropped?
that's the only thing i can think of
Denis
@elgatito
Jun 14 2018 07:46
should be: add same torrent file twice, then do Drop on one of the returned handles, then library throws a panic, not triggered by my call, but caused by that call
Matt Joiner
@anacrolix
Jun 14 2018 07:46
what do you mean torrent file?
Denis
@elgatito
Jun 14 2018 07:47
Client.AddTorrentFromFile(uri), where uri = path to torrent file
then on one of returned torrents, I do Torrent.Drop()
Matt Joiner
@anacrolix
Jun 14 2018 07:49
both torrents returned from that call should be the same
The *Torrent value should be the same
if the path is the same
Denis
@elgatito
Jun 14 2018 07:51
trying to reproduce :)
Matt Joiner
@anacrolix
Jun 14 2018 07:52
thx, the panic will block my intended fix for #253
Denis
@elgatito
Jun 14 2018 08:05
Now I can't reproduce. That time it did happen when I had multiple torrents added, with the same InfoHash (they were added with different filepath), then Dropped one of them. Now it does not work like that:)
Matt Joiner
@anacrolix
Jun 14 2018 08:33
yeah the Client only allows one *Torrent per infohash
Denis
@elgatito
Jun 14 2018 12:33
@anacrolix I have tried Torrent.(Pause/Resume) methods using Torrent.SetMaxEstablishedConns(0) and that works fine
on 0 we keep trackers connections but close all connections, then restoring the limit and it goes up
not perfect, but it does what it needs to
deranjer
@deranjer
Jun 14 2018 13:38
@anacrolix I got the error (assertNoPending) due to bad code I wrote where I had a goroutine that listed all the torrents and then on the MAIN routine I deleted one of the torrents. Then if the goroutine had ALREADY listed the torrent, then tried to manipulate an already dropped torrent, it gave me that error.
Matt Joiner
@anacrolix
Jun 14 2018 22:55
@deranjer what was the manipulation you did after dropping it?