Weird corruption in RTMP served to users

Simplest configuration: its ingesting streams from RTMP (with ingest points so that random people cannot overwrite the streams), and then the same server is used for users to connect to and read RTMP/RTMPT streams. I have also disabled clustering (numInstances 0) because it complicates things and i’m trying to get as basic a config as possible. Now, there’s a strange issue where certain users will report massive video corruption/audio issues, while others will have perfect stream quality. Since RTMP is based on TCP, there shouldn’t be any corruption, if the user’s bw isnt up to snuff (and it was, many times over), it should delay, not corrupt. It’s also not a problem with the stream that’s coming in, as the same stream viewed via HLS or RTSP doesn’t have this issue (the same user could view the same stream via RTSP and it will be perfect, while at the same time they could view it with RTMP and it could be corrupted). It also seems to ‘stick’ based on IP/user agent (the stream name does not matter, it seems), whereas the same user with the same program will either have the corruption or not for some time (they can play the stream in VLC and flash player simultaneously, one of them will be perfect while the other will be corrupted, and they will switch sometimes if you reconnect them). The server definitely has enough bandwidth, it was running the same streams with FMS before we decided to try out evostream. I can also tell it to push the stream (or another evostream server to pull the stream from it) to another server, and then it will be fine when the client connects to that other server. The corruption can also manifest in weird ways, like one time a user always had slowed down audio/skipping audio because in the ‘codec information’ tab the audio bitrate was 44100 (and it would stick to that no matter how many times he reconnected, during some time period), while all the other users reported 48000 as it should be (even the user that had 44100, when he connected with RTMPT to the SAME SERVEr and the SAME STREAM at THE SAME TIME, he would get 48000!). When a user is stuck with this corruption, restarting the server DOES NOT HELP. Lowering the input bitrate also does nothing (it is NOT the user/server running out of bandwidth). It is REALLY dissapointing when the most basic usage of your software (receiving and sending out rtmp/rtmpt streams) is faulty in such a weird and random way.

EvoStream Media Server (www.evostream.com) version 1.6.6 build 3511 - Gladiator - (built for Debian-6.0.5-x86_64 on 2015-01-17T03:29:24.000)

EDIT: also using pushStream to another RTMP server messes up the aspect ratio on 16:9 content (on the target server) for some reason (rtmp->rtmp should be 1:1 bitstream copy so i have no idea how that can happen).