thom-x / docker-fr24feed-piaware-dump1090 Goto Github PK

Specifications

• Image hash or version: latest/1.3.1
• Platform: Raspberry Pi 1B (old ;) ), armv6
• Subsystem: ?

Expected Behavior

I would expect the latest tag of this repo on the Docker Hub to use v4 of flightaware/dump1090.

Actual Behavior

The image currently pushed (one month ago) to the Docker Hub with tag latest is version 1.3.1 of this repo, which uses v3.8.1 of flightaware/dump1090.
There is an older (5 months ago) tagged flightaware-v4.0 which, based on its name, I'm assuming is using v4 of flightaware/dump1090.

Shouldn't latest point to v4?

Steps to Reproduce the Problem

1. Install from Docker Hub targeting the latest tag
2. Run and noticed that on the webpage it indicates v3.8.1 in the upper right of the page. I'd have expected v4.0

Hey, I have a Mode-S GPS Beast Receiver (connected to an ADS-B antenna) and I don't know how to connect it so I can run Dump1090, Fr24Feed and PiAware with it, instead of with a DVBT dongle. Also, I want to run this container with Docker running in my Synology NAS.

I'd appreciate your help!

FR24 sent out an email asking feeders to disable MLAT

Important information
If you intend to share data to networks alongside Flightradar24, in your Flightradar24 receiver please disable MLAT to the following settings: MLAT=“no”and MLAT-without-gps=“no”. This is to ensure the quality of the data we receive and use and to reduce incompatibility with other services.

FR24FEED_MLAT and FR24FEED_MLAT_DASH_WITHOUT_DASH_GPS should default to no?

Since the update today (29.02) it seems to be working all good but I have seen the following errors since some time already.

2020-02-29 14:13:21,321 INFO Included extra file "/etc/supervisor/conf.d/supervisord.conf" during parsing
2020-02-29 14:13:21,329 INFO RPC interface 'supervisor' initialized
2020-02-29 14:13:21,329 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2020-02-29 14:13:21,330 INFO supervisord started with pid 6
2020-02-29 14:13:22,332 INFO spawned: 'python' with pid 9
2020-02-29 14:13:22,332 INFO spawned: 'fr24feed' with pid 10
2020-02-29 14:13:22,333 INFO spawned: 'piaware' with pid 11
error | Local time: 2020-02-29 14:13:22 +0100
error | GMT+0 time: 2020-02-29 13:13:22 +0100
error | Your machine should be set as GMT+0 time zone!
warning | Time zone is not set to GMT+0
2020-02-29 14:13:22 | [main][i]FR24 Feeder/Decoder
2020-02-29 14:13:22 | [main][i]Version: 1.0.24-5/generic
2020-02-29 14:13:22 | [main][i]Built on Oct 30 2019 07:23:36 (static-i386_amd64-builds-and-macos-dump1090-update-c308dae.git/Linux/amd64)
2020-02-29 14:13:22 | [main][i]Running on: debian10
2020-02-29 14:13:22 | [main][i]Local IP(s): 172.17.0.2
2020-02-29 14:13:22 | [main][i]Copyright 2012-2019 Flightradar24 AB
2020-02-29 14:13:22 | [main][i]https://www.flightradar24.com
2020-02-29 14:13:22 | [main][i]DNS mode: LIBC
2020-02-29 14:13:22 | [main][i]Automatic updates are DISABLED
2020-02-29 14:13:22 | ERROR: bash: /sbin/rmmod: No such file or directory
2020-02-29 14:13:22 | [w]Detected --net argument for dump1090, disabling internal RAW feed!
2020-02-29 14:13:22 | [w]Detected --net argument for dump1090, disabling internal BS feed!
2020-02-29 14:13:22 | info | [httpd]Server started, listening on 0.0.0.0:8754
2020-02-29 13:13:22Z warning: /etc/piaware.conf:7: unrecognized option flightaware-user
2020-02-29 13:13:22Z warning: /etc/piaware.conf:8: unrecognized option flightaware-password
2020-02-29 14:13:22 | [i]PacketSenderConfiguration::fetch_config(): Yoda configuration for this receiver is disabled
2020-02-29 14:13:22 | [d]TLSConnection::ctor(): Enable verify_peer in production code!
2020-02-29 14:13:22 | [main][i]Reader thread started

I would ignore the error with the different false time zone, but this "bash error" could be maybe fixed and "piaware.conf:7: unrecognized option" seems to be a problem since I got my piaware.conf like this, which should correct.

# This file configures piaware and related software.
# You can edit it directly or use piaware-config from the command line
# to view and change settings.
#
# If /boot/piaware-config.txt also exists, then settings present in
# that file will override settings in this file.
flightaware-user user123
flightaware-password password123456
feeder-id b***b645-****-****-****-d59ab6f***3c

The flightaware feeder seems to be working when I visit the "My ADS-B" page.

Upon looking at the cover,

Is that a max range plot or is it the theoretical antenna range from heywhatsthat terrain-limit rings ?

How could I set it up in your image??

Hi Thomas, the used components had released new versions.

Can you upgrade your repo?

thank you.

Can you please explain how http://www.heywhatsthat.com / Terrain-limit rings is used? What are the implications?

I have read this and wonder which mac address ? The one of my network adapter or ?
Change --mac-address="ff:ff:ff:ff:ff:ff" with your own MAC address.

I am running the docker container on unraid with an usb dvt stick.
The fr24 side is working good but since the update today the local skyview is loading endless.

