Announcement

Collapse
No announcement yet.

Archived: Feed issues with 19-2

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Guest's Avatar
    Guest replied
    Originally posted by Oblivian View Post
    Khan/Vinnysp et-al

    Seems windows port is broken. From an earlier Rpi code? May be issues changing reading or input TCP modes after auto restart..

    https://forum.flightradar24.com/thre...out-30-Minutes
    Thanks, issue is identified and the fix will be released soon.

    Leave a comment:


  • Oblivian
    replied
    Khan/Vinnysp et-al

    Seems windows port is broken. From an earlier Rpi code? May be issues changing reading or input TCP modes after auto restart..

    https://forum.flightradar24.com/thre...out-30-Minutes

    Leave a comment:


  • abcd567
    replied
    Originally posted by Oblivian View Post
    How's it go, KISS. Keep it stupidly simple.
    1. From fr24feed, first purge/clean ALL components attempting to install and/or configure dump1090, and create a new version of fr24feed: fr24-data-feeder-only, which gets data from decoder either from port 30005 (beast) or port 30002 (raw/avr).

    2. Offer new design PI24 image - Raspbian with integral, but stand-alone apps fr24-data-feeder-only + dump1090-mutability

    3. Offer two bash scripts to user who want to use Raspbian image burned by them.
      • Bash Script 1: installs data-feeder-only software
      • Bash Script 2: (optional, if user does not have another decoder already installed) Installs dump1090-mutability v 1.14

    Leave a comment:


  • Oblivian
    replied
    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 Tapatalk

    Leave a comment:


  • MrMac
    replied
    Originally posted by abcd567 View Post
    SUGGESTION 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"
    Couldn't agree more. The de-facto standard today is for feeders and other clients to look for data at localhost:30005. I never let fr24feed control the decoder, normally avoiding a lot of this mess.

    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!

    /M

    Leave a comment:


  • abcd567
    replied
    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.

    Leave a comment:


  • abcd567
    replied
    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.

    Leave a comment:


  • abcd567
    replied
    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]

    Leave a comment:


  • AndreasWarby
    replied
    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"

    Leave a comment:


  • abcd567
    replied
    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:
    1. Permanently disabled fr24feed from starting/stopping/running dump1090-mutability
      Code:
      sudo rm /usr/lib/fr24/dump1090
    2. 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]"
    3. Rebooted
      Code:
      sudo reboot
    4. 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

    Leave a comment:


  • Oblivian
    replied
    Originally posted by Nigelr View Post
    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
    Depending on confidence to fix if it breaks. Purge it and the config. Apt install only (!not script) and setup manually for avrtcp. But that may be broken going by last tests.

    Sent from my XT1092 using Tapatalk

    Leave a comment:


  • Nigelr
    replied
    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

    Leave a comment:


  • abcd567
    replied
    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".

    Leave a comment:


  • abcd567
    replied
    @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.

    Leave a comment:


  • fr24-pad
    replied
    I agree. I use avr-tcp because I'm using dump1090-mutability 1.15-dev. I think the real problem is that the people building the packages are developers, not sysadmins.

    Leave a comment:

Working...
X