You are the first person I’ve found on mikrotik fiddling with their fq_codel implementation. (I’m one of the authors of fq_codel, cake, etc)
And you are tackling the worst problem “out there” for bufferbloat - inbound shaping a low rate lte connection. These sorts of connections are not only low rate,
but wildly variable in their ability to deliver packets at any given instant in time.
And you are only 7 days into it, and doing pretty well. 
My zeroth suggestion is to try it at 5Mbits, not 20Mbits. You want it to be closer to the minimum you experience, not the max. Period. You need to retain control of the
queue.
My first suggestion is to switch to cake, and kill all the rules you have there. I’ve been trying to find out if mikrotik supports nat for cake or not, but if you are natting on the router, applying the nat option to cake will give per host/per flow flow queuing, meaning that your low rate gaming traffic will win more often than netflix. In general, however, this is not hugely required.
One feature of cake, probably not exposed by mikrotik, is that it’s possible to dynamically change the shaping rate based on some other set of supplied statistics.
If you are going to stick with fq_codel, use a quantum of 300.