I was trying to use the OWM and it was not working after I added the API key (free version). I did some poking around and it appears that the map API calls used are not supported in the free version. From what I could tell the 'advanced weather maps' API is currently being called which requests a paid subscription (https://openweathermap.org/price#weather).

These are the errors I am seeing in my browser console

GET https://a.sat.owm.io/vane/2.0/weather/WS10/8/67/102?appid=<myapikey was here> 401 (Unauthorized)

page content:

{"cod":401, "message": "Invalid API key. Please see http://openweathermap.org/faq#error401 for more info."}

401 is an unauthorized error per the faq page - I did run an API call against basic maps with my API key and did not have an issue.

Advance weather maps API call example
http://maps.openweathermap.org/maps/2.0/weather/{op}/{z}/{x}/{y}?appid=[{API key}

Basic weather maps API call example
https://tile.openweathermap.org/map/{layer}/{z}/{x}/{y}.png?appid={API key}

If that is a known requirement then would be nice to add that to the documentation. If I am totally missing something then let me know.

BTW, thank you for the great work building this! I appreciate what you are doing.

Looking to get back into ADSB, long time ago ran on windows.
I no longer have an FR24 key, not sure i ever had a feeder ID.
How do i get these keys from the websites without having to install piaware on a pi which seems to be required step to get the keys in the first place?
Or is there a way to bootstrap using this image?

I am missing config options for both of them, just like e.g. HTML_RECEIVER_STATS_PAGE_FLIGHTRADAR24.

pseudo urls:
https://www.adsbexchange.com/api/feeders/?feed=SomeId&t=time.now()

https://planefinder.net/coverage/receiver/12345

At first, thanks for your awesome work. I am using this image for several months now and i wasn't disappointed. However, i tried to setup the two web frontends with traefik, and although the live view on port 8080 are fine, the setup view on port 8754 only loads the most basic HTML, and all other assets do not load. When trying to load a non-loading image in a new tab, the browser returns a HTTP 200, but with the content "Forbidden :>".

I assume that my traefik labeling isn't the culprit, since the connection to the container is successful, however, i could need some help figuring out the "Forbidden :>" issue.

When reading the logs from Docker, it is full with lines like this:
[07/Jun/2019 22:54:46] "GET ..............
Those are webserver logs from dump1090.
Any way to disable webserver logs?

I use the current version of Dump1090-fa without piaware client on a Pi Zero. It provides the receiver's data on the LAN via BEAST on port 30005. I use the Thom-X container as a client. In the stack, the remote IP of the DUMP1090 can be configured for FR24Feed and Piaware. These clients are working well. I cannot find any environment variables for Planefinder (e.g. tcp_address etc.). You can configure the connection type, IP etc. via the config page "dockerhost:30053" but this only works as long as the container is running. I have saved the config file /planefinder/config/pfclient-config.json via volume mapping on the Dockerhost and it is also available to the container after the restart, but unfortunately it is not used by the PFCLIENT.

How can I configure a remote Dump1090 in Planefinder?

Here is my complete Stack:

`version: "2"
services:

fr24feed-piaware:
container_name: fr24feed
networks:
net:
ipv4_address: xx.xx.xx.xx
dns:
- xx.xx.xx.xx
hostname: fr24feed
image: thomx/fr24feed-piaware:latest
restart: unless-stopped
volumes:
- /etc/localtime:/etc/localtime:ro # needed to sync time for MLAT
- /home/pi/nfs/planefinder/config:/planefinder/config/
- /home/pi/nfs/planefinder/log:/planefinder/log/
environment:
####### Allgemeine Einstellung ##############
- HTML_DEFAULT_TRACKER=FlightAware
- SERVICE_ENABLE_DUMP1090=false
- SERVICE_ENABLE_HTTP=true
- HTML_SITE_LAT=xxxxx
- HTML_SITE_LON=xxxxx
- HTML_SITE_NAME=xxxx

####### FlightAware Einstellung ##############
- SERVICE_ENABLE_PIAWARE=true
- PIAWARE_FEEDER_DASH_ID=xxxxxxxxx
- PIAWARE_RECEIVER_DASH_TYPE=other
- PIAWARE_RECEIVER_DASH_HOST=xx.xx.xx.xx
- PIAWARE_RECEIVER_DASH_PORT=30005
- HTML_RECEIVER_STATS_PAGE_FLIGHTAWARE=https://flightaware.com/adsb/stats/user/

####### FlightRadar24 Einstellung ##############
- SERVICE_ENABLE_FR24FEED=true
- FR24FEED_FR24KEY=xxxxxxxx
- FR24FEED_RECEIVER=beast-tcp
- FR24FEED_HOST=xx.xx.xx.xx:30005
- FR24FEED_BS=no
- FR24FEED_RAW=no
- FR24FEED_LOGMODE=1
- FR24FEED_LOGPATH=/tmp
- FR24FEED_MLAT=yes
- FR24FEED_MLAT_DASH_WITHOUT_DASH_GPS=yes
- HTML_FR24_FEEDER_STATUS_PAGE=http://xx.xx.xx.xx:8754/
- HTML_RECEIVER_STATS_PAGE_FLIGHTRADAR24=https://www.flightradar24.com/account/feed-stats/?id=T-XXXXXXX

####### Planefinder Einstellung ##############
- SERVICE_ENABLE_PLANEFINDER=true
- PLANEFINDER_SHARECODE=xxxxxxxxxx
ports:
- 8754:8754
- 8080:8080
- 30053:30053
logging:
options:
max-size: 30m
tmpfs:
- /run:exec,size=32M
- /usr/lib/fr24/public_html/data:size=32M
networks:
net:
external:
name: macvlan

`

Steps to Reproduce the Problem

1. restart Container will loss config data for Planefinder

Specifications

• Image hash or version: 1.18
• Platform: Docker
• Subsystem: Unraid

Expected Behavior

FlightRadar 24 feeder is updated to latest version

Actual Behavior

FlightRadar 24 feeder is out of date as of January 19th 2023 with version 1.0.25-3 and FlightRadar will stop supporting this version after Feb 28, 2023. Email Received from FlighRadar regarding the issue

Steps to Reproduce the Problem

Following values should be configurable through env.

DefaultSiteCirclesCount = 3;
DefaultSiteCirclesBaseDistance = 100;
DefaultSiteCirclesInterval = 50;

Hi again,
since I got a "empty" default piaware.conf I thought that flightaware would not work and I got not working site in the tab "my ADS-B", but I saw I its running all day without username/password/feeder-id.

2019-06-22 18:39:14,274 CRIT Supervisor running as root (no user in config file)
2019-06-22 18:39:14,274 INFO Included extra file "/etc/supervisor/conf.d/supervisord.conf" during parsing
2019-06-22 18:39:14,278 INFO RPC interface 'supervisor' initialized
2019-06-22 18:39:14,278 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2019-06-22 18:39:14,278 INFO supervisord started with pid 6
2019-06-22 18:39:15,280 INFO spawned: 'python' with pid 9
2019-06-22 18:39:15,281 INFO spawned: 'fr24feed' with pid 10
2019-06-22 18:39:15,282 INFO spawned: 'piaware' with pid 11
2019-06-22 18:39:15 | [main][i]FR24 Feeder/Decoder
2019-06-22 18:39:15 | [main][i]Version: 1.0.18-5/generic
2019-06-22 18:39:15 | [main][i]Built on Mar 4 2016 16:26:55 (devel-d11ca48.git/Linux/x86_64)
2019-06-22 18:39:15 | [main][i]Copyright 2012-2016 Flightradar24 AB
2019-06-22 18:39:15 | [main][i]http://flightradar24.com
2019-06-22 16:39:15Z warning: /etc/piaware.conf:9: invalid value for option feeder-id: YOUR_FEEDER_ID
2019-06-22 18:39:15 | [main][i]DNS mode: LIBC
2019-06-22 18:39:15 | [main][i]Automatic updates are DISABLED
2019-06-22 18:39:15 | ERROR
2019-06-22 18:39:15 | [w]Detected --net argument for dump1090, disabling internal RAW feed!
2019-06-22 18:39:15 | [w]Detected --net argument for dump1090, disabling internal BS feed!
2019-06-22 18:39:15 | [httpd][i]Server started, listening on 0.0.0.0:8754
2019-06-22 18:39:15 | [main][i]Reader thread started
2019-06-22 18:39:15 | [master][i]Starting processing thread
2019-06-22 18:39:15 | [reader][i]Initializing reader
2019-06-22 18:39:15 | [main][i]MLAT data feed started
2019-06-22 18:39:15 | [reader][i]Connecting to Beast receiver via (exe:///usr/lib/fr24/dump1090 --net --write-json /usr/lib/fr24/public_html/data --raw --mlat)
2019-06-22 18:39:15 | [mlat][i]Waiting for MLAT configuration
2019-06-22 18:39:15 | [reader][i]Connected to the receiver, configuring
2019-06-22 18:39:15 | [reader][i]Configured, processing messages
Sat Jun 22 18:39:15 2019 CEST dump1090-fa starting up.
rtlsdr: using device #0: Generic RTL2832U (Generic, RTL2832U, SN 77771111153705700)
Found Rafael Micro R820T tuner
rtlsdr: tuner gain set to 49.6 dB
Allocating 4 zero-copy buffers
2019-06-22 18:39:16 | [reader][w]Setting new UTC offset: 0!
2019-06-22 18:39:16 | [time][i]Synchronizing time via NTP
2019-06-22 18:39:16,380 INFO success: python entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2019-06-22 18:39:16,380 INFO success: fr24feed entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2019-06-22 18:39:16,380 INFO success: piaware entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2019-06-22 18:39:21 | [time][i]Time synchronized correctly, offset +0.0009 seconds
2019-06-22 18:39:21 | [main][i]Feed Network client started
2019-06-22 18:39:21 | [feed][i]Downloading configuration
2019-06-22 18:39:22 | [feed][c]Interval: 5s
2019-06-22 18:39:22 | [feed][c]Latitude: 52.5935
2019-06-22 18:39:22 | [feed][c]Longitude: 11.8577
2019-06-22 18:39:22 | [feed][c]GND: YES
2019-06-22 18:39:22 | [feed][c]NonADSB: YES
2019-06-22 18:39:22 | [feed][c]Timestamps: optional
2019-06-22 18:39:22 | [feed][c]Max range AIR: 350.0nm
2019-06-22 18:39:22 | [feed][c]Max range GND: 100.0nm
2019-06-22 18:39:22 | [feed][i]defined 4 servers
2019-06-22 18:39:22 | [stats][i]Stats thread started
2019-06-22 18:39:22 | [feed][n][email protected]:8099/UDP
2019-06-22 18:39:22 | [feed][n]connecting
2019-06-22 18:39:22 | [feed][n]connected via UDP (fd 8)
2019-06-22 18:39:22 | [feed][n]working
2019-06-22 18:39:22 | [mlat][i]MLAT configuration received, service ENABLED
2019-06-22 18:39:22 | [mlat][i]Starting MLAT with preconfigured position: 52.59,11.86,108.0
2019-06-22 18:39:22 | [mlat][i]MLAT bandwidth reduction active, level 1
2019-06-22 18:39:22 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
2019-06-22 18:39:22 | [mlat][i]Registering MLAT station
2019-06-22 18:39:22 | [feed][i]sent 1, filtered 0 AC in 1 packet
2019-06-22 18:39:22 | [mlat][i]Registering MLAT station: SUCCESS
2019-06-22 18:39:26 | [mlat][i]Received ADS-B time references AC:
2019-06-22 18:39:26 | [mlat][i] 896479

After that I tried to paste in my stuff into piaware.conf and restarted the docker but then piaware quits after seconds with exit code 4. So any way to stop feeding that automatically or how my login data can work ?

Specifications

• Image hash or version: PR-106 and latest
• Platform: amd64
• Subsystem:

Expected Behavior

Simply start and feed FR24/PiAware

Actual Behavior

Crash loop without any error

Steps to Reproduce the Problem

1. Start the container with this command: docker run -d -p 8080:8080 -p 8754:8754
   --device=/dev/bus/usb:/dev/bus/usb
   -v "/etc/localtime:/etc/localtime:ro"
   -e "FR24FEED_FR24KEY=<>"
   -e "PIAWARE_FEEDER_DASH_ID=<>"
   -e "HTML_SITE_LAT=<>"
   -e "HTML_SITE_LON=<>"
   -e "HTML_SITE_NAME=<>"
   -e "SERVICE_ENABLE_ADSBEXCHANGE=false"
   -e "MLAT_EXACT_LAT=<>"
   -e "MLAT_EXACT_LON=<>"
   -e "MLAT_ALTITUDE_MSL_METERS=<>"
   -e "SERVICE_ENABLE_PLANEFINDER=false"
   -e "TZ=Etc/GMT+0"
   --tmpfs /run:exec,size=32M
   --tmpfs /planefinder/log:exec,size=32M
   --tmpfs /usr/lib/fr24/public_html/data:size=32M
   --restart=unless-stopped
   --network=myNetwork
   --name fr24feed
   thomx/fr24feed-piaware:PR-106
2. USB Tuner is: Bus 002 Device 003: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T

I've attached some logs.
fr24feed.log

(removing the default issue template, as this is not really an issue report but a question/suggestion)

Question: would there be interest to publish a receiver's data to more public plane tracker websites?
For example:

• ADS-B Exchange
  • This one is new to me, seems interesting/non commercial, even its UI is very comparable to our local receiver's UIs : tar1090, see #52
• OpenSky Network
• AirNav RadarBox
• Plane Finder
• ADSBHub

I have two rtl devices, one for my 433MHz temperature sensors, and one for ADS-B Multi-Portal Feeder

Specifications

• Image hash or version: latest
• Platform: linux
• Subsystem: arm/v6

Expected Behavior

HTML_DEFAULT_TRACKER if set to Flightradar24 will change the default tracker in the UI to FlightRadar 24.
HTML_SITE_NAME if set will change the default site title from 'Dump1090 plane tracker' to the set value

Actual Behavior

HTML_DEFAULT_TRACKER and HTML_SITE_NAME are ignored and fall back to defaults.

Steps to Reproduce the Problem

1. Spin up Docker container using the following docker-compose file:

version: "3.7"
services:
  fr24feed-piaware:
    image: "thomx/fr24feed-piaware"
    container_name: piaware
    restart: unless-stopped
    environment: 
      - "FR24FEED_FR24KEY=XXXXXXXXX"
      - "PIAWARE_FEEDER_DASH_ID=XXXXXXXXXX"
      - "HTML_SITE_LAT=XXXXXXXX"
      - "HTML_SITE_LON=XXXXXXX"
      - "HTML_SITE_NAME=MyAwesomeFlightRadar"
      - "HTML_DEFAULT_TRACKER=Flightradar24"
      - "HTML_RECEIVER_STATS_PAGE_FLIGHTAWARE=https://flightaware.com/adsb/stats/user/XXXXXXX"
      - "HTML_RECEIVER_STATS_PAGE_FLIGHTRADAR24=https://www.flightradar24.com/account/feed-stats/?id=XXXXXXXX"
      - "HTML_FR24_FEEDER_STATUS_PAGE=http://192.168.30.222:8754/"
    devices:
      - "/dev/bus/usb"
    ports:
      - "8754:8754"
      - "8082:8080"

Hi there,

I just received and email from fr24 stating that version 1.0.25-3 will no longer be supported after Feb 28 2023.
I updated to the most recent image 1.18.0 but it still runs on the 1.0.25-3 version of fr24.

Another feature request, there are pre-made deb packages for the client

https://planefinder.net/coverage/client

I want to use this with network input (receiver on a different device sending tcp raw/beast output) to this container

Any plans for ARM architecture?

Hello, I wasn't sure where to ask this question, but I decided to post it here since I'm running this container.

A couple of days ago I set up my receiver, and to my satisfaction, the local dump1090 interface doesn't have any problems showing MLAT tracks of local flight school (C152) traffic (when in range). For this reason, I'm puzzled as to why those airplanes do not show up either on FlightAware, FlightRadar24, or ADSBexchange. Both FlightAware and ADSBexchange show the receiver MLAT as up and synchronised.

Edit: Additionally, it is clear by looking at my stats that at least FlightAware is receiving MLAT positions, maybe they hide all GA traffic in Spain or something...

If this is the case, my question would be why doesn't it appear on ADSBexchange, as they claim not to "censor" anything, is it perhaps because of the lower number of feeders they have?

Specifications

• Image hash or version: 3b511184a1cb
• Platform: Raspberry Pi
• Subsystem:

Expected Behavior

Actual Behavior

FlightRadar24 is receiving MLAT from my station but FlightAware isn't.

Specifications

I just attempted an upgrade from fa493ee73552d4ecdea6085aa46dac454a6468f837176aa1fe80fe894cb4e07c to latest (e6a44d31fdd73dd71fb9c433ddf9dc7e70a69eeb2009a0acd5f33a53a414a917). I did this by stoping the old container, pulling the latest image, and then trying to start the container back up using the new image. This leads to no aircraft being tracked and the following messages repeated in the logs.

Expected Behavior

Image is able to connect to USB stick.

Actual Behavior

2020-05-11 09:17:51 | [reader][i]Connecting to Beast receiver via (exe:///usr/lib/fr24/dump1090 --net --write-json /usr/lib/fr24/public_html/data --raw --mlat)
2020-05-11 09:17:51 | [reader][i]Connected to the receiver, configuring
2020-05-11 09:17:51 | [reader][i]Configured, processing messages
Mon May 11 09:17:51 2020 UTC  dump1090-fa v3.8.1 starting up.
rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001197)
usb_claim_interface error -6
rtlsdr: error opening the RTLSDR device: Device or resource busy
2020-05-11 09:17:51 | [reader][i]Connection terminated
2020-05-11 09:17:51 | [main][i]Terminating child process 347 with SIGETERM

Yesterday I noticed that the map on ADS-B Exchange had a similar but much better UI than the one available here on port 8080.
Therefore, since dump1090-fa which lacks many features and doesn't support mobile browsers, it would be a very nice improvement using tar1090 instead as it provides a much better UI and UX.

Is there any downside to this?

Specifications

• Image hash or version: 1.18.0.2
• Platform: HA OS
• Subsystem:

Expected Behavior

hide sidebar to see the map on mobile devices

Actual Behavior

sidebar overlapping the whole screen and map could not be shown

Steps to Reproduce the Problem

1. open Addon frontend on mobile device with portrait screen

Hi,

is it possible to get an updated docker image with Piaware V6.0 in it? With my current container i am unable to update the piaware installation as it just returns with the following error message:

"couldn't lock /run/piaware/upgrader.pid: couldn't open "/run/piaware/upgrader.pid": no such file or directory"

Specifications

• Image hash or version: ecd73f42ddf66091d1c9c8d2544d1e8fd2bd7d93254c2a4bf2498216df3463a0
• Platform: Unraid
• Subsystem: Docker

Expected Behavior

Container actually starting correctly.

Actual Behavior

Container fails to start with the following log

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 01-confd-fr24feed: executing...
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[267]: INFO Backend set to env
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[267]: INFO Starting confd
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[267]: INFO Backend source(s) set to
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[267]: INFO /etc/fr24feed.ini has UID 99 should be 0
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[267]: INFO /etc/fr24feed.ini has GID 100 should be 0
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[267]: INFO /etc/fr24feed.ini has mode drwxrwxrwx should be -rwxrwxrwx
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[267]: INFO /etc/fr24feed.ini has md5sum d41d8cd98f00b204e9800998ecf8427e should be d720cdd401cb34929e7ccb1122c7cd53
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[267]: INFO Target config /etc/fr24feed.ini out of sync
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[267]: ERROR rename /etc/.fr24feed.ini467061054 /etc/fr24feed.ini: file exists

2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[267]: FATAL rename /etc/.fr24feed.ini467061054 /etc/fr24feed.ini: file exists
[cont-init.d] 01-confd-fr24feed: exited 1.
[cont-init.d] 02-confd-piaware: executing...
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[280]: INFO Backend set to env
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[280]: INFO Starting confd
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[280]: INFO Backend source(s) set to
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[280]: INFO /etc/piaware.conf has UID 99 should be 0
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[280]: INFO /etc/piaware.conf has GID 100 should be 0
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[280]: INFO /etc/piaware.conf has mode drwxrwxrwx should be -rwxrwxrwx
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[280]: INFO /etc/piaware.conf has md5sum d41d8cd98f00b204e9800998ecf8427e should be 02b68abf8a0d00b67789aeb454a293ab
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[280]: INFO Target config /etc/piaware.conf out of sync
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[280]: ERROR rename /etc/.piaware.conf045869135 /etc/piaware.conf: file exists

2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[280]: FATAL rename /etc/.piaware.conf045869135 /etc/piaware.conf: file exists
[cont-init.d] 02-confd-piaware: exited 1.
[cont-init.d] 03-confd-html: executing...
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[294]: INFO Backend set to env
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[294]: INFO Starting confd
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[294]: INFO Backend source(s) set to
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[294]: INFO /usr/lib/fr24/public_html/config.js has UID 99 should be 0
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[294]: INFO /usr/lib/fr24/public_html/config.js has GID 100 should be 0
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[294]: INFO /usr/lib/fr24/public_html/config.js has mode drwxrwxrwx should be -rwxrwxrwx
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[294]: INFO /usr/lib/fr24/public_html/config.js has md5sum d41d8cd98f00b204e9800998ecf8427e should be 8d80f325c4ec83f92dd4f8d19c759f89
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[294]: INFO Target config /usr/lib/fr24/public_html/config.js out of sync
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[294]: ERROR rename /usr/lib/fr24/public_html/.config.js807195435 /usr/lib/fr24/public_html/config.js: file exists

2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[294]: FATAL rename /usr/lib/fr24/public_html/.config.js807195435 /usr/lib/fr24/public_html/config.js: file exists
[cont-init.d] 03-confd-html: exited 1.
[cont-init.d] 04-confd-layers: executing...
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[307]: INFO Backend set to env
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[307]: INFO Starting confd
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[307]: INFO Backend source(s) set to
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[307]: INFO Target config /usr/lib/fr24/public_html/layers.js out of sync
2021-04-08T15:20:30+02:00 96cd3b1a0b77 /opt/confd/bin/confd[307]: INFO Target config /usr/lib/fr24/public_html/layers.js has been updated
[cont-init.d] 04-confd-layers: exited 0.
[cont-init.d] 05-upintheair: executing...
[cont-init.d] 05-upintheair: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
Thu Apr 8 15:20:31 2021 CEST dump1090-fa v5.0 starting up.
rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
[main][i]FR24 Feeder/Decoder
[main][i]Version: 1.0.18-5/generic

[main][i]Built on Mar 4 2016 16:26:55 (devel-d11ca48.git/Linux/x86_64)
[main][i]Copyright 2012-2016 Flightradar24 AB
[main][i]http://flightradar24.com
[main][i]DNS mode: LIBC

FR24 Feeder/Decoder usage:
/fr24feed/fr24feed/fr24feed --fr24key=0123456789ABCDEF| Start feeding process manually
/fr24feed/fr24feed/fr24feed --signup | Sign up and configure
/fr24feed/fr24feed/fr24feed --reconfigure | Change configuration
/fr24feed/fr24feed/fr24feed --version | Show binary version number

s6-svscanctl: fatal: unable to control /var/run/s6/services: supervisor not listening
s6-svscanctl: fatal: unable to control /var/run/s6/services: supervisor not listening
s6-svscanctl: fatal: unable to control /var/run/s6/services: supervisor not listening
s6-svscanctl: fatal: unable to control /var/run/s6/services: supervisor not listening
[cont-finish.d] executing container finish scripts...
Found Rafael Micro R820T tuner
[cont-finish.d] done.
[s6-finish] waiting for services.
rtlsdr: tuner gain set to 49.6 dB
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

Seems no matter which keys I do use during startup, in the end it kills itself anyway

Steps to Reproduce the Problem

1.Pulled thomx/fr24feed-piaware:latest straight from dockerhub
Configured the keys following github readme = container kills itself
Not using any extra keys, but just mapping correctly the container paths and ports = container kills itself

Specifications

• Image hash or version: latest (~Week 51 2020)
• Platform: Raspberry Pi Zero W
• Subsystem: Raspbian Buster

Expected Behavior

Inside the container fr24feed starts after it's called by "/fr24feed/fr24feed/fr24feed --signup"

Actual Behavior

bash: /fr24feed/fr24feed/fr24feed: No such file or directory
The file fr24feed exists in the subfolder ans is executable but it wont start (I am no linux expert).
Also running the "complete" image fails because fr24feed fails to start. If fr24feed is disabled then dump1090 and piaware work like they should.

Building the image on a Pi Zero is not possible (failed after running for 4 hours).

Steps to Reproduce the Problem

1.  -e "SERVICE_ENABLE_DUMP1090=false" \
    -e "SERVICE_ENABLE_HTTP=false" \
    -e "SERVICE_ENABLE_PIAWARE=false" \
    -e "SERVICE_ENABLE_FR24FEED=false" \
    thomx/fr24feed-piaware /bin/bash```
   

2. run: /fr24feed/fr24feed/fr24feed

In the fr24feed.ini I was instructed to download i see this:

bs="yes"
raw="yes"

However the fr24 manual states

raw=BOOL - Defaults to “no” and decides whether or not the RAW data stream should be
available on port 30334 for all receivers but DVBT which uses port 30002 instead. When
using dump1090 with “--net” please disable as that feed is already provided and otherwise it
will cause conflicts.
--bs=BOOL - Defaults to “yes” and decides whether or not the Basestation compatible data
stream should be generated on port 30003. When using dump1090 with “--net” please
disable as that feed is already provided and otherwise it will cause conflicts

according to ps the image is running dump1090 with --net? Do i need to change the settings?

I just tested the new flightware-v4.0 taged docker image and panorama-ring isn't working anymore.

Specifications

• Image hash or version: flightaware-v4.0
• Platform: kubernetes & docker
• Subsystem: ubuntu 20.04

Expected Behavior

Show panorama rings on map.

Actual Behavior

Does not show the panorama rings after update to tag flightaware-v4.0.

Steps to Reproduce the Problem

1. Deploy Docker with panorama ringt -e "PANORAMA_ID=ABCDFE" use tag latest -> working
2. Deploy Docker with panorama ringt -e "PANORAMA_ID=ABCDFE" use tag flightaware-v4.0 -> not working

I moved this problem to a new issue. This is only true with new docker container using
Sun Jun 16 15:35:56 2019 CEST dump1090-fa starting up.

I am running this container on unraid without "mac-address" parameter and with empty FlightAware login data (not using fa) and filled fr24feed.ini

Flightradar24 is working good and I can reach and see everything on the fr24feed configuration panel.
When I try to reach the webui on port 8080 the layout with time and date loads, only the map is not loading and in the midlle the loading circle. I used the fresh config.js without any mods.

I see in the logs of the docker container follow beside the normal feed stuff..

192.168.178.50 - - [16/Jun/2019 15:36:20] "GET / HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /style.css?v=2 HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /jquery/jquery-ui-1.11.4-smoothness.css HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /jquery/jquery-3.0.0.min.js HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /jquery/jquery-ui-1.11.4.min.js HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /jquery/plugins/jquery.validate.min.js HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /ol/ol-4.4.2.css HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /ol/ol-4.4.2.js HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /registrations.js HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /planeObject.js?v=2 HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /ol/ol3-layerswitcher.css HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /layers.js HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /script.js?v=2 HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /ol/ol3-layerswitcher.js HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /config.js HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /markers.js HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /dbloader.js HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /formatter.js?v=2 HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /flags.js HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /spinny.gif HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /images/[email protected] HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /images/fa_logo_color.png HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /images/pa-sv-logo.png HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /images/ff-sv-logo.png HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /images/settings-icon.png HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /images/map-icon.png HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /images/table-icon.png HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /images/alt_legend_feet.svg HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /images/[email protected] HTTP/1.1" 200 -
192.168.178.50 - - [16/Jun/2019 15:36:20] code 404, message File not found
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /status.json HTTP/1.1" 404 -
192.168.178.50 - - [16/Jun/2019 15:36:20] code 404, message File not found
192.168.178.50 - - [16/Jun/2019 15:36:20] "GET /favicon.ico HTTP/1.1" 404 -

Not quite sure if this is caused because I am not using fa.

I have this issue since around 2 weeks. The log output shows the following lines repeatedly:

2020-03-26 07:28:54 | [reader][i]Connected to the receiver, configuring
2020-03-26 07:28:54 | [reader][i]Configured, processing messages
Thu Mar 26 07:28:54 2020 UTC  dump1090-fa v3.8.0 starting up.
rtlsdr: using device #0: Generic RTL2832U (Generic, RTL2832U, SN 77771111153705700)
usb_claim_interface error -6

However, connecting to the web frontend shows up some aircraft, although with type "Other" and not "ADS-B", whatever "Other" means. As a result of all this, my account on fr24 was degraded to Basic, since apparently my feeder is connected but i do not send any data. I have already double-checked whether some "real" DVB-T modules in my kernel are disabled, they are all blocked.

How is the feeder currently tracking the aircrafts? Why isn't it able to connect to the stick all of a sudden?

Just wondering why this docker uses mutability/dump1090 instead of https://github.com/flightaware/dump1090 ?

Specifications

• Image hash or version: 1.11.0
• Platform: FriendlyARM NanoPi R4S
• Subsystem: Armbian 21.08.8 Focal

Steps to Reproduce the Problem

1. Update the image and run the command as suggested in the readme file.
2. Unexpected output /run/s6/basedir/scripts/rc.init: 35: /run/s6/basedir/scripts/rc.init: /planefinder/pfclient: not found

Hi,
is it possible to implement a "range ring" like the heywhatsthat.com function, but dependent on the last logged tracks?
tar1090 has implemented that feature: https://github.com/wiedehopf/tar1090#tar1090ptracks

Issue with new update, getting the following error when launching. It was working before the upgrade.

warning: /etc/piaware.conf: failed to read config file: error reading "file3": illegal operation on a directory

piaware (process 361) is shutting down because it received a shutdown signal (SIGTERM) from the system...
piaware (process 361) is exiting...
[s6-finish] sending all processes the KILL signal and exiting.

Specifications

• Image hash or version: latest
• Platform: kubernetes
• Subsystem: ubuntu 18.04 LTS

Expected Behavior

Enabled is HTTP, FR24FEED and PIAWARE.
Conrigured as beast-tcp is a remote IP of my LAN.
FR24FEED and PIAWARE is running fine and does report aircrafts to the web.

I can access HTTP service from my browser but there is no aircrafts on the Map and the List.

In the log I can find the following:

10.32.0.1 - - [07/Sep/2020 13:01:46] "GET /data/aircraft.json?_=1599476498563 HTTP/1.1" 404 -
10.32.0.1 - - [07/Sep/2020 13:01:47] code 404, message File not found

Actual Behavior

SkyAware Map and list should show aircraft informations.

Steps to Reproduce the Problem

1. Run dump1090 an a different host in LAN (not localhost / not same docker container)
2. Configure fr24feed-piaware-dump1090 docker image to use HTTP, fr24feed and piaware.
3. Open WebGUI and try to show aircrafts on the map.

I just pulled the new image and the docker is unable to start. Do I need to rejoin to FR24 and FlightAware again or what I'm doing wrong?

I'm using a RPI 3b+ and a standard RTL2832U, everything is working good with 1.7.0

The launch command:

sudo docker run -d -p 8080:8080 -p 8754:8754 --name rtl --restart=always --device=/dev/bus/usb:/dev/bus/usb -e "FR24FEED_FR24KEY=XXXXXXXX" -e "PIAWARE_FEEDE
R_DASH_ID=XXXXXX" -e "HTML_SITE_LAT=XXXXX" -e "HTML_SITE_LON=XXXX" -e "HTML_SITE_NAME=Lasarte" -e "PANORAMA_ID=XXXXXX" thomx/fr24feed-piaware

The logs:

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 01-confd-fr24feed: executing... 
/var/run/s6/etc/cont-init.d/01-confd-fr24feed: line 23: /opt/confd/bin/confd: No such file or directory
[cont-init.d] 01-confd-fr24feed: exited 127.
[cont-init.d] 02-confd-piaware: executing... 
/var/run/s6/etc/cont-init.d/02-confd-piaware: line 18: /opt/confd/bin/confd: No such file or directory
[cont-init.d] 02-confd-piaware: exited 127.
[cont-init.d] 03-confd-html: executing... 
/var/run/s6/etc/cont-init.d/03-confd-html: line 21: /opt/confd/bin/confd: No such file or directory
[cont-init.d] 03-confd-html: exited 127.
[cont-init.d] 04-confd-layers: executing... 
/var/run/s6/etc/cont-init.d/04-confd-layers: line 3: /opt/confd/bin/confd: No such file or directory
[cont-init.d] 04-confd-layers: exited 127.
[cont-init.d] 05-upintheair: executing... 
--2022-02-10 08:04:13--  http://www.heywhatsthat.com/api/upintheair.json?id=M93W7NC1&refraction=0.25&alts=1000,10000
Resolving www.heywhatsthat.com (www.heywhatsthat.com)... 69.39.100.105
Connecting to www.heywhatsthat.com (www.heywhatsthat.com)|69.39.100.105|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/json]
Saving to: '/usr/lib/fr24/public_html/upintheair.json'

     0K .......... .......... ......                            152K=0.2s

2022-02-10 08:04:14 (152 KB/s) - '/usr/lib/fr24/public_html/upintheair.json' saved [26641]

[cont-init.d] 05-upintheair: exited 0.
[cont-init.d] done.
[services.d] starting services
Thu Feb 10 08:04:14 2022 UTC  dump1090-fa v7.1 starting up.
libcommon read_config failed - /etc/fr24feed.ini
______  _  _         _      _                    _              _____    ___ 
|  ___|| |(_)       | |    | |                  | |            / __  \  /   |
| |_   | | _   __ _ | |__  | |_  _ __  __ _   __| |  __ _  _ __`' / /' / /| |
|  _|  | || | / _` || '_ \ | __|| '__|/ _` | / _` | / _` || '__| / /  / /_| |
| |    | || || (_| || | | || |_ | |  | (_| || (_| || (_| || |  ./ /___\___  |
\_|    |_||_| \__, ||_| |_| \__||_|   \__,_| \__,_| \__,_||_|  \_____/    |_/
               __/ |                                                         
              |___/                                                          
[main][i]FR24 Feeder/Decoder
[main][i]Version: 1.0.25-3/generic
[main][i]Built on Apr  8 2020 07:06:55 (HEAD-5e8ef0c.git/Linux/static_armel)
[main][i]Running on: debian10
[main][i]Local IP(s): 172.17.0.2
[main][i]Copyright 2012-2020 Flightradar24 AB
[main][i]https://www.flightradar24.com
[main][i]DNS mode: PING

FR24 Feeder/Decoder usage:
/fr24feed/fr24feed/fr24feed --fr24key=0123456789ABCDEF| Start feeding process manually
/fr24feed/fr24feed/fr24feed --signup                  | Sign up and configure
/fr24feed/fr24feed/fr24feed --reconfigure             | Change configuration
/fr24feed/fr24feed/fr24feed --version                 | Show binary version number
[services.d] done.
s6-svscanctl: fatal: unable to control /var/run/s6/services: supervisor not listening
s6-svscanctl: fatal: unable to control /var/run/s6/services: supervisor not listening
s6-svscanctl: fatal: unable to control /var/run/s6/services: supervisor not listening
s6-svscanctl: fatal: unable to control /var/run/s6/services: supervisor not listening
[cont-finish.d] executing container finish scripts...
rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

Thanks

(removing the default issue template, as this is not really an issue report but a question/suggestion)

Would it be an idea to switch the UI from dump1090-fa to tar1090?
As you can see on https://globe.adsbexchange.com/ it does provide quite an improved UI...

(now that I've spent time working on adapting the dump1090 to add the links to FR24 in #44, maybe not the smartest to move right away to another UI, but maybe food for thought?)

I know the name is very specific but i don't think it would preclude adding another feed client as an option to the users.
(and obviously i'm not asking for a change in name ;) )

If that would be an option for you, i'd work on it and make a pull request eventually.
I wouldn't expect to add more than 20 MB of size to the image even when including an extra interface (tar1090 using data from the feed client).
The whole code wouldn't run unless people define ADSBEXCHANGE_UUID environment variable or something along those lines.

Let me know!

Seems like https://github.com/flightaware/dump1090 is the successor of dump1090-mutability?

Specifications

• Image hash or version: latest/1.3.1, contains v3.8.1 of flightaware/dump1090.
• Platform: Raspberry Pi 1B
• Subsystem: armv6

Expected Behavior

As this Docker image combines both PiAware and FR24feed, I'd expect the UI to provide not just links to FlightAware but also to FlightRadar24, and a link to the local FR24Feed page, typically http://localhost:8754/
And why not, also a link to the public pages of one's own user/tracker on both platforms so that you can easily check the health of your radar, as seen externally by those 2 tracking sites:

• https://flightaware.com/adsb/stats/user/e2jk
• https://www.flightradar24.com/account/feed-stats/?id=34513

Actual Behavior

Data upload is performed to both platforms, which is great.
But the UI elements are only FlightAware-focused

• Logos (which I don't really care about), FlightAware and PiAware/SkyAware
• Page title ("FlightAware SkyView")
• Links to the flights pages, both clicking on the flight number link or the "Visit Flight Page" button when a flight is selected:

I don't expect FlightAware to modify their version of the dump1090 package to include links to one of their competitors, though ;)
What would be the most efficient way to get these changes, would we need to fork after each stable release and add these items/ Probably better than to try to monkey-patch directly from the Dockerfile...
Any interest to work (together) on this effort? I could create a new repo that downloads the latest stable release of flightaware/dump1090 and modifies/adds these elements, would that be something you'd be interested in?

The links to the user/tracker page on both platforms could be passed on as environment variables when launching the Docker container, like is done for all the other parameters of this container.

Note: I am not professionally affiliated to any of the 2 platforms in any way, just a simple user.
I have been a FR24 user for a long time (started my first receiver in 2013, pushing only to FR24) and just recently created my FlightAware profile and pushing to FA thanks to this repo. If it hadn't been for the easy integration with the 2 platforms that is facilitated by your Docker container @Thom-x, I would likely only have continued to push data to FR24 and not FlightAware.
Just adding this in case my suggestion here would be misinterpreted ("all this hard maintenance work done by FlightAware, and this guy just wants to tag along FR24"), it is thanks to this combination that I'm now also feeding FlightAware...

Steps to Reproduce the Problem

Regular install of the Docker image.

Specifications

• Image hash or version:
• Platform: Raspberry Pi 3
• Subsystem: Raspberry Pi OS

Expected Behavior

FR24Feed and piaware to run and begin sharing

Actual Behavior

Container starts up and then shuts down. Portainer is showing the following error in the log. It repeats for every attempt to restart, it includes nothing else.

standard_init_linux.go:211: exec user process caused "exec format error"

I have included what I believe to be necessary screenshots.

Steps to Reproduce the Problem

1. Start container in Portainer
2. Monitor start progress
3. Check log for additional error reference (show above in "Actual Behavior"

Hi,

in the Skyview (http....:8080) my feeders location and center of the map is shown a few hundred meters offset.

I have the following docker export variables that should give the correct location:

HTML_SITE_LON 11.123456
HTML_SITE_LAT 48.123456

I have set my coordinates also in flightaware and fr24 and restarted everything multiple times. When i change the export variables, the map and center spot are moving accordingly. But it seems its never displayed at the exact spot i set.

The location is displayed slightly offset (~ 700 meters away from my house, on a totally different building).

Are the export variables cut to less than 6 digits after the dot ?

Hi again,
I updated yesterday and now I only get tons of these in the log.. and the webui of fr24 and the map are not working. Since it cant get the dvbt receiver, it dont send any data too.

Tue Feb 25 19:32:23 2020 CET dump1090-fa starting up.
rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
usb_claim_interface error -6
rtlsdr: error opening the RTLSDR device: Device or resource busy
2020-02-25 19:32:23 | [reader][i]Connection terminated
2020-02-25 19:32:23 | [main][i]Terminating child process 89 with SIGTERM
2020-02-25 19:32:28 | [reader][i]Connecting to DVBT receiver via (exe:///usr/lib/fr24/dump1090 --net --write-json /usr/lib/fr24/public_html/data --raw --mlat)
2020-02-25 19:32:28 | [reader][i]Connected to the receiver, configuring
2020-02-25 19:32:28 | [reader][i]Configured, processing messages
Tue Feb 25 19:32:28 2020 CET dump1090-fa starting up.
rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
usb_claim_interface error -6
rtlsdr: error opening the RTLSDR device: Device or resource busy
2020-02-25 19:32:28 | [reader][i]Connection terminated