Announcement

Collapse
No announcement yet.

Aircraft map does not show up after changing feeder settings to "AVR TCP"

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

  • Aircraft map does not show up after changing feeder settings to "AVR TCP"

    After working smoothly for months I had to reboot my Raspberry Pi that ran FR24feeder. So, after booting up I ran into the well known Dump1090 errors mentioned in this forum (usb_claim_interface error -6 Error opening the RTLSDR device: Device or resource busy), resulting in my feed being connected to FR24 server but not sending any data.
    This is because I have a manually installed version of dump1090-mutability 1.14 as well as the in-built dump1090 that comes with the installer package.

    I followed Oblivian's well documented recommendations and changed FR24 Feeder "Receiver"-Settings from "DVB Stick (default)" to "AVR TCP" with a "Host/IP"-Setting" of "localhost:30002". This did the job and my feed was up again, sending data to FR24

    But unfortunately from now on I can no longer see the DUMP1090-webpage with the map by entering http://<IP-address>:8080 into my browser, whereas the FR24 Feeder Status webpage at http://<IP-address>:8754 still works.

    I still have the "--net" argument in the "Process arguments" section of "FR24 Feeder Settings" but when I enter http://<IP-address>:8080 there is no answer from the webserver.

    Any suggestions what to do?

  • #2
    Need to follow the guide from abcd to remove the packaged dump1090 (no map anymore) and switch back to starting mutability first.

    I forget the steps right now

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

    Comment


    • #3
      Try:
      http://<IP-address>/dump1090/gmap.html

      If above does not work, change process arguments to:
      --net --net-http-port 8080
      Last edited by abcd567; 2018-04-15, 21:08.

      Comment


      • #4
        Thank you for your tips but unfortunately both of them do not work.
        How can I prevent automatic startup of packaged dump1090 after booting? Do you know where I can set this in the startup script?

        The fact is that before reboot caused by a power failure things were working perfectly for months with the very same setup. There were no upgrades during this time. I just forgot how I managed to have it running. The only thing I remember was stopping the packaged dump1090 manually and starting dump-mutability 1.14 manually. And from then on it worked perfectly.

        So any hints how to manually stop and start either packaged dump and dump-mutability 1.14 are welcome.

        Comment


        • #5
          The FR24 auto-update may have executed on restart. Which goes and blindly replaces Dump1090

          It seems to vary between setups, but if it has its way it makes Dump1090 run-on-demand. Disabling the normal setup. And therefore conflicts when starting up fr24feed if it already has as a service

          Some of the regular commands around it are here https://forum.flightradar24.com/thre...ll=1#post74851

          And ABCDs setting up -15 mutability thread has more.

          There are various run files dropped that start it. /Run and init.d

          Not for the feint hearted - https://forum.flightradar24.com/thre...l=1#post100314

          Most peoples setups seemed to have stabilised.

          It's now a matter of checking each function on their own to see if the services are auto starting - without allowing them to all conflict
          (if dump1090 starting on startup away from FR24feed.. if so reconfigure fr24feed as avr, check it starts correctly when called if set as DVBT)
          Posts not to be taken as official support representation - Just a helpful uploader who tinkers

          Comment


          • #6
            First try to clear browser cache (Ctrl+Shift+Delete), then reload browser (Ctrl+F5).

            If you cannot debug/solve the problem, then use uninstall followed by reinstall as follows:

            (1) Uninstall & purge the fr24feed and dump1090-mutability
            Code:
            sudo dpkg --purge fr24feed
            
            sudo dpkg --purge dump1090-mutability
            
            sudo dpkg --purge dump1090
            
            sudo rm -rf /usr/share/dump1090-mutability/html
            (2) Check if uninstalled successfully
            Code:
            apt-cache policy fr24feed
            
            apt-cache policy dump1090-mutability
            
            apt-cache policy dump1090

            (3) Reinstall fr24feed by bash script
            Code:
            sudo bash -c "$(wget -O - https://repo-feed.flightradar24.com/install_fr24_rpi.sh)"

            (4) During configuration, select "Receiver = DVBT", and after saving/completing configuration, restart fr24 feed. Restarting with "Receiver=DVBT" will make fr24feed to install dump1090-mutability v1.14, and you will not need to install dump1090-mutability v1.14 separately.
            Code:
            sudo systemctl restart fr24feed
            (5) Check map at <ip-of-pi>/dump1090/ , and <ip-of-pi>:8080 . It should show on both.

            (6) In case of problem, clear browser cache (Ctrl+Shift+Delete), then reload browser (Ctrl+F5).

            Comment


            • #7
              Solved. it's running again.

              Thank you @Oblivian and @abcd567 for all your help. But I was afraid to uninstall and reinstall everything. So I played around with @Oblivian's tips in the additional info thread: https://forum.flightradar24.com/thre...dditional-Info and it started working again!

              Here is what I did to solve my problem:
              1. I switched back to "DVBT Stick (default)" in "Receiver" settings of FR24 Feeder Settings (http://myIPaddress:8754/settings.html), hit Save and then Restart button
              2. In terminal I entered the command "sudo fr24feed-status" which was answered by Receiver: down ... failed!
              3. I stopped dump1090 service by entering command "sudo service dump1090-mutability stop"
              4. I started service again by entering "sudo service dump1090-mutability start"
              5. Bingo! It started working again and is showing the map at URL http://myIPaddress:8080

              I still do not know what caused my problem. Obviously after restarting my Raspberry Pi dump1090-mutability is automatically started first by the system before FR24feeder is started, which is not a good idea. Starting dump1090-mutability after FR24feeder service seems to work.

              The question is now: how can I prevent dump1090-mutability from starting first? Of course this must be in a configuration file but I do not know where?

              Comment


              • #8
                There's a high probability dump1090 was running and therefore starting fr24feeds version couldn't connect to dvbt as it already was. And maps won't have been loading due to the bundled version being misconfigured. Or dual install

                Chances are stopping it (both) and starting fr24 and trying to restart dump1090 probably actually failed to restart it due to fr24 being able to take stick ownership first.

                Check the status of dump1090 service now. Sudo service dump1090-mutability status.

                Probably say failed to start. Just the same way fr24 couldn't load it.

                It's the way it is. You need to make a choice. Remove separate dump1090 and use bundled version (maps only work in dvbt option). Or remove all dump1090 references and put -dev back on and run in Avrtcp mode.

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

                Comment


                • #9
                  Originally posted by abcd567 View Post
                  First try to clear browser cache (Ctrl+Shift+Delete), then reload browser (Ctrl+F5).

                  If you cannot debug/solve the problem, then use uninstall followed by reinstall as follows:

                  (1) Uninstall & purge the fr24feed and dump1090-mutability
                  Code:
                  sudo dpkg --purge fr24feed
                  
                  sudo dpkg --purge dump1090-mutability
                  
                  sudo dpkg --purge dump1090
                  
                  sudo rm -rf /usr/share/dump1090-mutability/html
                  (2) Check if uninstalled successfully
                  Code:
                  apt-cache policy fr24feed
                  
                  apt-cache policy dump1090-mutability
                  
                  apt-cache policy dump1090

                  (3) Reinstall fr24feed by bash script
                  Code:
                  sudo bash -c "$(wget -O - https://repo-feed.flightradar24.com/install_fr24_rpi.sh)"

                  (4) During configuration, select "Receiver = DVBT", and after saving/completing configuration, restart fr24 feed. Restarting with "Receiver=DVBT" will make fr24feed to install dump1090-mutability v1.14, and you will not need to install dump1090-mutability v1.14 separately.
                  Code:
                  sudo systemctl restart fr24feed
                  (5) Check map at <ip-of-pi>/dump1090/ , and <ip-of-pi>:8080 . It should show on both.

                  (6) In case of problem, clear browser cache (Ctrl+Shift+Delete), then reload browser (Ctrl+F5).
                  I'm starting to get the feeling It seems Dump1090 after either updating, or keeping a particular version of fr24feed has changed states or overwriting the way an external dump1090 install functions.

                  I've adjusted my info pages to effectively say external dump1090 maps are only available when using DVBT mode. I've hidden away OR external Dump1090 install and not change config to DVBT to prevent that script running - not sure if it still runs at time of auto update.

                  Obviously when fr24 is set to DVBT it has no option but to call Dump1090 after checking for it and installing its own one, which isn't clear from hidden startup if it includes the --net functions, but presumably so as it is marketed with a self view map. Or if it runs as a service (pretty sure its run on demand)

                  HOWEVER, that shouldn't be leading to multiple people needing different URLs to get it to function. We know a standard start-as-service of Dump1090 is preconfigured with it. And if you have an external web server as our 1.14/1.15DEV guides indicate it adds just the /Dump1090/ pointer (In which case FR24 will fail in DVBT mode with a conflict obviously)

                  My Pi is on a separate 24/7 task at present to do a bit more testing. But I'm wary of the dump1090 bash included, we shouldn't have users reporting different URLs are needed for the maps

                  Only thoughts
                  Run-on-demand included Dump1090 is crashing (not enough reboots when making changes) and causing issues - should be /gmap.html with no Dump1090 webserver alias?
                  Included dump1090 breaking standalone service and webserver installs (may only happen after changing to DVBT accidentally) - should be /dump1090/ alias
                  Kill script included is stopping the separate standalone service when people use it within fr24feeed and confusing things.

                  Maps should work fine in AVR mode if it's the latter, as it's fulltime connected to the stick and managing the web updates. Running fr24 is just another downstream app. And not mess with that setup.
                  Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                  Comment

                  Working...
                  X