Originally posted by fr24-pad
View Post
Announcement
Collapse
No announcement yet.
Archived: Feed issues with 19-2
Collapse
This topic is closed.
X
X
-
Originally posted by abcd567 View PostActually all this interference by fr24feed to dump1090 is needed because of the setting "receiver=dvbt". If this setting is not there, most of the ownership and permissions isuues, and crisis caused by them will disappear.
Comment
-
@fr24-pad
I have Pi24 image, and after auto-upgrade, it has dump1090-mutabilty ver 1.14. It works fine at "receiver=dvbt". Flightaware and Planefinder feeders also work fine in their default network mode.
When I change setting of fr24feed to "avr-tcp, 127.0.0.1:30002" or "beast-tcp, 127.0.0.1:30005", everything fails. The dump1090-mutability status shows running, but all feeders complaint of "no program available to listen at port 30005".
I edited file /etc/default/dump1090-mutability, and changed setting START_DUMP1090="no" to START_DUMP1090="yes".
This enabled start of dump1090-mutability at boot.
Rebooted.
Still same situation.
Comment
-
This weekend, I will try a cleanup: remove all pieces of codes in various files through which fr24feed controls dump1090-mutability.
The first thing I will do is
sudo rm -rf /usr/lib/fr24/dump1090
Another thing is to edit file fr24feed.service and remove commands giving permissions/ownership of dump1090 to user fr24.
set dump1090-mutability to automatically start at boot
I expect this will result in failure of fr24feed on setting receiver=dvbt, but will work ok in network modes "avr-tcp, 127.0.0.1:30002", or "beast-tcp 127.0.0.1:30005".
Comment
-
I've read about the problems with dump1090 mutability but ca. 3 weeks ago my feed to FR24 using dump1090-fa stopped on one of my Pis and i've tried various things, without success, to get it feeding again. Dump1090-fa and the feed to fa and RB24 are working fine. All the feed to FR24 from my other Pi is fine and still working.
Any suggestions and advice would be gratefully received.
Thanks
Comment
-
Originally posted by Nigelr View PostI've read about the problems with dump1090 mutability but ca. 3 weeks ago my feed to FR24 using dump1090-fa stopped on one of my Pis and i've tried various things, without success, to get it feeding again. Dump1090-fa and the feed to fa and RB24 are working fine. All the feed to FR24 from my other Pi is fine and still working.
Any suggestions and advice would be gratefully received.
Thanks
Sent from my XT1092 using TapatalkPosts not to be taken as official support representation - Just a helpful uploader who tinkers
Comment
-
NEW EXPERIMENT ON PI24 upgraded to v 1.0.19-13
Setting avr-tcp and beast-tcp were not working. Only dvbt was working.
Fixed by following method:
- Permanently disabled fr24feed from starting/stopping/running dump1090-mutability
Code:sudo rm /usr/lib/fr24/dump1090
- Permanently enabled automatic start of dump1090-mutability at boot
Code:sudo nano /etc/default/dump1090-mutability #changed "no" to "yes" START_DUMP1090="[COLOR="#FF0000"][B]yes[/B][/COLOR]"
- Rebooted
Code:sudo reboot
- Map at ip-0f-pi/dump1090/ is ok
The FR24 status shows that at setting DVBT, it has failed.
Changed setting to AVR(TCP), 127.0.0.1:30002.
Now shows OK
Code:pi@raspberrypi:~ $ fr24feed-status [ ok ] FR24 Feeder/Decoder Process: running. [ ok ] FR24 Stats Timestamp: 2018-02-03 07:28:56. [ ok ] FR24 Link: connected [UDP]. [ ok ] FR24 Radar: T-CYYZ9. [ ok ] FR24 Tracked AC: 4. [ ok ] Receiver: connected (2627 MSGS/0 SYNC). [ ok ] FR24 MLAT: ok [UDP]. [ ok ] FR24 MLAT AC seen: 4.
Code:pi@raspberrypi:~ $ sudo systemctl status piaware -l ● piaware.service - FlightAware ADS-B uploader Loaded: loaded (/lib/systemd/system/piaware.service; enabled) Active: active (running) since Sat 2018-02-03 02:26:16 EST; 3min 45s ago .......................... .......................... Feb 03 02:26:53 raspberrypi piaware[531]: 20 msgs recv'd from dump1090-mutabi; 20 msgs sent to FlightAware
FR24 dump1090 deleted - dvbt failed.png FR24 dump1090 deleted - avr-tcp ok.png FR24 dump1090 deleted - Map ok.png
Comment
- Permanently disabled fr24feed from starting/stopping/running dump1090-mutability
-
I had been using avr-tcp / 127.0.0.1:30002 for years and, in my case, the auto-update from 1.0.19-11 to 1.0.19-12 gave me this problem:
pi@piaware:~ $ /usr/bin/fr24feed-status
[ ok ] FR24 Feeder/Decoder Process: running.
[ ok ] FR24 Stats Timestamp: 2018-01-30 11:06:37.
[ ok ] FR24 Link: connected [UDP].
[ ok ] FR24 Radar: T-CYCV22.
[ ok ] FR24 Tracked AC:.
[FAIL] Receiver: down ... failed!
[FAIL] FR24 MLAT: not running ... failed!
I "fixed" this problem under 1.0.19-12 by instead configuring the receiver / host to
beast-tcp / 127.0.0.1:30005
With beast-tcp / 127.0.0.1:30005 in place, the auto-update from 1.0.19-12 to 1.0.12-13
went smoothly, with everything apparently working now and no interventions needed.
For reference here are the contents of my setup params:
pi@piaware:~ $ cat /etc/fr24feed.ini
receiver="beast-tcp"
fr24key="xxx"
host="127.0.0.1:30005"
bs="no"
raw="no"
logmode="2"
windowmode="0"
mpx="no"
mlat="yes"
mlat-without-gps="yes"
Comment
-
Trying to install fr24feed on STRETCH, gpg key server failure
Code:pi@raspberrypi:~ $ sudo -i root@raspberrypi:~# gpg --keyserver eu.pool.sks-keyservers.net --recv-keys 40C430F5 gpg: keyserver receive failed: [COLOR="#FF0000"]No keyserver available[/COLOR]
Comment
-
I now discovered that if eu. is removed from eu.pool.sks-keyservers.net in above post, the gpg key gets installed
Code:pi@raspberrypi:~ $ sudo -i root@raspberrypi:~# gpg --keyserver pool.sks-keyservers.net --recv-keys 40C430F5 gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key C969F07840C430F5: public key "Flightradar24 <support@fr24.com>" imported gpg: Total number processed: 1 gpg: imported: 1 root@raspberrypi:~# gpg --armor --export 40C430F5 | apt-key add - OK root@raspberrypi:~# mv /etc/apt/sources.list /etc/apt/sources.list.bak root@raspberrypi:~# grep -v flightradar24 /etc/apt/sources.list.bak > /etc/apt/sources.list || echo OK root@raspberrypi:~# echo 'deb http://repo.feed.flightradar24.com flightradar24 raspberrypi-stable' >> /etc/apt/sources.list root@raspberrypi:~# apt-get update
Last edited by abcd567; 2018-02-03, 21:35.
Comment
-
Raspbian STRETCH + dump1090-fa OR dump1090-mutability v1.15~dev + fr24feed ver 1.0.19-13
- Setting-1: OK
receiver="beast-tcp"
host="127.0.0.1:30005"
- Setting-2: FAILS
receiver="avr-tcp"
host="127.0.0.1:30002"
- Setting-3: FAILS
receiver="beast-tcp"
host="localhost:30005"
- Setting-4: Creates a mess.
If by mistake setting is changed to receiver="dvbt", and fr24feed restarted or Pi rebooted, it creates a mess.
- If you have dump1090-mutability v 1.15~dev, it gets replaced by ver 1.14
- If you have dump1090-fa, it stays, but dump1090-mutability ver 1.14 also gets installed.
After cleaning this mess, I safeguarded against future disasters by re-naming following 2 files:
Code:cd /usr/lib/fr24/ sudo mv install_dump1090.sh install_dump1090.sh.getlost sudo mv dump1090 dump1090.getlost
Last edited by abcd567; 2018-02-04, 09:56.
Comment
- Setting-1: OK
-
Originally posted by abcd567 View PostSUGGESTION TO DEVELOPMENT TEAM
I feel it will simplify things if fr24feed:- Does NOT install dump1090
- Does NOT control or take ownership of dump1090
- Does NOT control and change settings of dump1090
- Does NOT have option "DVBT"
Another problem is that when fr24feed controls the execution of dump1090, the settings in /etc/default/dump1090-mutability are not used, causing a lot of ambiguity.
I also run all our Rpis in write-protected mode, preventing fr24feed from auto-updating. This saved more than 20 installations from being f***ed up by the latest buggy versions, so I can just wait for something that looks like a stable release.
Remove the "dvbt" option!
/MF-ESDF1, F-ESGG1, F-ESGP1, F-ESNK1, F-ESNV2, F-ESNV3 F-ESSL4, F-ESNZ7, F-LFMN3
T-ESNL1, T-ESNL2, T-ESGR15
P-ESIA, P-ESIB, P-ESGF, P-ESSN, P-EFMA
mrmac (a) fastest.cc
Comment
-
Yeap. Still comes back to the original dilemma I suspected. Awful hard to keep dump1090 direct USB configs going when asked to completely pull/replace its existence when other stuff not using it in direct mode may rely on dropped files too from under our noses without manual intervention (hindsight would have been a lot easier to force it dead and give users a single working instruction or self install option to get going again..)
Certainly a case of too much automation with disregard :/
How's it go, KISS. Keep it stupidly simple.
Sent from my XT1092 using TapatalkPosts not to be taken as official support representation - Just a helpful uploader who tinkers
Comment
Comment