Hi I have an SD-card install of the latest PiAware 3.5 (upgraded to 3.5.1 with apt-get etc. etc.) which is based on old Debian Jessie. I tried to upgrade to Raspbian Stretch on the system but now it doesn’t boot… so don’t try this at home kids I suspect the kernel upgrade didn’t go well given PiAware seems to have a custom setup for this.
Is there an ETA for a STRETCH-based PiAware SD card image?
Otherwise has anyone successfully upgraded their PiAware to stretch and has instructions?
Otherwise I will do a new Raspian Stretch Lite image and install Piaware over the top … however I like the custom things PiAware image install has like the config TXT file on the /boot drive for setting the gain easily etc.
I upgraded from Raspbian Jessie to Raspbian Stretch and there were no problems during installation or during normal operation.
However I did not upgrade by upgrade command from my stats page, or by “sudo apt-get dist-upgrade” or by “sudo apt-get upgrade”. Instead, I formatted microSD card and wrote Raspian Stretch Lite image. After booting, I installed Piaware 3.5.1 and dump1090-fa by package install.
Note:
While the microSD card was still in the card reader and plugged into Desktop, I very easily enabled SSH and configured WiFi as per instructions here: Bake a Pi - Option-2, item 5(a) and (b)
Yes, but trying to install following leads to problem.:
dump1090-mutability v1.15~dev.
Flightradar24 feeder by bash script or JProchazka’s scripts.
Radarbox24 feeder by bash script.
I tried these on another microSD card after formatting & writing Raspbian Stretch image, and could succeed only after carrying out separate workarounds for each of these.
(3) RadarBox24’s rbfeeder fails to install by bash script
sudo bash -c "$(wget -O - http://apt.rb24.com/inst_rbfeeder.sh)"
.........
W: GPG error: [url]http://apt.rb24.com[/url] jessie Release: The following signatures were invalid: A7E7D5E3786CA2212A3A5F4769D62C99357DF51A
W: The repository 'http://apt.rb24.com jessie Release' is not signed.
.........
WARNING: The following packages cannot be authenticated!
rbfeeder
.....
Failed to start rbfeeder.service: Unit rbfeeder.service not found.
Workaround:
sudo apt-get update
sudo apt-get install rbfeeder
Ignore following warning during install and say y
WARNING: The following packages cannot be authenticated!
rbfeeder
Install these packages without verification? [y/N]
This seems to be the most appropriate thread for me to ask about my problems getting FlightReader24 to use my PiAware system.
When I upgraded my Raspbian ‘wheezy’ system (apt-get dist-upgrade), my system would no longer boot (!). So I opted to start over again with Debian ‘stretch’. My PiAware configuration seems to be working OK, but not my FlightReader24 addon. The log keeps repeating errors with port 30005:
...
2017-10-25 12:53:29 | [feed][n]ping 1047
2017-10-25 12:53:29 | [reader][i]Connecting to DVBT-TCP-BEAST-RAW receiver via (tcp://localhost:30005)
2017-10-25 12:53:29 | [reader][e]Could not connect to tcp://localhost:30005
2017-10-25 12:53:30 | [feed][n]syncing stream result: 1
2017-10-25 12:53:34 | [reader][i]Connecting to DVBT-TCP-BEAST-RAW receiver via (tcp://localhost:30005)
2017-10-25 12:53:34 | [reader][e]Could not connect to tcp://localhost:30005
2017-10-25 12:53:39 | [reader][i]Connecting to DVBT-TCP-BEAST-RAW receiver via (tcp://localhost:30005)
2017-10-25 12:53:39 | [reader][e]Could not connect to tcp://localhost:30005
...
Delete following entry from your file /etc/fr24feed.ini
path="/usr/bin/dump1090-fa"
Save the file /etc/fr24feed.ini, and then reboot sudo reboot,
Few minutes After reboot, check log file cat /var/log/fr24feed.log
.
DETAILED DISCUSSION
You have set /etc/fr24feed.ini file to receiver="avr-tcp" and host="127.0.0.1:30002". Then why it tries to connect to DVBT-TCP-BEAST-RAW receiver via (tcp://localhost:30005)?
When I compare my and your files /etc/fr24feed.ini, I found in your file thereis an extra entry, which I have made bold above.
To simulate your situation, I added entry path="/usr/bin/dump1090-fa" in my file /etc/fr24feed.ini
and then rebooted sudo reboot
After reboot, checked file /var/log/fr24feed.log, and got exactly your problem:
I then deleted the entry path="/usr/bin/dump1090-fa", saved fr24feed.ini file and then rebooted sudo reboot. After reboot, checked /var/log/fr24feed.log. The problem is gone, and output became normal as shown below:
Further investigation after my last post. I found the bug (I think so).
This problem occurs when the fr24feed is restarted by commands like sudo service fr24feed restart or sudo systemctl restart fr24feed,
This problem goes away when Pi is rebooted,
fr24feed is stopped by some internal process due to very low traffic during night, then restarted when traffic picks up. Because of this, the problem appears again. It goes away if Pi is rebooted, to appear again when system again restarts it in next24 hours.
I have further found that this bug is related only to following setting
receiver="avr-tcp"
host="127.0.0.1:30002"
When I changed the settings to following, then restarting manually by sudo systemctl restart fr24feed worked well and fr24feed worked ok. However I have still to observe over few days to see what happens when the system shuts down the fr24feed due to very low traffic in night and then restarts when traffic picks up,
abcd567: Thanks for your careful investigation of this problem! Your first response made sense, but strangely I found my server was already running fine with the most recent changes to ‘/etc/fr24feed.ini’ (similar to what you had mentioned). I was happy – but puzzled. I then made a small change and restarted ‘fr24feed’ – only to find that it was broken again!
I then took more careful note of your suggestion to ‘reboot’ (rather than restart the daemons as I had been doing), and it worked fine again. I came back here to mention this to you, but noticed your 2nd response confirming the same thing
Yes, I agree with you that some sort of bug is present! Are we the first ones to discover this? Did this not occur in Debian Wheezy or Jessie? If it did, I cannot imagine that no one noticed it before. Hmmm…
It occurs only in Stretch, which is proving itself a pain in meck with so many feeder decoder software.
Yes, it has been reported recently at least by one more user. Immediately after posting here, I have posted contents of my last post there also (about an hour ago).
What is (perhaps) odd is that the stats page for my FlightRadar24 page is not (yet) showing any change in ‘Aircraft Seen/Positions Reported’. I did not take notice before I made this change, but I would have expected these numbers to change every time I refresh the page (?). EDIT: The numbers finally increased – I guess they are not ‘real time’ stats.
P.S. I guess we don’t need to specify ‘raw’ somewhere for the port 30005 stream?
Since you have now tested that with setting beast-tcp, 30005, restarting fr24feed does not create problem, you can again modify fr24feed.ini to avr-tcp, 30002 and watch overnight for few days.
.
The updating of data on feeder stats page is NOT instantaneous. Sometimes it lags by hours.
.
I think the software understands that beast is same as raw. It is not necessary to specify raw once beast is specified. Also in FR24 config page, setting ModeS Beast (TCP) and beast-tcp are mentioed for receiver. However for output data, they have mentioned Raw data 30002/30334
A better method is to see the status locally on your desktop/laptop/phone’s browser by typing the sddress ip-of-pi:8754 which gives instantenoous status, and automatically updated every few minutes, or by refreshing the browser.
Note: After restart of fr24feed, it takes few minutes to update this page. During this period it will show Not configured, go to settings, not connected, and N/A for most items.
I suspect the kernel upgrade didn’t go well given PiAware seems to have a custom setup for this.
