i'm doing my development in the dev branch now
@anacrolix this is peerid setter - https://github.com/elgatito/elementum/blob/master/util/ident.go#L63
and here we set bep20 and peerid (filled with random chars) - https://github.com/elgatito/elementum/blob/master/bittorrent/service.go#L231
thanks
this is the bit i was after: https://github.com/elgatito/elementum/blob/master/util/ident.go#L60
taipei-torrent has port deletion code - https://github.com/jackpal/Taipei-Torrent/blob/master/torrent/upnp.go#L346
while syncthing does not
it's probably not a problem anyway
huh.. there is already a library in go - https://github.com/huin/goupnp
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
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
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
i'm fine with how it's now
added same torrent twice, then dropped one, while another one was still downloading
I have a debug message, ticking every second: https://github.com/elgatito/elementum/blob/master/bittorrent/torrent.go#L229
there is a
Torrent.Stats() call, which sometimes is locked for more than 10 seconds
finally, have released version with
/debug/bundle, should be easier to get proper debug outputs in one click
cool name lol
/debug/bundle ?
if Torrent.Stats takes that long, it will help to see the /debug/lockTimes after it
yeah /debug/bungle
bundle*
as well as the bug with download, coming to 0kb, it happen rarely
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
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
what do you mean torrent file?
Client.AddTorrentFromFile(uri), where uri = path to torrent file
then on one of returned torrents, I do
Torrent.Drop()
both torrents returned from that call should be the same
The *Torrent value should be the same
if the path is the same
trying to reproduce :)
thx, the panic will block my intended fix for #253
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:)
yeah the Client only allows one *Torrent per infohash
@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
@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.
@deranjer what was the manipulation you did after dropping it?