These are chat archives for anacrolix/torrent

13th
Jun 2017
Denis
@elgatito
Jun 13 2017 05:58
Unfortunately seeking is nowhere near libtorrent. Even with he highest priority (Now) pieces take three to four times more time to complete.
@anacrolix , also did notice that after seeking the file somewhere it takes much time to download pieces with higher priority
Denis
@elgatito
Jun 13 2017 06:04
that is a quote from @dimitriss .
Matt Joiner
@anacrolix
Jun 13 2017 11:08
I'm not sure of the context of that. Or who dimitriss is.
Denis
@elgatito
Jun 13 2017 11:17
That is about situation when media player trigger seek somewhere far from current position and reader reprioritize pieces, but it takes much time to download readahead pieces
Matt Joiner
@anacrolix
Jun 13 2017 11:22
I've not noticed that. The library focuses on that, and with good seeders/leechers it's very fast.
dimitriss
@dimitriss
Jun 13 2017 12:05
The library is great, with a little fine tuning maybe seeking can be better
Matt Joiner
@anacrolix
Jun 13 2017 14:23
I used to focus more on satisfying immediate reads at the expense of efficiency on the network and scaled it back. I also used to have a "responsive" reader mode, where data was passed to readers without completing pieces and verifying, but I'm not sure that's enabled anymore. I decided it wasn't a good idea.
You should always ensure you have 10+ peers for a given (public) torrent or you will have a bad time anyway.
dimitriss
@dimitriss
Jun 13 2017 14:27
Matt are you going to accept a PR that enables sequential piece downloading ?
Matt Joiner
@anacrolix
Jun 13 2017 14:42
Yes, what are you trying to achieve?
What's the use-case?
dimitriss
@dimitriss
Jun 13 2017 14:42
streaming video
peaces will be downloaded sequentially
Matt Joiner
@anacrolix
Jun 13 2017 14:43
That's actually my primary use case too, and I intentionally don't do it purely sequentially
With the noteworthy exception of the currently blocked piece
You can read the Client.WriteStatus output to see what ordering each connection has each piece in
There's a probabalistic algorithm that takes into account piece priority due to reader positions within the torrent
this seems to generate random numbers that are later used as a factor for generating priority
i will have a look at the code later tonight and if i have any questions i will let you know
Matt Joiner
@anacrolix
Jun 13 2017 15:02
that's right
it's worth watching the client in action, by hooking up the writestatus to some endpoint
watch what pieces the conns prioritize when ur readers seek about
dimitriss
@dimitriss
Jun 13 2017 15:03
Yes, I'm running with debugging and i can see the priorities and the completion progress
i will add a couple of PiecePriorities
Matt Joiner
@anacrolix
Jun 13 2017 15:09
hm my last 2 messages disappeared. take a look at connection.go:537 and connection.go:212
dimitriss
@dimitriss
Jun 13 2017 15:10
Thanks. I will make the changes, test it thoroughly and issue a PR
Matt Joiner
@anacrolix
Jun 13 2017 15:11
great, good luck