Level-4 log
Using tixati 1.96. Peer identified itself as KTorrent 2.2.6 (I think...I posted this last week, but apparently that got stuck between forum movements).

time to time uploads for uTorrent 3.3 is blocked
[23:00:37]  remote has piece 3987
[23:00:38]  remote has piece 2301
[23:00:39]  remote has piece 3710
[23:00:41]  remote has piece 1500
[23:00:41]  Stopped: Block request buffer overflow
[23:00:41]  going offline
[23:01:21]  going online
[23:01:21]  receiving secure incoming connection
[23:01:21]  sending handshake
[23:01:22]  logged in OK
[23:01:22]  sent bitfield
[23:01:22]  received bitfield, 1466 of 4931 pieces complete (29%)
[23:01:24]  remote interested in local
[23:01:28]  local unchoked remote for charity
[23:01:32]  remote has piece 4591
[23:01:36]  remote has piece 1849
[23:01:39]  remote has piece 4634
[23:01:44]  remote has piece 909

I am experiencing the same problem.
Also (at the moment) with µTorrent 3.3, but have seen it happening with libtorrent 13.4

Bump!!

This really needs some attention soon.

It seems to happen, when the leecher wants to increase the bandwidth.
I have 1 user with with libtorrent 0.13.3 who kan download>5MB/sec and I am capable of delivering it.
The leecher connects, everything is Ok.
The leecher starts asking for more Bandwidth, and at a certain paint Tixati disconnects the user with the status "Block request buffer overflow".

[17:35:29]  remote has piece 2911
[17:35:32]  remote has piece 1236
[17:35:36]  remote has piece 2669
[17:35:39]  remote has piece 2953
[17:35:41]  remote has piece 2801
[17:35:42]  Stopped: Block request buffer overflow
[17:35:42]  going offline
[17:35:43]  going online
[17:35:43]  receiving secure incoming connection
[17:35:43]  sending handshake
[17:35:43]  logged in OK
[17:35:43]  sent bitfield
[17:35:43]  received bitfield, 642 of 7169 pieces complete (8%)
[17:35:46]  remote interested in local
[17:35:52]  local unchoked remote for charity
[17:35:58]  remote has piece 2866
[17:36:00]  remote has piece 2623
[17:36:03]  remote has piece 2586
[17:36:06]  remote has piece 2847
[17:36:06]  Stopped: Block request buffer overflow
[17:36:06]  going offline

Affected clients: µtorrent 3.3.2 and 3.4.0 beta (for Windows clients only).

I found how to solve it: limit peer upload to 1000 kB/s.
When the peer downloads from me at more than 1MB/s, the transfer uses to stop.


Also, I have problems seeding to qBittorrent v3.1.5 clients (10:110), but that's another story.

Client configuration (Tixati 1.96, under Linux Kubuntu x64):
- Outgoing peer connection encription: Encrypted only
- Incoming peer connection encryption: Encrypted only
- Outgoing peer connection protocol: UDP > TCP
- Incoming peer connection protocol: TCP = UDP
- Peer connect / login timeouts: 40 / 40
- Advanced socket options: (by default)

Are you guys using auto limit feature in the Bandwidth page. If yes  go to rules and look at throttle ratio. What is that number? Also upload and download speeds from speedtest?

BTW encryption only is secure but not friendly. It creates it's own problems. Client should be set to receive both encrypted or not for maximum compatibility. Yes little cost to security.

v1.96, Win 7
Have seen many sustained uploads at well over 1M w/o this problem.  Maybe something to do with router or Windows setup?  But then again, I don't look at the logs or individual peer/sseeder speeds to see if your issue is actually happening.

This error appears when a leech downloads so fast, that he requests too much blocks at once, more than Tixati's buffer can hold. Unfortunately I don't know what is the buffer size, I don't have high enough upload bandwidth ;) You can see a number of block requests on Peers tab's Status column, next to red-green "IN LI RC OUT LC RI" indicator - the "LQ" value (you'll need to widen the column to see this). The same information is on each peer's Properties.

From Tixati help:

Same problem here! I run v.1.96 on win7 x64
Is there an option to adjust the buffer size, or should we wait for an update? Recently use Tixati. I like it and this is my first disappointment! :(
I want to continue use Tixati, please tell me a decision.
Thanks in advance!

"LQ" value: with 1MB/s limit to a peer, the value keeps between 180 and 200. Maybe that 200 it's the limit.

Without the 1MB/s limit, "LQ" value sometimes can vary too much, from 30 to xxx and the buffer overflow error appears. Perhaps the peer tried to ask for 400-500 blocks.

I use the bandwidth "limit outgoing" to 100000 kB/s (max.upload capacity: 200Mbits).

I'm still having the problem of "buffer overflow" with Tixati version 1.99.

REQUEST: Please, allow at least 500 or 1000 LQ for upload in future versions of Tixati instead of 200: people with high upload speed can't use this client due to this restriction (Tixati kicks to many clients, as µtorrent and qBittorrent if downloads from Tixati at more than 1250kB/s ~ 2500kB/s).
Or at least, an option selectable for high upload capacity connections (500/1000 LQ instad of 200 LQ).

Just to note, I have a 100/100mbps connection and I'm hitting this same exact issue as well.

Any update on this problem?

Yes, this is a serious problem. I can't even seed properly to certain clients like utorrent 3.x or bittorrent 7.x I love Tixati, but this is the only thing keeping me from using it. I'm running Win 7 64-bit and Tixati 1.99 btw.

I am experiencing the same problem.
I will explain:

I am moving some files from my new PC to my old PC
New PC is running Win 8.1 x64, Tixati 2.16/x64, created a torrent of my files (120GB), chunk size 8MB
Old PC is Win 7 x86, I have both uTorrent 3.3 and Tixati 2.16 installed.

If I use uTorrent 3.3 it seems to rapidly create block requests and I experience the block request buffer overflow error. If I limit the outgoing bandwidth to around 1 MiB/s it's working (and uTorrent is running into its crappy writing cache problems, but that's not important here)

If I use Tixati 2.16/x86 it issues always at maximum 96 requests, which leads to an effective download rate of 1.9 to 2.0 MiB/s.

They are connected using fast ethernet, so there is room for more.
I would like to ask if it's possible to tune those request buffer parameters to allow for faster transfers in LAN environments (larger buffer size for more parallel requests in both directions).