No announcement yet.

Archived: Feed issues with 19-2

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

  • #16
    Originally posted by m33as View Post
    Oblivian - thank you. The bit-by-bit post was what I needed, I honestly wasn't aware of it (I apologise). But, it clarified a lot for me, and helped go through the steps to make A working before trying B, getting B working, etc... Thank you a lot. It's running fine now.

    Good to hear. See my perceived attitude isnt always in vein

    Out of curiosity what was the cause/fix? Installed but not started or started but conflict

    Sent from my XT1092 using Tapatalk
    Posts not to be taken as official support representation - Just a helpful uploader who tinkers


    • #17
      Your help was genuinely appreciated! It turned out dump1090-mutability was already, independently running, prohibiting fr24feed to connect to the SDR properly. As mention in the bit-by-bit post! So stopping it, and letting fr24feed load it, did the trick!


      • #18
        I assume that when you refer to updating to 19-5 you are actually saying to use the link provided by Khan earler today.

        I run this and get an error almost immediately saying "line 8: /dev/mmcblk0p7: Permission denied

        Is this my problem


        • #19
          /var/run data "missing" after fr24feed 1.0.19-5 update

          After the recent issues with fr24feed updates (missing dump1090) I moved to a stand-alone version of dump1090-mutability and configured fr24feed to use it via the "avr-tcp" mechanism. The most recent update of fr24feed is now interfering with dump1090-mutability's data files in /run/dump1090-mutability. The behaviour can be reproduced as follows:

          1. stop both daemons (sudo service fr24feed stop; sudo service dump1090-mutability stop)
          2. remove /run data files (sudo rm -fr /run/fr24feed /run/dump1090-mutability)
          3. start dump1090-mutability (sudo service dump1090-mutability start)
          4. ls -lar /run/dump1090-mutability
          This indicates that the files belong to the dump1090 user
          5. start fr24feed (sudo service fr24feed start)
          4. ls -lar /run/dump1090-mutability
          This indicates that the files' permissions have been changed (to the nobody user, the one that runs fr24feed). After this the dump1090 process can no longer write to the /run/dump1090 directory and this breaks the web interface and anything that might be using those files.

          A quick work-around is to change the dump1090-mutability data file location in /etc/default/dump1090-mutability. If you are using lighttpd to serve dump1090-mutability's web interface you will also need to change the data dile location in /etc/lighttpd/conf-available/89-dump1090.conf.

          Clearly, some more rigorous unit and regression testing needs to be used by whomever is creating the fr24feed releases. Using an upgrade script outside of Debian's package management system does not seem to be helping matters either.
          Last edited by fr24-pad; 2018-01-20, 08:05.


          • #20
            "if grep -q dvbt /etc/fr24feed.ini && [ ! -e /usr/lib/fr24/dump1090 ] ; then"

            What if "dvbt" is present in the fr24feed.ini file but it is commented out? A better solution might be to evaluate the file and check the value of $receiver.


            • #21
              Originally posted by Oblivian
              Cant be sure but I have a feeling the fr24feed.ini has not only had permissions changed but possibly changed location in an attempt to force a fresh reconfigure. Which seems to break pre-existing settings...
              No, the permissions and location of fr24feed.ini are retained. After upgrade, I could edit config from Web Browser, as well as directly in by sudo nano /etc/fr24feed.ini through SSH console.
              NOTE: Should use sudo when running scripts for "auto-upgrade", else will get permission denied on some of the steps during execution of script.

              Pi24 Upgrade ver 1.0.18-9 >> ver 1.0.19-5

              [color=#00AA00]cd /usr/lib/fr24[/color]
              [color=#00AA00][B]sudo[/B] ./[/color]
              Installed version: 1.0.18-9
              Latest available: 1.0.19-5
              Upgrading fr24feed...
              Waiting for fr24feed to stop completely...
              [COLOR="#FF0000"]Configuration file '/etc/fr24feed.ini'[/COLOR]
               ==> Modified (by you or by a script) since installation.
               ==> Package distributor has shipped an updated version.
                 What would you like to do about it ?  Your options are:
                  Y or I  : install the package maintainer's version
                  N or O  : keep your currently-installed version
                    D     : show the differences between the versions
                    Z     : start a shell to examine the situation
               The default action is to keep your current version.
              [COLOR="#FF0000"]*** fr24feed.ini (Y/I/N/O/D/Z) [default=N] ? [B]N[/B][/COLOR]
              You don't seem to have any dump1090 installed. On the fr24feed start it will automatically install dump1090-mutability.
              Created symlink from /etc/systemd/system/ to /etc/systemd/system/fr24feed.service.
              In upgrade on one of my PI24, something got broken during installation of dump1090-mutability, and it did not get installed.
              I fixed it by this method
              [color=#00AA00][B]sudo[/B] dpkg --configure -a[/color]
              [color=#00AA00]cd /usr/lib/fr24[/color]
              [color=#00AA00]sudo ./[/color]
              Run /etc/init.d/lighttpd force-reload to enable changes
              dump1090-mutability is installed. You can always override it in /etc/fr24feed.ini with any other supported driver.
              Web server (aircraft map) at http://YOUR_DEVICE_IP/dump1090 is enabled by default.
              PI24 ver 1.0.19-5
              Last edited by abcd567; 2018-01-21, 03:39.


              • #22
                How I Configured Pi24 To Run Piaware Data feeder + Display Flightaware MLAT Feed Back on Map

                1. Installed Piaware data feeder on Pi24 as per Step-2 on Flightaware page
                2. edited file /etc/fr24feed.ini and added process arguments line as below

                sudo nano /etc/fr24feed.ini
                [COLOR="#FF0000"]procargs="--net --net-bi-port 30104"[/COLOR]
                --net allows Piaware to get data of DVB-T in beast:30005 (dump1090-mut's default setting)
                --net-bi-port 30104 allows Piaware to feed Flightaware MLAT data to dump1090-mutability so that dump1090-mut can display MLAT planes on Map. Please note that dump1090-mutability does NOT mix MLAT feedback from Flightaware with the data from DVB-T, and does not feed it to any other site. Dump1090-mut keeps the MLAT feedback segregated, and uses it ONLY for dispalying MLAT planes on your local Map

                FR24 ProcArgs for Piaware ver 19-5.png


                • #23
                  Will try keep this updated..

                  Errors/What we (as un-advised volunteers and feeders) seem to find:

                  Changes to update daily script from Jan 9 (v19-2) removed Dump1090-MR leaving many feeders offline and needing Dump1090 installed again

                  New way to see whats broken from 19-2
                  - sudo fr24feed-status

                  Not running scripts with 'sudo'
                  - can change file permission, skip parts of the script and cause auto start/stop issues

                  If installing, unless you know how to do dump1090 manually and fix things after
                  - Wait for manual script to be re-engineered
                  - don't apt-get update/install it
                  - the only manual steps that seem to work (sometimes)

                  Dump1090 web-view AJAX/Data out of date error
                  - fix

                  -Users reporting time sync/server when run as service.
                  - local lookup jessie connection issues likely
                  - investigating, but running as std output works. (Sudo fr24feed stop, sudo fr24feed)
                  - Ping permission needs adjustment (added to later install script sudo chmod 4755 /bin/ping)

                  FR24feed Not auto-starting on reboot
                  - Not sure why/not enough info provided to pinpoint cause or fix
                  - poss owner of run service string (adjusted in later script)

                  Usual "usb_claim_interface error -6" error
                  - USB in use - dump1090 may need to be 'killed', or purged and installed again.

                  bash: /usr/lib/fr24/dump1090: No such file or directory
                  - virtual device fr24feed looks for 'Dump1090' linking failed (ln -s /usr/bin/dump1090-mutability /usr/lib/fr24/dump1090)
                  - Dump1090 missing

                  Dump1090 appears to be run ON-DEMAND as fr24feed is started (not service)
                  - Expect issues if its already going
                  - Will not allow fulltime/100% AVRTCP connection type if true

                  False Detection of existing Dump190 may skip needed file/setup changes

                  'Feeder offline'
                  - probably similar to above. It'll be Dump1090 not working when feeder is - always been around

                  'DVBT' / USB is main config with issues as Dump190-MR has been removed and -Mutability added
                  - Issues during dump1090 deployment experienced

                  New additional apps installed/needed
                  - librtlsdr0, libusb-1.0-0, dirmngr (fixes the old stretch install issue), lighttpd (for the web server) wget (to download dump1090)

                  Installer script doesn't kill Dump1090 possibly before installing a new one

                  Cron job for updating ap can undo-changes - can disable by:
                  sudo rm /etc/cron.d/fr24feed_updater

                  Force update to latest via:
                  sudo /usr/lib/fr24/

                  Long way around while awaiting fix,
                  Purging related apps may have some success for those with patience and time to kill

                  Associated files
                  pi@raspberrypi:~ $ dpkg-query -L fr24feed

                  As for getting a little short at people/closing threads.

                  Basically anyone with DVBT chosen has been affected and is looking for quick answers that just aren't easy to give. Trying to give it and share of findings/fixes. Starting new threads because it doesn't quite seem related (when it really is.. ) prevents this crowd-help going.

                  And there's a lot of hours being put in to try and help ya'll with what is at our home-test-setup disposal

                  Keep in mind there is an official method of contacting support - email. Forums are actually secondary to this but doing our best. But expect delays

                  Frustration level is high [emoji14]
                  Last edited by Oblivian; 2018-01-30, 10:01.
                  Posts not to be taken as official support representation - Just a helpful uploader who tinkers


                  • #24
                    I have been trying workarounds since last two days. It is a fluid situation, as fr24feed is being updated by Flightradar24 staff to overcome the crisis. As a result workarounds I found and posted for ver 19-2 are no more valid for newer ver 19-5.

                    I have found that easiest fix for those using Pi24 is to re-image, then run update script as follows:

                    cd /usr/lib/fr24
                    sudo ./


                    • #25
                      Keep up the good work, Oblivian & abcd567! I hope the guys at FR buy you a beer or three for helping sort out the chaos this upgrade's caused!


                      • #26
                        I would respectfully submit that the installation update process should be refactored and that the "" update script should be abandoned. Debian is full of software infrastructure that supports installation and update dependencies. Running a "hidden" update script on it's own from from systemd (at fr24feed startup) and cron doesn't seem like a good idea. Especially when it changes file permissions and creates unsafe conditions on the server. Experienced Debian users have been able to unpick this mess and get things running again (without re-imaging, sorry but this is terrible advice) but many people have been left with a broken system and little idea how to fix it.

                        In summary - use the installation and update tools that Debian has put at your disposal and stop reinventing the wheel.


                        • #27
                          Originally posted by perseus68
                          Hi guys. I appreciate your efforts in trying to fix stuff. I had the same problem as many users (if not all of them).
                          I just run the script (dump1090-mutablity was OK). So far fr244feed service is running, dump1090-mutability looks happy and receiving planes.
                          The only problem is that I canīt connect fr24:

                          Updated: 10:51:53 GMT+0000 (GMT Standard Time)

                          FR24 Link: Disconnected (connection error)
                          FR24 Radar Code: N/A
                          Aircraft Tracked (ModeS & ADS-B): 22
                          Aircraft Uploaded: N/A
                          Receiver: dvbt, Connected
                          MLAT running: NO

                          I noticed a time sync problem when I look at the Status variables:

                          time_update_utc_s="2018-01-22 10:51:51"

                          Could it be the cause of the connection failure of the fr24feed service?
                          This is getting a mess...
                          Not alone

                          Posts not to be taken as official support representation - Just a helpful uploader who tinkers


                          • #28
                            Hi Oblivian,

                            Thanks to your previous two posts and other contributions I got my installation working again. I have dump1090-mutability v1.15~dev with a few modifications and performance monitoring.

                            Indeed, the file /etc/systemd/system/fr24feed.service was causing a few issues:

                            1) By doing '/bin/chown -R nobody:nogroup /run/dump1090-mutability' it prevented dump1090-mutability writing into this directory with two effects:
                            a) dump1090 map display was not updating
                            b) performance data were not collected

                            I removed the '/run/dump1090-mutability' from this line and I also issued the following command to reset the correct permissions for this directory:
                            ~ $ sudo chown -R dump1090:nogroup /run/dump1090-mutability

                            2) The fr24feed process does not seem to work well when running as 'nobody' user. I observed 3 effects:
                            a) it was unable to resolve 'localhost' and connect to dump1090 on port 30005 (I fixed by specifying
                            b) it was unable to run NTP as seen in the log: '[time][e]Failed to synchronize time'
                            c) it was unable to connect to as seen in the log: '[e]Could not connect to, errno: 101'

                            I tried your suggestion to run it interactively (sudo fr24feed), and this worked. Therefore, for now I edited /etc/systemd/system/fr24feed.service again and specified the 'root' user. This is working for now. The file currently looks like this:

                            Description=Flightradar24 Decoder & Feeder
                            ExecStartPre=-/bin/mkdir -p /run/dump1090-mutability /var/log/fr24feed /run/fr24feed /var/log/lighttpd
                            ExecStartPre=-/bin/touch /dev/shm/decoder.txt
                            [B]ExecStartPre=-/bin/chown -R nobody:nogroup /var/log/fr24feed /run/fr24feed /dev/shm/decoder.txt[/B]
                            ExecStartPre=-/bin/chmod a+rwx /var/log/lighttpd
                            Feel free to edit/move/remove post as required.
                            Last edited by Oblivian; 2018-01-23, 10:07.
                            T-EIKY1 | T-EICK1


                            • #29
                              Originally posted by k5hmd
                              How do you temporarily disable the automatic updater?

                              F-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)


                              • #30
                                Just received email answer from FR24 support. A newer build is supposed to be deployed tomorrow.

                                Quoting fr24's email: "Sorry for the late reply. We had missed the emails.

                                This [the fr24 feed stopped] because of an update we released. Please leave them [the feeds] like this for now. We are working on a newer build that will hopefully fix all the issues. Currently aiming for a release tomorrow. Your feeds should get updated automatically.
                                Best Regards,

                                Gesendet von iPhone mit Tapatalk