These are chat archives for anacrolix/torrent

13th
Feb 2018
deranjer
@deranjer
Feb 13 2018 01:57
@anacrolix Had the issue again, here is the code from my server and then the panic from your library:
?[36mINFO?[0m[0019] message for deleting torrents                 ?[36mdeleteTorrentsPayload?[0m="map[TorrentHashes:[fa931c99dae96a339b1aff7b2d266578167ec578] WithData:false]" ?[36mdeleteWithData??[0m=false ?[36mtorrentlist?[0m="map[TorrentHashes:[fa931c99dae96a339b1aff7b2d266578167ec578] WithData:false]"
?[36mINFO?[0m[0019] Matched for deleting torrents                 ?[36mselection?[0m=fa931c99dae96a339b1aff7b2d266578167ec578
?[36mINFO?[0m[0019] Deleting just the torrent                     ?[36mselection?[0m=fa931c99dae96a339b1aff7b2d266578167ec578
panic: -1

goroutine 5898 [running]:
github.com/anacrolix/torrent.(*Torrent).assertNoPendingRequests(0xc042042380)
        C:/Users/deranjer/go/src/github.com/anacrolix/torrent/torrent.go:1223 +0xf3
github.com/anacrolix/torrent.(*Torrent).deleteConnection(0xc042042380, 0xc042154c80, 0xc04248fed0)
        C:/Users/deranjer/go/src/github.com/anacrolix/torrent/torrent.go:1215 +0xdc
github.com/anacrolix/torrent.(*Torrent).dropConnection(0xc042042380, 0xc042154c80)
        C:/Users/deranjer/go/src/github.com/anacrolix/torrent/torrent.go:1231 +0x64
github.com/anacrolix/torrent.(*Client).runHandshookConn(0xc0421dec00, 0xc042154c80, 0xc042042380, 0x1)
        C:/Users/deranjer/go/src/github.com/anacrolix/torrent/client.go:857 +0x369
github.com/anacrolix/torrent.(*Client).outgoingConnection(0xc0421dec00, 0xc042042380, 0xc042648300, 0x13, 0xce2af6, 0x2)
        C:/Users/deranjer/go/src/github.com/anacrolix/torrent/client.go:707 +0x1e9
created by github.com/anacrolix/torrent.(*Torrent).initiateConn
        C:/Users/deranjer/go/src/github.com/anacrolix/torrent/torrent.go:1703 +0x2cc
exit status 2
Essentially this occurred just after I performed singleTorrent.Drop()
Matt Joiner
@anacrolix
Feb 13 2018 03:48
hmm
Matt Joiner
@anacrolix
Feb 13 2018 04:28
@deranjer what go version and OS/arch are you on?
Matt Joiner
@anacrolix
Feb 13 2018 04:33
really struggling to figure this one out
it should only happen if a request is deleted twice, or is deleted without ever being added. that shouldn't be possible
Denis
@elgatito
Feb 13 2018 12:21
@anacrolix I have definitely seen an issue with timeouts. In short - memory storage, so only a reader with readahead that is downloaded. Wait till readahead downloaded, pause, wait for a long time, unpause. Reader is alive and is responding, data is read fine, but next pieces are not downloaded. I looked over /info and there one single connection. Like most of them were closed by us/them on idle-timeout and not reconnected when needed
Matt Joiner
@anacrolix
Feb 13 2018 13:50
readers alone won't keep connections alive
if pieces are evicted from storage, the client doesn't know, and will find out when it tries to serve them through the reader
Denis
@elgatito
Feb 13 2018 13:53
pieces are not deleted and were not previously downloaded, that is a new torrent, first pieces downloaded, then many minutes pass, and when reader continues to read (and so, priorities are moving further) - we don't get connections again
maybe they will be available in few minutes, but kodi is closing the file with a timeout error, so it's closed after that
Matt Joiner
@anacrolix
Feb 13 2018 13:54
hmmm
does it look like it's trying to connect?
with half open connections and accepts?
Denis
@elgatito
Feb 13 2018 13:56
don't remember, I will try to reproduce that specially. I only remember trackers had peers but there was one single connection in the list
Denis
@elgatito
Feb 13 2018 14:06
@anacrolix , getting panic after updating iplist package:
16:04:25.489 T:140423518586624  NOTICE: [plugin.video.elementum] panic: packed len 8684347 < 10418900
16:04:25.489 T:140423518586624  NOTICE: [plugin.video.elementum]
16:04:25.489 T:140423518586624  NOTICE: [plugin.video.elementum] goroutine 1 [running]:
16:04:25.490 T:140423518586624  NOTICE: [plugin.video.elementum] github.com/anacrolix/torrent/iplist.NewFromPacked(0x7f7386fb6000, 0x84833b, 0x84833b, 0x7f7386fb6000, 0x84833b, 0x84833b)
16:04:25.490 T:140423518586624  NOTICE: [plugin.video.elementum]     /home/elgatito/go/src/github.com/anacrolix/torrent/iplist/packed.go:71 +0x180
16:04:25.490 T:140423518586624  NOTICE: [plugin.video.elementum] github.com/anacrolix/torrent/iplist.MMapPackedFile(0xc420484820, 0x4d, 0x0, 0x0, 0x0, 0x0)
that is the same file, which I used after pack-blocklist
Matt Joiner
@anacrolix
Feb 13 2018 14:10
ah yeah, you need to rebuild the file. i knew it would be a hassle but i didn't want to put the effort in for backward compatibility
i upgraded the iplist packed format to support ipv6
as part of a big effort to improve ipv6 support
Denis
@elgatito
Feb 13 2018 14:10
yeah, did that..
do we support ipv6 connections, btw?
Matt Joiner
@anacrolix
Feb 13 2018 14:11
yes
i just added ipv6 support for http trackers, and pex
you'll need to rebuild the packed file with the cmd/packed-blocklist or whatever it's called
that command needs to be updated too of course
Denis
@elgatito
Feb 13 2018 14:12
network: "tcp", string: "46.211.20.79:57701" even with Debug: false :)
yes, pack file is now fine after rebuilding it
go-libutp: 2018/02/13 16:13:19 callbacks.go:40: error sending packet: write udp [::]:36979->[2001:0:9d38:78cf:8cd:2d85:3ce3:e037]:27078: sendto: network is unreachable also without debug mode
Matt Joiner
@anacrolix
Feb 13 2018 14:14
ok i missed that log message, i just pushed the fix for the first one
that's interesting that you get that log message
the recent ipv6 support must be triggering it
Denis
@elgatito
Feb 13 2018 14:17
that is a very firewalled network, that can be an issue
Matt Joiner
@anacrolix
Feb 13 2018 14:18
yeah it could get noisy
maybe make an issue for that one on go-libutp
whatever client you're running that got that message, it would be good to see the /debug/vars
it should be reporting ipv6 activity
Denis
@elgatito
Feb 13 2018 14:21
okay, I have a torrent, readeahead is downloaded, speed drops to 0, so waiting for some time to resume playback and move on the reader
Matt Joiner
@anacrolix
Feb 13 2018 14:21
between the readahead being downloaded, and "resuming", is there a read on the Reader?
that should trigger the readahead window to move
and start downloading again to fill the new window
Denis
@elgatito
Feb 13 2018 14:22
no, no reads, everything is stale before I resume playback
Matt Joiner
@anacrolix
Feb 13 2018 14:23
that sounds like the caller to the reader isn't performing correctly. like kodi has given up already
Denis
@elgatito
Feb 13 2018 14:23
maybe make an issue for that one on go-libutp
I'm just curious it's being printed while Debug is false :)
Matt Joiner
@anacrolix
Feb 13 2018 14:23
that's a good point. i think it's because it's not supposed to happen and i wanted to know about it. i'll probably just turn it into a counter
Denis
@elgatito
Feb 13 2018 14:24
currently it's:
TotalPeers: (int) 534,
 PendingPeers: (int) 425,
 ActivePeers: (int) 41,
 ConnectedSeeders: (int) 38,
 HalfOpenPeers: (int) 80
Matt Joiner
@anacrolix
Feb 13 2018 14:24
ok yep that looks good
bit many halfopen, but i wrote it for a server lol!
Denis
@elgatito
Feb 13 2018 14:25
now I update the /info and see number is lowering
 TotalPeers: (int) 384,
 PendingPeers: (int) 273,
 ActivePeers: (int) 38,
 ConnectedSeeders: (int) 35,
 HalfOpenPeers: (int) 80
okay, I will let it stay for few minutes
deranjer
@deranjer
Feb 13 2018 17:47
@anacrolix go version go1.9.3 windows/amd64