Half an hour ago, installed graphs on freshly written Pi24 image.
Adsbexchange feeder was NOT installed.
pi@raspberrypi:~ $ sudo find / -name adsbexchange
find: ‘/proc/17091’: No such file or directory
pi@raspberrypi:~ $ sudo /usr/share/graphs1090/graphs1090.sh 24h
17574 (process ID) old priority 0, new priority 19
1258x343
1258x343
1258x343
1258x343
1258x359
1258x327
1258x343
1258x343
1258x327
1258x343
1258x343
1258x343
1258x343
1258x343
1258x343
pi@raspberrypi:~ $
Go away with the Pi24 image already 
I don’t care about the facts, it’s still ugly.
True, the Pi24 image is ugly, but still does its job.
Comparing based on GUI, I will rate as follows:
#1 - tar1090
#2 - dump1090-fa
#3 - dump1090-mutability ver1.15/EB_VER (currently used by FR24)
#4 - dump1090 (Malcolm Robb)
Don’t forget about Al’s overlay It’s not tar1090 which is fantastic work, but since we’re now listing…
Sorry that I forgot to include it. I remember it being mentioned in forum posts occasionally, but never used it, so dont know much about it. Where would you place it in my rating list?
I call it a tie with tar1090. Depends how many bells and whistles one wants. No need to apologize to me, I didn’t create it, but I really like it and think he did a great job. Super glad I came across it, so figure it’s worth the publicity as others may enjoy as well.
EDIT/ADD - Reference to a post I made sometime back with some basic instructions for those who may be interested to try without overwriting any existing overlays:
I have a question about the messages/sec charts.
These are shown twice if i am correct. Once in the first chart, then further down in “ADS-B” maxima.
There is a small deviation in the line, the second one looks “flattened” and lower than in the first chart.
The max. message rate at this point in time was 1102
Not a big difference, but noticeable. I would like to understand what makes the difference here.
The screenshots were taken from the 8 hour selection, in the 2 hour selection, both lines are the same.
But also on the 24 hour scaling, the first line looks “smoother”
top graph has this:
Not a big difference, but noticeable. I would like to understand what makes the difference here.
The bottom graph is technically more accurate, as we have a value for every minute, which is best shown with steps instead of drawing lines from point to point (slopes).
Also for longer time scales the maxima graph behaves quite a bit different than the first graph, as transitioning data to one pixel representing longer time spans means you need to either average or maximize / minimize over the represented data points.
Thanks for the explanation. Makes totally sense.
I am dealing with lots of charts in my job and personally like the non-adjusted ones with steps more giving more accuracy and showing the time perspective better
I assume you wanted to add something different, but you quoted my question twice 
--slope
That was it.
It’s the way the graphs were set up initially, so i just left it as they were.
After upgrading to Ubuntu 20, the graphs1090 don’t work anymore.
sudo journalctl --no-pager -u collectd
Aug 16 15:31:53 Ubuntu-Latitude-E6420 collectd[3943427]: ERROR: dlopen("/usr/lib/collectd/python.so") failed: /usr/lib/collectd/python.so: undefined symbol: PyFloat_Type. The most common cause for this problem is missing dependencies. Use ldd(1) to check the dependencies of the plugin / shared object.
Aug 16 15:31:53 Ubuntu-Latitude-E6420 collectd[3943427]: dlopen("/usr/lib/collectd/python.so") failed: /usr/lib/collectd/python.so: undefined symbol: PyFloat_Type. The most common cause for this problem is missing dependencies. Use ldd(1) to check the dependencies of the plugin / shared object.
Aug 16 15:31:53 Ubuntu-Latitude-E6420 collectd[3943427]: plugin_load: Load plugin "python" failed with status 2.
Aug 16 15:31:53 Ubuntu-Latitude-E6420 collectd[3943427]: Found a configuration for the `python' plugin, but the plugin isn't loaded or didn't register a configuration callback.
Aug 16 15:31:53 Ubuntu-Latitude-E6420 collectd[3943427]: Plugin python failed to handle option ModulePath, return code: -1
Aug 16 15:31:53 Ubuntu-Latitude-E6420 collectd[3943427]: Error: Parsing the config file failed!
Aug 16 15:31:53 Ubuntu-Latitude-E6420 systemd[1]: collectd.service: Main process exited, code=exited, status=1/FAILURE
Aug 16 15:31:53 Ubuntu-Latitude-E6420 systemd[1]: collectd.service: Failed with result 'exit-code'.
Aug 16 15:31:53 Ubuntu-Latitude-E6420 systemd[1]: Failed to start Statistics collection and monitoring daemon.
Any suggestions?
Add the following to /etc/default/collectd altering the x86_64 for your architecture.
LD_PRELOAD=/usr/lib/python3.8/config-3.8-x86_64-linux-gnu/libpython3.8.so
I had to do this myself last weekend.
Thanks, that was it!
However, the overall CPU utilization is wrong. The graphs1090 shows 25%, but top command shows 95%.
top shows the percentage of CPU utilization as it relates to 1 core so if you have a 4 core processor and top shows 100% for the process, then that process is actually using 25% of the total cycles available. I believe collectd is reporting the % utilization related to the total cycles available.
What does the top summary line say for %Cpu ...
That’s right, I forgot about that.
@wiedehopf Is there an easy way to get multiple instances running? I’ve got multiple instances of dump1090-fa dump978-fa skyaware978 and tar1090 working well but I can’t figure out how to do it with graphs1090 other than hacking the scripts to add an instance id. So far, that’s not worked out too well.
No, there is not.
No plans to add that either, quite the hassle.
I was actually able to make it work using systemd template unit files and BindPaths/PrivateTmp. I’ll work up a pull request if you’re interested.
I’m not terribly motivated to work on this project anymore because it’s working well
But i’ll sure take a look at your changes.
Is it possible to see what version i’m running, and what the newest is? If so, does an update delete old graphs data?