Just had an email from FR24, asking me to disable MLAT in their config:
" Important information
If you intend to share data to networks alongside Flightradar24, in your Flightradar24 receiver please disable MLAT to the following settings: MLAT=“no”and MLAT-without-gps=“no”. This is to ensure the quality of the data we receive and use and to reduce incompatibility with other services."
I had that and thought it was strange given that other aggregators don’t seem to mind you having MLAT enabled when sharing with others.
Anyway, I’ve disabled it - if that’s what they want that’s what they’ll get.
Me too - I’ll follow suit!
The FR24 forum is meanwhile flooded with view to these two articles:
I see no reason this could not be accomplished in their feed software by automatic detection.
…
And now they’ve followed it up with actual, useful instructions.
I get the impression they don’t know their arse from their elbow. That first email was so unprofessional, coming as it did from “Feeder Team”.
And still they manage to do an incomplete instruction 
If you ask the people to change their ini file or the web UI, they also have to restart the software (webui) not just save it or restart the service (SSH style) in order to activate the new configuration.
SSH style the appropriate command would be “sudo service fr24feed restart” (without the exclamation marks off course).
That would give a complet set of instructions and a correct activation of the new configuration. 
I thought it was just me who got it as I had only just set it up to feed FR24 and assumed I had messed the install up hahaha
I replied to their email saying just that.
I posted it in a number of threads on their forum as well, Like keithma said, it seems they have no clue how to communicate properly with the people they need.
“Don’t bite the hand that feeds you” seems appropriate here 
Does this mean that military aircraft will no longer be displayed on the FR24 map?
That depends on the signal the aircraft are transmitting.
It has been a long time discussion whether the MLAT in coming from home built feeders was used by FR24, it seemed not that way.
So only flightfeeders from FR24 are used for MLAT aggregation in the past and it stays that way.
Well quite, but they’ve always had an odd way of going about things. I think they still use an ancient version of dump1090 which doesn’t recognise the mlat flag as their default decoder, so I suspect that people have installed that to feed other mlat clients which are returning results to dump1090 which duly forwards them on to their upload client.
I get the impression that they don’t update their client very often - they emailed me once to see why I was sending 50,000 or so aircraft a day. I wasn’t, but did have the verbatim flag set in airspy_adsb so that messages with crc errors were being forwarded uncorrected, and their client couldn’t handle it. They were going to look into it and get back to me, but I never heard anything more about it.
Well i don’t think their head knows what their hand is doing …
LOL that’s nothing like what their email message said.
No, it fully recognizes mlat flag. It is built using source code of dump1090-mutability ver1.15~dev which is fully mlat-compatible.
The dump1090 they are using is build by a Debian group using source code of dump1090-mutability ver 1.15~dev, and hosted in Debian repositories, renamed as EB_VERSION (actually DEB_VERSION with D not appearing due to some bug in their code).
Their Pi24 image / fr24feed Bash script sources it from Debian repositories. Anyone can install it by following command:
sudo apt install dump1090-mutability
Well that’s weird then. I don’t know what their problem is, but they seem to have thoroughly confused everyone unnecessarily. They should probably have thought this one through a bit more before emailing everyone multiple times.
Before these latest emails, the FR24 has repeatedly mentioned that MLAT will work only if in fr24feed’s configuration 'receiver=dvbt" is used.
When fr24feed’s setting "receiver=dvbt" is chosen, following happens:
fr24feed’s bash script install_dump1090.sh installs dump1090-mutability from Debian repository
Auto start of dump1090-mutability is set to “NO”. It is started only by a command from fr24feed when it starts.
Output from ports 30005 and 30003 of dump1090-mutability are blocked by default, so it cannot be used to feed other sites unless reconfigured by the user.
pi@raspberrypi:~ $ cat /usr/lib/fr24/install_dump1090.sh
#!/bin/bash
# Stop on first error
set -e
LOGFILE=/var/log/fr24feed_install_dump1090.log
exec > >(tee -a $LOGFILE)
exec 2>&1
if grep -q "^receiver.*dvbt" /etc/fr24feed.ini ; then
if [ ! -e /usr/lib/fr24/dump1090 ] ; then
echo "dump1090 is not found, downloading dump1090-mutability..."
# to skip any questions from APT
export DEBIAN_FRONTEND=noninteractive
echo 'dump1090-mutability dump1090-mutability/auto-start boolean false' | debconf-set-selections -v
apt-get update -y
DUMP1090_IF_PRESENT=`apt-cache search --names-only '^dump1090-mutability.*' | awk '{ print $1 }' | head -n 1`
apt-get -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install librtlsdr0 libusb-1.0-0 dirmngr lighttpd wget $DUMP1090_IF_PRESENT -y
if [ "$DUMP1090_IF_PRESENT" == "" ]; then
# Download and install dump1090-mutability if not present in repository
wget -O /tmp/dump1090-mutability_1.14_armhf.deb https://github.com/mutability/dump1090/releases/download/v1.14/dump1090-mutability_1.14_armhf.deb
dpkg -i /tmp/dump1090-mutability_1.14_armhf.deb
rm -f /tmp/dump1090-mutability_1.14_armhf.deb
fi
ln -s /usr/bin/dump1090-mutability /usr/lib/fr24/dump1090
lighty-enable-mod dump1090 || true
service lighttpd force-reload || true
systemctl enable lighttpd || true
systemctl start lighttpd || true
echo "dump1090-mutability is installed. You can always override it in /etc/fr24feed.ini with any other supported driver."
echo "Web server (aircraft map) at http://YOUR_DEVICE_IP/dump1090 is enabled by default."
elif grep -q 'START_DUMP1090="yes"' /etc/default/dump1090-mutability ; then
sed -i 's/START_DUMP1090="yes"/START_DUMP1090="no"/g' /etc/default/dump1090-mutability
systemctl stop dump1090-mutability || true
fi
fi
That was partly on me. I was filling in the first hole as fast as I could to beat new threads being created and missed it out.
Someone took note of my moan and thankfully followed it up
Made incorrect assumption people would figure out you need to address a restart anyway.
Those in low traffic areas it would likely have done it anyway. System has a 600second restart timeout going by the ‘manual’ and number of times it comes up when people see it in the logs.