[00:10:06] *** semaphore has joined #bittorrent
[00:10:40] <semaphore> hi.  how do most people calculate a torrent's 'health'? it's more than just leechers divided by seeds, isn't it?
[00:11:52] <DreadWingKnight> a lot more
[00:12:08] <DreadWingKnight> it's possible to have a perfectly healthy torrent with 0 seeds actually
[00:12:43] <semaphore> is this documented someplace? i don't recall seeing it
[00:12:49] <semaphore> er, formula, perhaps
[00:14:02] <DreadWingKnight> it has to do with how the download gets segmented
[00:14:16] <DreadWingKnight> as long as there's at least one copy of every segment, it doesn't matter who has it
[00:14:48] *** jamie_k has quit IRC
[00:14:57] <semaphore> i can't do that from just the seed/leech count, i'd have to ask the tracker
[00:15:35] <DreadWingKnight> the tracker doesn't have that information
[00:16:41] <semaphore> so i'd have to connect to the peers which i could and tally up who has what pieces?
[00:17:46] <DreadWingKnight> and given the size of some torrent swarms, that isn't always practical
[00:17:57] <DreadWingKnight> most current clients have an availability value in them
[00:18:08] <DreadWingKnight> if that's greater than 1.0, the torrent should be considered healthy
[00:18:46] <semaphore> yeah, but this isn't a client, techincally
[00:19:51] <DreadWingKnight> torrent indexers have no real way to tell if a swarm is healthy or not
[00:20:08] <semaphore> they have arbitrary bar graphs and things for it
[00:20:28] <semaphore> wait, how can a torrent be healthy if it has 0 seeds
[00:20:40] <semaphore> i thought health is that 'there's someone seeding'
[00:20:46] <DreadWingKnight> nope
[00:20:54] <DreadWingKnight> again, segmented download
[00:21:04] <DreadWingKnight> doesn't matter who has the segments
[00:21:11] <DreadWingKnight> if they're all there, the torrent is healthy
[00:21:17] <semaphore> how often does that happen?
[00:21:18] <DreadWingKnight> they don't have to all be in the same place
[00:21:40] <DreadWingKnight> often enough for me to completely ignore any "health" graphs any index sites have
[00:22:11] <semaphore> no, how often do two people each initally seed half a torrent so that it's healthy
[00:22:26] <Switeck> It's only practical to connect to maybe 50-100 peers+seeds.
[00:23:00] <Switeck> To even reach 50, a torrent will probably claim there's 200+
[00:23:28] *** KyleK_ has quit IRC
[00:23:55] <semaphore> okay, but on a smaller scale, like a swarm of 3... someone pretty much has it, or they don't
[00:24:52] <DreadWingKnight> it's still possible to be a healthy torrent with no seeds down as low as 2 peers
[00:25:09] <semaphore> but i'm saying it's not as probable
[00:25:20] <semaphore> and thant one seed will have it all
[00:25:54] <Switeck> A "seed" that's running 10+ other torrents with 1 KB/sec global upload speed hardly counts -- but even availability won't take that into account.
[00:25:58] <DreadWingKnight> ultimately though, the point is that any index site you come across is NOT going to have accurate information about a given swarm
[00:26:25] <semaphore> DreadWingKnight: unless it somehow joins the swarm?
[00:27:57] <DreadWingKnight> even then, the information can't be guaranteed as accurate
[00:28:07] <semaphore> right
[00:28:13] <semaphore> okay, thanks for clearing that up
[00:28:16] <DreadWingKnight> because the resources required to maintain an accurate idea of the swarm simply don't exist on a single computer
[00:29:37] <semaphore> thus the whole point of the swarm
[00:29:50] *** _rafi_ has quit IRC
[00:38:21] <The_8472> <semaphore> hi.  how do most people calculate a torrent's 'health'? it's more than just leechers divided by seeds, isn't it? <- a simple measure is the availability of the rarest piece when excluding seeds
[00:38:36] <The_8472> i have come up with something that i think is better but that's mostly academical
[00:46:34] <semaphore> The_8472: that's kinda... theoretical if determining that is less than trivial
[00:48:02] <Switeck> The_8472, does your method take into account seeds and peers that give essentially nothing...or 100 mbit/sec seedboxes?
[00:56:01] <The_8472> well, i could take the swarm throughput into account, but i'm not doing that atm, no
[00:57:37] <The_8472> but i'm ignoring seeds completely anyway
[01:03:54] *** neurodrone has quit IRC
[01:07:00] *** thomas_sch has quit IRC
[01:15:13] *** thomas_sch has joined #bittorrent
[01:33:15] *** senex has joined #bittorrent
[01:45:29] *** ProperNoun has quit IRC
[02:18:46] *** neurodrone has joined #bittorrent
[02:41:53] <Switeck> Why are uTorrent v2.0 peers trying to connect to me when they're already connected to me?
[02:42:31] <Switeck> This seems to be default behavior now. :(
[02:47:28] <Switeck> The worst part is the existing connections are incoming to me...so no port change!
[02:47:47] *** neurodrone_ has joined #bittorrent
[02:48:02] <DeHackEd> okay that's dumb
[02:49:03] *** neurodrone_ has quit IRC
[02:50:06] <Switeck> ]even bitcomet now (usually) seems to quit when it makes 1 incoming connection to me.
[02:53:18] <Switeck> great, now they're banning me
[02:53:32] <Switeck> [2010-02-12 20:01:19]  Incoming connection from 165.228.183.46:55437 for torrent 'UNKNOWN'
[02:53:34] 
[02:53:36] 
[02:53:38] 
[02:54:38] 
[02:54:55] <Switeck> http://img682.imageshack.us/img682/4041/ut20utpvstcpon3peers.png
[02:56:15] <Switeck> that's so completely failing I don't know where to even begin
[02:56:23] <Nolar> <The_8472> alus, for the udp proxy... you're forgetting about the source IP  << already standard http headers for that
[02:56:23] <Nolar> <The_8472> not to mention that you still would do tons of tcp connections << keep-alive to the backend
[03:57:26] <Switeck> Can someone confirm if uT v2.0 is attempting reconnects to other BitTorrent clients even when already connected? (It'd be using UDP, so the client themselves may not notice.)
[04:00:15] *** The_8472 has quit IRC
[04:05:53] *** The_8472 has joined #bittorrent
[04:16:29] *** ivan``` has quit IRC
[04:19:25] *** jamie_k has joined #bittorrent
[04:59:53] *** punto has quit IRC
[05:00:21] *** punto has joined #bittorrent
[05:09:53] *** ajaya has quit IRC
[05:15:24] *** K`Tetch has quit IRC
[05:36:55] *** neurodrone has quit IRC
[05:38:51] *** goussx has quit IRC
[05:41:16] *** init0 has quit IRC
[05:43:02] *** init0 has joined #bittorrent
[05:53:20] <alus> Nolar: indeed, standard headers and one TCP connection.
[05:53:32] <alus> The_8472: yes, uT upgrades from TCP to uTP if possible
[05:53:47] <alus> Switeck: what's wrong with that picture?. the two peer tabs?
[05:54:39] <Switeck> those 2 peer tabs show the same peers, once with uTP and again with TCP.
[05:54:45] <alus> mhm.
[05:54:46] <Switeck> with uTP, they were *DEAD*
[05:54:54] <alus> Switeck: do you have bt.tcp_rate_control off?
[05:54:57] <Switeck> sometimes, there'd be a short burp of <1 KB/sec
[05:55:07] <Switeck> I tested with both bt.tcp_rate_control true and false
[05:55:17] <Switeck> it seemed to have little effect on this.
[05:55:31] <alus> perhaps there are too few uTP connection for bt.tcp_rate_control to take effect
[05:55:55] <alus> if that's true, TCP will perform unthrottled, which will cause uTP to back off
[05:56:08] <alus> appearing "dead", because your internet connection is congested
[05:56:22] <Switeck> At times, I had up to 6 uTP peers...and was trying to upload to all of them.
[05:57:00] <alus> do this. set a very low upload rate limit, like 10% of normal. turn off bt.tcp_rate_control, turn on bt.ratelimit_tcp_only
[05:57:51] <Switeck> I banned all the uT v2.0 peers sometime after the test out of disgust
[05:58:07] <Switeck> for the reconnect hammering behavior.
[05:58:15] <alus> what bt.ratelimit_tcp_only is hopefully exactly what it sounds like. any rate limit applies only to TCP peers. uTP is left unthrottled
[05:58:24] <alus> uT 2 does not reconnect hammer.
[05:58:46] <Switeck> it's a bug then, because it *DOES*
[05:58:53] <alus> shwo me
[05:58:55] <alus> er, show me
[05:58:59] <Switeck> I'm already connected to it, by an incoming connect
[05:59:07] <alus> TCP or uTP?
[05:59:09] <Switeck> and it's *STILL* trying to connect to me!
[05:59:14] <Switeck> TCP probably
[05:59:19] <alus> ... TCP or uTP?
[05:59:20] <Switeck> because uTP often instantly fails.
[05:59:32] <Switeck> ...due to anotehr bug
[05:59:34] <alus> when?
[05:59:37] <alus> what bug?
[05:59:59] <Switeck> I don't know what triggers the instant disconnect bug in the sourcecode
[06:00:29] <alus> well can you describe it? when does it disconnect?
[06:01:09] <Switeck> [2010-02-12 20:01:19] Incoming connection from 165.228.183.46:55437 for torrent 'UNKNOWN'
[06:01:11] 
[06:01:13] 
[06:01:15] 
[06:01:19] <Switeck> You tell me
[06:01:41] <Switeck> within 2 seconds of encrypted handshake complete...it disconnects.
[06:01:57] <alus> gracefully
[06:02:15] <alus> for some reason it decided it did not want the connection.
[06:02:54] <alus> can you get this to happen between two local uT 2.0 peers you run?
[06:03:15] <Switeck> I saw it a couple times in tests in the past
[06:03:17] <Switeck> local tests
[06:03:46] <Switeck> but I don't know if that was the same bug or a different bug
[06:03:58] <Switeck> and I can't reliably get it to happen.
[06:06:33] <alus> ok, so it's probably not something that happens all the time, either
[06:07:17] <alus> but, I'll look in to it
[06:07:27] <alus> all the more reason to implement "disconnect reason"
[06:08:49] *** goussx has joined #bittorrent
[06:10:33] <Switeck> Right now I have 3 uTP peers that want to run at 0.1 KB/sec
[06:10:43] <Switeck> I allowed them back in
[06:11:13] <alus> ok...
[06:11:24] <alus> did you try the ratelimit_tcp_only trick I mentioned?
[06:11:48] <Switeck> bt.tcp_rate_control = false, bt.ratelimit_tcp_only = true
[06:11:55] *** MassaRoddel has quit IRC
[06:11:56] <Switeck> no good
[06:12:49] <Switeck> unless you want me to do more testing to them, I'll just ban them again :(
[06:13:04] <alus> and you dropped your rate limit to something very small?
[06:13:28] <alus> set it at like 1 kB/s just to test
[06:13:52] <Switeck> that's a bomb
[06:13:56] <alus> what?
[06:13:59] <Switeck> all upload slots went from U to u
[06:14:21] <alus> oh. set it at like 5
[06:14:37] <alus> and wait about a minute
[06:15:06] <Switeck> uTorrent selects everything else to upload to in the meantime :P
[06:16:23] <Switeck> I banned all but the uTP peers
[06:16:30] <Switeck> now what?
[06:16:38] <alus> "selects everything else to upload"?
[06:17:23] <Switeck> how?
[06:17:32] <alus> how what?
[06:17:48] <Switeck> oh, I mean uTorrent refused to upload to the uTP peers...they stayed "u" flagged
[06:17:54] <alus> hmph.
[06:19:04] <alus> ok, if you banned the other peers that's fine
[06:19:25] <alus> the question is, in the absense of congestion due to TCP, does uTP with those same peers upload a bunch?
[06:19:44] <Switeck> no
[06:19:53] <alus> hm.
[06:20:05] <alus> and what are you ping times to google.com like while this is going on?
[06:20:32] <Switeck> the inactive column for them seems to want to count upwards to about 2-10 minutes as well
[06:21:01] <Switeck> about 50 ms
[06:21:30] <alus> hm.
[06:21:40] <alus> perhaps it's download congestion on their end
[06:22:00] <Switeck> I can upload just fine to them when I force TCP...
[06:22:14] <Switeck> I just get constant incoming connections from them to "upgrade" to uTP
[06:22:26] <alus> yeah, but maybe you're just pushing other TCP connections out of the way, not actually increasing their download speed
[06:22:40] <Switeck> the ways I have checked have ruled that out.
[06:22:46] <alus> hm?
[06:23:02] <Switeck> oh you mean their download speed?
[06:23:30] <Switeck> if they're at max downoad speed maybe...but as non-busy as the torrents I'm on, that seems exceedingly remote for *ALL* of them to act that way!
[06:23:31] <alus> yeah
[06:23:49] <alus> well you're saying uploading over uTP never does anything at all
[06:23:57] <Switeck> not quite
[06:23:59] <alus> which is obviously false. there has to be congestion somewhere
[06:24:03] <Switeck> sometimes it sputters along for awhile
[06:24:16] <Switeck> then it fails utterly again and seems to prefer to stay that way. :P
[06:24:16] <alus> right, when there is space in a buffer somewhere
[06:24:29] <alus> fail is the wrong word there. it's not needed
[06:24:32] <Switeck> the problem is not lack of bandwidth on my end.
[06:24:37] <Switeck> no, fail
[06:24:40] <alus> true. excess, in fact
[06:25:09] <Switeck> it is a failure to hold open upload slots but then get "stuck" at 0.1 KB/sec (actually 0 due to the shown inactive times)
[06:25:12] <alus> I don't know why you call that fail. did you really want to be uploading uselessly?
[06:25:34] <Switeck> there is a very low probability that they are maxed out.
[06:25:51] <alus> that's the only explanation I can see
[06:25:53] <alus> can you prove otherwise?
[06:25:55] <Switeck> With each additional one doing the same dang thing (and I've seen about 10 just today)
[06:26:01] <Switeck> *ALL* going 0.1 KB/sec
[06:26:08] <Switeck> you really better be the one trying harder, not me!
[06:26:21] <Switeck> because it happens on multiple torrents
[06:26:22] <alus> well, I can't prove there is a problem.
[06:26:30] <alus> here, try this:
[06:26:52] <alus> stop the torrents or exit. start up a fresh uT with empty resume.dat, and try to download that same torrent
[06:26:56] <Switeck> if I added *ALL* my torrent swarms together, even counting the ones that have seeds but no peers...it might be 50 total
[06:27:07] <alus> perhaps there is so much excess capacity you will get a full download rate
[06:28:38] <alus> this is of course not a perfect test. there would need to be (C + your download rate) capacity. but if you get very high download rate it certainly proves it
[06:28:59] <alus> if you don't it doesn't entirely. you might be fighting to pull your share, where if you left there would be plenty for everyone
[06:29:16] <Switeck> working on it
[06:33:35] *** kwinz2 has quit IRC
[06:33:52] <Switeck> I'm still waiting for it to hit 1 KB/sec
[06:34:26] <Switeck> it keeps breaking connection to everything with default uT v2.0 settings
[06:35:46] <Switeck> whups, only had max connections per torrent set to 10 XD
[06:37:15] <Switeck> raised to 90
[06:37:23] <Switeck> top speed I saw was <2 KB/sec download
[06:37:35] <alus> try TCP only
[06:37:37] <Switeck> This torrent's crying for seeds
[06:37:57] <alus> perhaps they have other torrents going to. kind of impossible to tell
[06:38:45] <Switeck> that much may seem likely for some or even many, but since I'm seeing absolutely terrible results also...I deem it unlikely as a total answer
[06:39:25] <alus> well you can't really prove it one way or the other
[06:39:44] <Switeck> speeds picked up, now it's managing right at 1 KB/sec download now
[06:39:49] <alus> and the choices are some logically explanation we can't disprove, or some mysterious bug we have absolutely no insight on
[06:39:58] <alus> s/logically/logical/
[06:40:23] <alus> so if I had to place bets, I'd bet on the logical explanation
[06:46:39] <Switeck> http://pastebin.com/m7f1fb08b
[06:49:45] <TheSHAD0W> Looks like an error in the protocol implementation to me.
[06:50:00] <TheSHAD0W> Complete handshake followed soon by a disconnect.
[06:50:37] <TheSHAD0W> If only there were a way to have the community review the source code...
[06:52:14] <alus> that's not a protocol implementation problem
[06:52:45] <alus> there's probably some sort of race condition after it receives the peer ID
[06:53:00] <alus> TheSHAD0W: yeah, because the community writes such great sourcecode
[06:53:17] <TheSHAD0W> A race condition is a protocol implementation problem.  :-P
[06:53:31] <alus> uh, no
[06:53:34] <TheSHAD0W> Unless it's a protocol design problem.
[06:53:36] <alus> this is between two connections.
[06:53:37] <TheSHAD0W> One or the other.
[06:53:43] <alus> it's not a protocol issue at all
[06:53:49] <alus> it's a peer list management issue
[06:53:55] <Switeck> http://pastebin.com/d1b1788ec
[06:54:05] <TheSHAD0W> Expired.
[06:54:07] <Switeck> oops, that one's gone
[06:54:30] <alus> Switeck: I get the idea. more logs aren't going to help unless you have logs from the other side
[06:55:05] <Switeck> how about you be the other side then :P
[06:55:13] <alus> ok. give me a torrent to run
[06:55:26] <Switeck> test torrent, get a url and pass it along :)
[06:55:39] <alus> I don't have one handy. do you?
[06:55:59] <Switeck> <- eating :P
[06:56:03] <alus> you're the seed in your case, so I think you should be the seed here too
[06:56:14] <alus> make a torrent out of a large file, pass me the magnet URI
[06:56:22] <Switeck> openoffice is small enough
[06:56:36] <alus> I'd rather not involve other peers, if possible
[06:56:40] <alus> make it easier to read
[06:58:36] <Switeck> ok
[06:59:28] <Switeck> be easier if you made a small torrent then
[06:59:33] <Switeck> ~20-50 MB in size
[06:59:45] <Switeck> or maybe up to 300 MB size
[07:00:59] <Switeck> I can make one of the Pinwheel galaxy pic I have...it's 60 MB :P
[07:02:40] <alus> fine
[07:05:35] <Switeck> email sent
[07:10:49] *** danohuiginn has quit IRC
[07:13:17] <alus> aw, why not a magnet URI?
[07:13:34] <Switeck> don't know how
[07:14:03] <alus> right-click the torrent in uT, select "Copy Magnet URI"
[07:14:06] <alus> pm it to me
[07:14:12] <alus> TheSHAD0W: do you support magnet URIs?
[07:17:11] <TheSHAD0W> Nope.
[07:17:52] <alus> hm, If only there were a way to have the community contribute the source code...
[07:17:54] <alus> :P
[07:18:21] <TheSHAD0W> I don't think it'd be that difficult to implement, it'd just take a little time.
[07:18:33] <TheSHAD0W> Maybe I'll play with it tomorrow.
[07:18:51] <TheSHAD0W> Gotta code up the protocol extensions.
[07:20:00] <TheSHAD0W> Actually, looks like LH-ABC has it already.
[07:21:40] <TheSHAD0W> Time to collapse, goodnight.
[07:21:46] <alus> goodnight
[07:24:35] <GTHK> That ratelimit tcp only option doesn't seem to be working for me. I was hoping I could devote some bandwidth to TCP and then let uTP take up whatever slack is left :<
[07:25:02] <alus> it should work..
[07:26:25] <alus> oh! I have it backward.
[07:26:55] <alus> it doesn't use the explicit rate you set, it uses the rate the bt.tcp_rate_control picks
[07:27:28] * alus looks more
[07:28:29] <GTHK> Is that why when I had TCP and UDP on, and rate limit TCP only, the speed limit was shifting on its own and the whole thing spazzing out terribly?
[07:28:32] <alus> hm. yeah, so set your limits to unlimited. enable bt.tcp_rate_control, enable bt.ratelimit_tcp_only
[07:29:18] <GTHK> uTP only works great btw, but that's not something I want to run with on dying torrents..
[07:34:31] <GTHK> Being able to specify a cap for TCP and let uTP do its thing seems like it would work out well, and would get around the whole tcp_rate_control not doing a good enough job thing :P
[07:37:25] <alus> well, sort of
[07:37:31] *** fjl9 has joined #bittorrent
[07:37:56] <alus> the problem with tcp_rate_control is usually that there is some very fast TCP connection, and insufficient uTP peer capacity
[07:38:04] <alus> so for example when there is an ISP seed which runs TCP
[07:38:19] <alus> so being able to set a TCP rate limit will not really help you there. you want TCP to be unlimited
[07:38:54] <fjl9> hey guys, small question. I'm downloading a large torrent at the moment, and it's going very slow... I've observed one peculiar thing: I'm intermittently uploading 0.1 KB/s to lots of peers. what could be going on here? (my speed by the way is ~15 mega bits down/1 mega bit up)
[07:39:21] <Switeck> you on uTorrent v2.0 or v2.1?
[07:39:49] <GTHK> No I don't, tcp clearly can't regulate itself :P | Also, my GUI fubared itself D:
[07:42:18] <alus> fjl9: probably sending HAVE messages, PEX, things like that
[07:43:13] *** MassaRoddel has joined #bittorrent
[07:43:29] <fjl9> Switeck, if that was to me, I'm on Transmission
[07:43:37] <Switeck> ah
[07:43:40] <fjl9> alus, it's only happening with one torrent, if that's worth something
[07:44:30] *** rot has quit IRC
[07:44:31] <Switeck> how many are you uploading to faster than 0.1 KB/sec?
[07:44:34] <Switeck> about 20?
[07:45:40] <alus> fjl9: what are the Flags for those peers? do you see "U" or "u"?
[07:45:48] <fjl9> "downloading from 13 of 25" ... uploading .1 KB/sec to about 10
[07:46:41] <fjl9> alus, both
[07:48:15] <alus> fjl9: does it correlate to whether you're uploading to them?
[07:50:03] <fjl9> alus, I'm not downloading from them at all
[07:51:48] <alus> fjl9: I don't understand how that's related
[07:54:42] <fjl9> whoops, sorry, I wasn't all here there for a sec -- anyways, here's a screenshot in which you can see the speeds. I just find it suspicious, and perhaps symptomatic of some sneaky problem? - http://i.imgur.com/Zb0qV.png
[07:55:29] <fjl9> isn't it true that when a torrent is particularly active, I should get good speeds? I'm getting 20 KB/sec
[07:55:40] <fjl9> and it's a rather large torrent, so that's.. not good :)
[07:57:02] <fjl9> (er, probably should have maximized the window, sorry for the cluttered ss)
[07:57:42] <alus> large doesn't mean there is a lot of excess capacity for you
[07:58:00] <alus> what client is that?
[07:58:18] <fjl9> Transmission
[07:58:22] <alus> oh
[07:58:23] <alus> charles: ping
[07:59:19] *** wereHamster has joined #bittorrent
[08:00:14] <GTHK> alus, Why does rate limit tcp only make the icons look like crap D: (and what is the purpose of that setting)?
[08:01:52] <alus> ratelimit_tcp_only changes the icons? o.O
[08:02:25] <GTHK> Yes, it reminds me of VirtualBox running Windows Me (but only the icons in the main window, not the toolbar).
[08:02:34] <alus> it should not change any icons.
[08:02:36] <GTHK> http://img205.imageshack.us/img205/3410/79961348.png
[08:02:48] <alus> the purpose of ratelimit_tcp_only is to use your global rate limits in the absence of data from uTP peers.
[08:03:00] <alus> so if there are uTP peers, it limits TCP based off that data, and does not limit uTP
[08:03:10] <alus> when there are not uTP peers, it limits TCP using your global rate limits
[08:03:12] <Switeck> should I have that set to true?
[08:03:53] <alus> Switeck: not for this test
[08:04:11] <GTHK> I was able to produce it reliably a few times, but it just stopped :<
[08:04:18] <alus> wtf
[08:04:27] <alus> you said earlier "Also, my GUI fubared itself D:"
[08:04:28] <GTHK> Time for someone to dig through code..
[08:04:31] <alus> is that related?
[08:04:44] <GTHK> Yea, it's what I was referring to.
[08:07:34] <alus> the screenshot you posted looks fine to me
[08:07:38] <alus> what's wrong with it?
[08:10:08] <GTHK> Category view icons and the torrent status icons are wrong. If you can't see it, I have a big problem with my graphics right now.
[08:13:38] <GTHK> Tell me you can see it ;-;
[08:22:50] <alus> oh, I see
[08:23:10] <alus> not ruling out you having a big problem with your graphics, though :P
[08:23:13] <alus> are you skinning uT?
[08:24:34] <GTHK> No.
[08:24:57] *** edigaryev has joined #bittorrent
[08:25:03] <alus> odd..
[08:25:32] <GTHK> I changed that option 6 times and restarted with effect before it stopped behaving that way.
[08:33:00] *** _rafi_ has joined #bittorrent
[09:05:41] *** rot has joined #bittorrent
[09:40:01] *** neurodrone has joined #bittorrent
[10:15:43] *** kwinz2 has joined #bittorrent
[10:30:26] *** GTHK has quit IRC
[10:50:19] *** jamie_k has quit IRC
[10:53:00] *** Andrius has joined #bittorrent
[11:25:52] *** _rafi2_ has joined #bittorrent
[11:29:44] *** _rafi_ has quit IRC
[11:56:41] *** KyleK_ has joined #bittorrent
[11:58:26] *** senex has quit IRC
[12:06:09] *** _rafi2_ has quit IRC
[12:37:36] *** Switeck has quit IRC
[12:42:06] *** edigaryev has quit IRC
[12:43:48] *** _rafi_ has joined #bittorrent
[13:32:39] *** n215 has quit IRC
[13:37:01] *** n215 has joined #bittorrent
[14:12:32] *** jamie_k has joined #bittorrent
[14:34:26] *** jamie_k has quit IRC
[14:46:19] *** n215 has quit IRC
[14:46:19] *** n215 has joined #bittorrent
[14:49:38] *** punto has quit IRC
[14:49:58] *** punto has joined #bittorrent
[14:52:26] *** neurodrone has quit IRC
[15:19:10] *** danohuiginn has joined #bittorrent
[15:25:00] *** edigaryev has joined #bittorrent
[15:25:02] *** SeanNoble has quit IRC
[15:25:18] *** SeanNoble has joined #bittorrent
[15:45:18] *** _rafi_ has quit IRC
[15:50:27] *** _rafi_ has joined #bittorrent
[15:55:17] *** jamie_k has joined #bittorrent
[15:55:22] *** KyleK_ has quit IRC
[16:00:44] *** cgreco has quit IRC
[16:01:16] <burris> I don't necessarily think this is a good idea, but if torrent files had some parity data, say one piece worth per large file in the torrent, then it would protect against stuck torrents from people/players changing file metadata and clients disappearing immediately after finishing
[16:02:02] <DeHackEd> changing metadata breaks the torrent. you can't download from people who have different metadata at all..
[16:02:44] *** cgreco has joined #bittorrent
[16:02:44] *** cgreco has joined #bittorrent
[16:03:08] <burris> I'm dling a torrent where everyone is stuck waiting for the first piece of every track, I believe because the guy changed the flac metadata after he started his torrent client
[16:03:24] <burris> http://bt.etree.org/details.php?id=532373
[16:03:27] <TheSHAD0W> Oops.
[16:04:29] <TheSHAD0W> Well.
[16:04:35] <burris> he might not have done it on purpose, he was probably listening to it while seeding
[16:04:50] <TheSHAD0W> The length of the metadata has to be the same or it would've broken the entire torrent.
[16:05:07] <TheSHAD0W> So it might be possible to find the change and undo it.
[16:05:14] <DeHackEd> if it's at the start of every file, then it's almost certainly an inplace modification
[16:05:38] <burris> yes, the way flac works is it reserves a block for the metadata when creating the file, so updating track names and stuff won't change the length or the offsets of data in the torrent
[16:06:18] <kjetilho> burris: would be nice if a client allowed you to override automatic blacklisting and say "that's OK, I trust the data from that source"
[16:06:37] <DeHackEd> but then the first chunks can't be redistributed
[16:06:45] <TheSHAD0W> Well.
[16:06:47] <kjetilho> it's funny the seed didn't get blacklisted by everyone?
[16:06:53] <alus> burris: unless the names are reaaaallllyyy long?
[16:07:17] <The_8472> <kjetilho> burris: would be nice if a client allowed you to override automatic blacklisting and say "that's OK, I trust the data from that source" <- your client will download the data anyway (and probably write it to disk too)
[16:07:21] <The_8472> it'll just fail the check
[16:07:24] <TheSHAD0W> That client is the only one which is uploading data for that piece; assuming the client is coded to write the data before testing it, you'll have the bad data anyway.
[16:07:32] <The_8472> so you already have the pieces. just the wrong ones
[16:07:41] <The_8472> exactly
[16:07:47] <burris> ut isn't writing the data to disk, flac barfs on the files
[16:07:53] <TheSHAD0W> Hm.
[16:07:57] * TheSHAD0W shrugs
[16:08:01] <TheSHAD0W> Use BitTornado.  :-P
[16:08:04] <TheSHAD0W> Or Vuze.
[16:08:34] <TheSHAD0W> uT really ought to be writing the data, then re-reading it to check the hash, as a consistency measure.
[16:08:38] <burris> maybe we could digitally bitchslap the seeder and get him to do it again
[16:08:53] <kjetilho> TheSHAD0W: that's a security problem, actually.  if you download an EXE file and get a bogus block, you could get infected if you try to run it before the download completes
[16:09:06] <TheSHAD0W> Well.
[16:09:11] <TheSHAD0W> Possibly...
[16:09:27] <burris> alus and anyone in sf, barleywine festival at the toronado today w00t!
[16:09:52] <alus> !
[16:10:26] <The_8472> kjetilho, who the hell would start an incomplete exe file?
[16:10:34] <burris> I'm going to go get in line soon, bring two cardboard sixpack carriers
[16:10:34] <kjetilho> The_8472: impatient people
[16:10:41] <The_8472> they deserve to be infected
[16:10:45] <kjetilho> hehe
[16:10:57] <alus> TheSHAD0W: it's probably in the cache, unflushed
[16:11:41] <The_8472> burris, btw... the piece has to be downloaded at least once of course (even if it failed). if it was never downlaoded you can't have it on the disk of course
[16:23:54] *** _rafi_ has quit IRC
[16:27:06] *** danohuiginn has quit IRC
[16:28:15] <TheSHAD0W> Burris: It also might not be a metadata error.  It could be corruption induced by a router set to game mode.
[16:28:22] <TheSHAD0W> I've unfortunately seen that happen a lot.
[16:34:42] <The_8472> encrypted connections should help in that case
[16:34:52] <The_8472> because the data won't look the same every time
[16:36:32] *** KyleK_ has joined #bittorrent
[16:44:05] <TheSHAD0W> Yup.
[16:50:57] *** jamie_k has quit IRC
[16:53:19] *** SeanNoble has quit IRC
[16:53:54] *** SeanNoble has joined #bittorrent
[16:58:05] *** danohuiginn has joined #bittorrent
[17:04:13] *** danohuiginn has quit IRC
[17:40:17] *** Elrohir has joined #bittorrent
[17:49:19] *** neurodrone has joined #bittorrent
[18:01:45] *** Gottaname2 has joined #bittorrent
[18:02:32] *** Gottaname has quit IRC
[18:34:53] *** punto has quit IRC
[18:35:12] *** punto has joined #bittorrent
[18:37:47] *** GTHK has joined #bittorrent
[18:48:04] *** edigaryev has quit IRC
[18:55:08] *** Elrohir has quit IRC
[19:06:04] *** punto has quit IRC
[19:06:22] *** punto has joined #bittorrent
[19:14:32] *** punto has quit IRC
[19:20:24] *** punto has joined #bittorrent
[19:25:42] *** punto has quit IRC
[19:29:39] *** fjl9 has quit IRC
[19:32:32] *** punto has joined #bittorrent
[19:39:11] *** punto_ has joined #bittorrent
[19:41:12] *** punto has quit IRC
[19:43:51] *** punto_ has quit IRC
[20:26:27] *** trelane has joined #bittorrent
[21:40:14] *** punto has joined #bittorrent
[21:46:38] *** punto has quit IRC
[22:12:52] *** punto has joined #bittorrent
[22:17:25] *** punto has quit IRC
[22:56:42] *** punto has joined #bittorrent
[23:08:38] *** punto has quit IRC
[23:09:01] *** punto has joined #bittorrent
[23:13:23] *** punto has quit IRC
[23:30:35] *** SeanNoble has quit IRC
[23:30:49] *** punto has joined #bittorrent
[23:31:11] *** SeanNoble has joined #bittorrent
[23:40:42] *** punto has quit IRC
[23:41:26] *** Miller` has quit IRC
[23:43:00] *** Switeck has joined #bittorrent





top