Announcement

Collapse
No announcement yet.

FR24 Feeder/Decoder: Version: 1.0.24-2/generic

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • abcd567
    replied
    The initial versions had dump1090 (Malcolm Rob) BINARY installed when fr24feed.deb was installed (/usr/lib/fr24/dump1090). This binary was controlled by fr24feed and did not start at boot. It was started by fr24feed if setting was receiver=dvbt.

    Later the dump1090 (malcolm rob) binary was removed, and an script was included to install dump1090-mutability ver 1.14 using its .deb package available at Github. As the fr24feed binary was hard coded to start the dump1090 binary located in folder /usr/lib/fr24/, the install_dump1090.sh script creates a symlink in this folder to ver 1.14 binary located in folder /usr/bin/dump1090-mutability

    This script acted as follows:

    (1) If setting of fr24feed is receiver=dvbt, thefr24feed at startup looks for binary of dump1090, and if not found, runs the script to install dump1090-mutability v 1.14.

    (2) During installation of dump1090-mutability v 1.14, it changes its init.d file to say NO at startup.

    (3) Creates a symlink to ver 1.14 binary.


    Code:
    pi@raspberrypi:~ $ cat /usr/lib/fr24/install_dump1090.sh

    Code:
    .... .... ....
    .... .... ....
    
    if grep -q "^receiver.*dvbt" /etc/fr24feed.ini && [ ! -e /usr/lib/fr24/dump1090 ] ; then
        echo "dump1090 is not found, downloading dump1090-mutability..."
    
        # to skip any questions from APT
        export DEBIAN_FRONTEND=noninteractive
    
        echo 'dump1090-mutability dump1090-mutability/auto-start boolean false' | debconf-set-selections -v
    
        apt-get update -y
    
        DUMP1090_IF_PRESENT=`apt-cache search --names-only '^dump1090-mutability.*' | awk '{ print $1 }' | head -n 1`
    
        apt-get -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install librtlsdr0 libusb-1.0-0 dirmngr lighttpd wget $DUMP1090_IF_PRESENT -y
    
        if [ "$DUMP1090_IF_PRESENT" == "" ]; then
            # Download and install dump1090-mutability if not present in repository
            wget -O /tmp/dump1090-mutability_1.14_armhf.deb https://github.com/mutability/dump1090/releases/download/v1.14/dump1090-mutability_1.14_armhf.deb
            dpkg -i /tmp/dump1090-mutability_1.14_armhf.deb
            rm -f /tmp/dump1090-mutability_1.14_armhf.deb
        fi
    
        ln -s /usr/bin/dump1090-mutability /usr/lib/fr24/dump1090
    
    .... .... ....
    .... .... ....
    Last edited by abcd567; 2019-10-24, 21:30.

    Leave a comment:


  • fl24
    replied
    Exactly. Whomever has created the service scripts either doesn't understand having a healthy separation between software deployment and system administration, or doesn't care. Having init scripts modify the files and directories of other packages is a really bad idea - ask anyone who has had their fr24 installation broken after performing an update. It has been brought to the attention of the dev team many times so I can only assume that they don't agree or don't care.

    Originally posted by Astralix View Post
    I don't understand some lines in the service script. Ok, I do understand what they do, but I don't get why they are there. The original script tries to install dump1090-mutability. But that shouldn't be part of the init-script. Especially as there are multiple flavors of dump1090 out there, it either looks like fr24 tries to overrule them, or they want to keep the need for compatibility checks low.
    But on my system I found that installation line to be missing so it might be, that the installer.sh found my already installed piaware background and skips this rule.
    If it is the support thing, I wonder why all services work fine on dump1090-fa but fr24 is pushing on dump1090-mutability?

    This all tastes a bit bitter... Like fr24 wants to gain control over the feeder exclusively. I simply don't understand why they not simply create some installer packages (.deb or so) that have some dependencies declared and concentrate on fr24 feeding but accept any dump1090-* as a source?

    Leave a comment:


  • Astralix
    replied
    I don't understand some lines in the service script. Ok, I do understand what they do, but I don't get why they are there. The original script tries to install dump1090-mutability. But that shouldn't be part of the init-script. Especially as there are multiple flavors of dump1090 out there, it either looks like fr24 tries to overrule them, or they want to keep the need for compatibility checks low.
    But on my system I found that installation line to be missing so it might be, that the installer.sh found my already installed piaware background and skips this rule.
    If it is the support thing, I wonder why all services work fine on dump1090-fa but fr24 is pushing on dump1090-mutability?

    This all tastes a bit bitter... Like fr24 wants to gain control over the feeder exclusively. I simply don't understand why they not simply create some installer packages (.deb or so) that have some dependencies declared and concentrate on fr24 feeding but accept any dump1090-* as a source?

    Leave a comment:


  • fl24
    replied
    Good call. I had to change that when the previous update broke abt-tcp mode so I’ll change my “good” file.

    Originally posted by abcd567 View Post
    fl24:

    The setting receiver="avr-tcp" often gives problems in connecting to fr24 server.
    Better change it to beast-tcp in your good file:

    % cat fr24feed.ini-good
    receiver="beast-tcp"
    fr24key="your key here"
    host="127.0.0.1:30005"

    Leave a comment:


  • abcd567
    replied
    fl24:

    The setting receiver="avr-tcp" often gives problems in connecting to fr24 server.
    Better change it to beast-tcp in your good file:

    % cat fr24feed.ini-good
    receiver="beast-tcp"
    fr24key="your key here"
    host="127.0.0.1:30005"

    Leave a comment:


  • fl24
    replied
    I see the fr24 dev team are still including system administration functions (scripted package updates) instead of doing things correctly. If you want auto-updates, use the standard debian package for that: unattended-upgrades. Anyone who is tired of fr24's poor behaviour might be interested in running a separate dump1090 and using something similar to my safe-upgrade script:


    #!/bin/bash

    BASE="$HOME/fr24-fix"
    DATE=`date +%Y%m%d`

    sudo apt-get install fr24feed
    sudo service fr24feed stop

    sudo cp /etc/systemd/system/fr24feed.service $BASE/fr24feed.service-dist-$DATE
    sudo cp $BASE/fr24feed.service-good /etc/systemd/system/fr24feed.service
    sudo systemctl daemon-reload

    sudo cp /etc/fr24feed.ini $BASE/fr24feed.ini-dist-$DATE
    sudo cp $BASE/fr24feed.ini-good /etc/fr24feed.ini

    sudo rm /etc/cron.d/fr24feed_updater
    sudo chmod 0 /usr/lib/fr24/fr24feed_updater.sh
    sudo chmod 0 /usr/lib/fr24/install_dump1090.sh
    sudo chmod 0 /usr/lib/fr24/unregister_kernel_modules.sh
    sudo chmod 0 /usr/lib/fr24/create_missing_directories.sh
    sudo chmod 0 /usr/lib/fr24/dump_diagnostics.sh

    sudo rm -fr /run/dump1090-mutability
    sudo service fr24feed start

    my "good" files are as follows:

    % cat fr24feed.ini-good
    receiver="avr-tcp"
    fr24key="your key here"
    host="127.0.0.1:30002"
    stats="yes"
    bs="no"
    raw="no"
    logmode="1"
    logpath="/var/log/fr24feed"
    mlat="yes"
    mlat-without-gps="yes"


    % cat fr24feed.service-good
    [Unit]
    Description=Flightradar24 Decoder & Feeder
    After=network-online.target

    [Service]
    Type=simple
    Restart=always
    LimitCORE=infinity
    #ExecStartPre=-/usr/lib/fr24/install_dump1090.sh
    #ExecStartPre=-/bin/mkdir -p /run/dump1090-mutability /var/log/fr24feed /run/fr24feed /var/log/lighttpd
    #ExecStartPre=-/bin/touch /dev/shm/decoder.txt
    #ExecStartPre=-/bin/chown -R fr24:fr24 /var/log/fr24feed /run/fr24feed /dev/shm/decoder.txt
    #ExecStartPre=-/bin/chmod a+rwx /run/dump1090-mutability
    ExecStart=/usr/bin/fr24feed
    User=fr24
    Group=fr24
    PermissionsStartOnly=true
    StandardOutput=null

    [Install]
    WantedBy=multi-user.target

    Leave a comment:


  • Astralix
    replied
    May be things change as Raspberry Pi 4 is also a 64 bit machine. However, I try my very best to get some details. I'll report here if I have results.

    Leave a comment:


  • abcd567
    replied
    Ok, I will write my own "neo-fr24feed", and post its source code on Github.

    Leave a comment:


  • wiedehopf
    replied
    Originally posted by Astralix View Post
    But as you title the rf24 team as 'they' it sounds like a closed group of developers? I need to check if there is a way to pull the code and fix it and send in a merge-request. Piaware wasn't in any way stable on Allwinner 64 bit boards, but you just download and build it yourself and for me it now works perfectly stable for month.
    Good joke

    The source for the software is not available.
    For over a year people have been asking for binaries of the current version for amd64 or i386, no answer.

    If they would even compile for armhf, it might be less of a problem:
    Code:
    2019-10-23 09:40:24 | [main][i]FR24 Feeder/Decoder
    2019-10-23 09:40:24 | [main][i]Version: 1.0.24-2/generic
    2019-10-23 09:40:24 | [main][i]Built on Oct  8 2019 05:28:05 (HEAD-bb2208f.git/Linux/static_armel)
    It wouldn't be hard for them to just compile it on a few different platforms, but i suppose they would want to testing which they don't want to allocate resources for.
    But at this point, a non-tested new compile would probably be the better option as the non-RPi binaries are that ancient.

    Anyway from all this you probably get an idea of how likely it is for you got the source code.
    Good luck anyway.

    Leave a comment:


  • Astralix
    replied
    I would like to help to find a solution for this bug, regardless of the platform. I would also appreciate to convert this package to arm64 and I will test this software iMX too, as I do not trust these RasPi and OrangePi boards enough to mount them in a place which is hard to get to. However, that is an iMX6 which is armhf.
    But as you title the rf24 team as 'they' it sounds like a closed group of developers? I need to check if there is a way to pull the code and fix it and send in a merge-request. Piaware wasn't in any way stable on Allwinner 64 bit boards, but you just download and build it yourself and for me it now works perfectly stable for month.

    Leave a comment:


  • wiedehopf
    replied
    dump1090 flavor has nothing to do with the bus error.

    It just doesn't work if you're not on armhf or maybe even just not on a Raspberry Pi.

    Anyway i get the impression they will not test for anything but the RPi, so this error might be here to stay, which is unfortunate.

    Leave a comment:


  • Astralix
    replied
    I can confirm that the "Bus Error" bug, that prevents rf24feed to start, is still active in version 1.0.24-4. I was checking my system and found that everything works fine, besides that fr24feed was not running anymore. Manually installing 1.0.23-8 solved the problem for now.

    That some people report that 1.0.24-4 has fixed that issue, might be cause they use dum1090-mutability. But I have dump1090-fa installed, not dump1090-mutability!

    Background is, that I was simply unsure which of the multiple incarnations of dump1090 I should install. But while testing multiple platforms from Raspberry zero, 3, 3+, OrangePi Zero, OrangePi PC2 and NanoPC-T4, it always worked fine to first compile dump1090-fa and fa from source and install ist, then install fr14 on top. So I did not investigate further which dump1090 flavor to use.

    Leave a comment:


  • Winap
    replied
    Hello, I have a problem with manual gain receiver..In old version was all ok, but after update I can't configure it. It still the same setup, wihout manual setup on port
    80 throw Mozilla . Any Idea please?

    Leave a comment:


  • HAm
    replied
    Originally posted by abcd567 View Post
    You are using commands copied outside a code tag. The URLs in these commands are shortened, and fail as Linux command. They work OK in a browser, hence you could download in Windows.

    Copy-paste commands below. These are within code tag, and are not shortened
    Code:
    ## First get rid of already installed new version
    sudo dpkg --purge fr24feed
    
    ## Now install old version
    wget https://repo-feed.flightradar24.com/rpi_binaries/fr24feed_1.0.23-8_armhf.deb
    sudo dpkg -i fr24feed_1.0.23-8_armhf.deb
    
    ## Get rid of the updator
    sudo rm /etc/cron.d/fr24feed_updater
    
    ## Checks
    apt-cache policy fr24feed                                                    
    
    ## Check receiver is NOT dvbt. It should be beast-tcp
    sudo nano /etc/fr24feed.ini
    
    ## Save file (Ctrl+o) and close (Ctrl+x)
    ## Restart fr24feed
    sudo systemctl restart fr24feed
    
    fr24feed-status
    Took me ten minutes and now I'm up and running!
    Thank you all!

    oh6my@adsb-rx:~$ fr24feed-status
    * FR24 Feeder/Decoder Process: running
    * FR24 Stats Timestamp: 2019-10-10 17:23:40
    * FR24 Link: connected [UDP]
    * FR24 Radar: T-EFVA13
    * FR24 Tracked AC: 9
    * Receiver: connected (4969 MSGS/0 SYNC)
    * FR24 MLAT: ok [UDP]
    * FR24 MLAT AC seen: 9

    Hans

    Leave a comment:


  • abcd567
    replied
    Originally posted by wiedehopf View Post
    @abcd, i'm not sure why you would purge the old installation, that will lead to the update cron file to be written again.
    Purging is only required in some cases.
    You are right. I forgot about updater. Now I have added following command after installation command:

    sudo rm /etc/cron.d/fr24feed_updater

    I prefer purge over remove to get a better clean up.

    Leave a comment:

Working...
X