What could go wrong in PiAware 3.8.0 such that, following a reboot, aircraft type are mostly of type “Unknown”? It’s using the OL3 interface but that’s just a wrapper around the data, and it seems the data itself is not being ‘resolved’ any more. It was working fine until this reboot. Another reboot hasn’t fixed it.
This is the Pi that’s had all the dhcpcd prodding and poking in the other thread. Is there a log entry I can check to see if something that should be loaded/running is indeed loaded/running? Or a flightaware address or IP I can prod to see if I should be able to reach it but can’t?
EDIT: I don’t know if these errors are related to Graphs1090, OL3 or PiAware 3.8.0 (I think Graphs1090)? May or may not be related to the above. Quite a few of these in syslog after the reboot:
Feb 7 07:07:17 piaware collectd[773]: rrdtool plugin: rrd_update_r (/var/lib/collectd/rrd/localhost/df-root/df_complex-free.rrd) failed: /var/lib/collectd/rrd/localhost/df-root/df_complex-free.rrd: illegal attempt to update using time 1581059238 when last update time is 1581059238 (minimum one second step)
Skyaware does not have aircraft type information in this format, it provides ICAO designators only, so your changes are doing more than just wrapping the data.
Please don’t call it OL3 interface, OpenLayers3 is just the map API used.
If i’m not mistaken it’s the alkissack interface which brings its own database.
Clearing the cache never hurts with such issues.
There is a loading bug in the dbloader in the dump1090-fa and probably the alkissack interface as well as it’s based on that.
I’ve fixed it in tar1090 but haven’t gotten around to doing a PR for dump1090-fa.
Don’t even remember what the bug was at the moment.
Anyhow might not be the bug.
If clearing the cache doesn’t help, you can try removing the db folder and replacing it with a fresh copy from the alkissack github.
Thanks, and to @obj, I didn’t know that, I thought the decoding of the ICAOs and craft info and all that took place outside of the html and the html was just the ultimate web wrapper to present it. Are you talking about a cache as part of OL3, the browser cache (already cleared that, no change) or another cache in PiAware?
@foxhunter it’s the PiAware image with /usr/share/dump1090-fa/html replaced with the OL3 html. It’s been working fine for me for months and for my mate since he went live, but today after a reboot he’s mostly all type Unknown.
No it won’t be that given the above.
Given the stick this build has had (it’s mate’s that’s had the patches applied) I think we might rebuild over the weekend anyway.
Might be that the sd-card is corrupted.
You can open the page in your browser, press F12 and check the network tab.
Filter by json or db and reload the page.
If some files can’t be loaded, that would be the issue of the database not being able to be loaded from the server (via http).
It’s always possible, reimaging and re-doing settings is a last resort, only about 20 mins work though. Certainly all the /usr/share/dump1090/html and below files are all unchanged since they were configured.
Everything loads fine. The only error in Chromium’s dev tools is a file http://192.168.1.4/dump1090-fa/sql/sql-best-ranges.php is 403 and that’s the same when I view mine in Safari inspector. But now the Unknown types vary from staying as Unknown with just a handful updating, to all updating. On mine they all update instantly. In this case that 20 mins work is looking nice.
That’s graphs1090, but it’s not any error that’s really relevant.
It just says it can’t update the data.
That sounds like the database loading error i encountered.
I can’t remember what the issue was tough.
Think it depends on connection speed and which aircraft are loaded when.
Normally after doing a reload all the database should be cached and it shouldn’t be an issue.
Was the problem over a slow connection?
Could well be that the only difference isn’t the data or the server, but the connection speed.
No problem, thanks, I just wanted to be sure if it was graphs1090 related or something systemic perhaps more serious.
Not a slow connection but one that might be pushing the limits of the wifi range. Perhaps the Pi is sometimes losing the connection and this is manifesting as errors in various components due to loss of network. Perhaps an external wifi antenna can improve matters, and I think PiAware has the bluetooth component enabled, might as well disable that since it’s not used.
The real fix would be fixing the javascript loading the database (dbloader.js).
But i’m not real keen on checking/remembering what the issue is and fixing that.
Given that that is even the error you are seeing, but it sure sounds like what i remember.
