Archived: Feed issues with 19-2

[JohnSunnyhills]

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

[m33as]

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!

[Oblivian]

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.

/Gunnar

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

[m33as]

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.

/Gunnar

[Oblivian]

Hi all, I must admit, (as a not very confident user) that I don't understand what they really did with 19-2... all I know, I re-downloaded/installed the fr24feed through repo.feed.flightradar24... So I see it installed dump1090-mutability in /usr/bin. But when I run fr24feed-status, I get:

[ ok ] FR 24 Feeder/Decoder Process: running
[ ok ] FR 24 Stats Timestamp...
[ ok ] FR 24 Link: connected [TCP]
[ ok ] FR 24 Radar: <ID>
[ ok ] FR 24 Traced AC: .
[FAIL] Receiver: down ... failed !
[FAIL] FR24 MLAT: not running ... failed!

And I don't quite know (nor understand) why the receiver is down, or fails? What could this be?

Thanks for any hints! Sorry for yet posting again Oblivian - but I honestly don't get it.

Out of the box, users who chose DVBT (or the Pi24 image )stick as a receiver previously set off 2 things in the software. Install, and then Start Dump1090 on-demand, and then connect to that dump1090 and send the data (as outlined in my FAQ)

The 19-2 script Removed Dump1090-MR - Which was being used by anyone with 'DVBT Stick' set as receiver type in the config. = instant fail
At the same time Added Dump1090-Mutability
- Did not reconfigure itself to use it or set it to auto-start (the connector part of the decoding process to actually initialize the DVBT)

So ABCDs methods, Depending on user requirements work well. But everyone has to do basic checks beforehand to see which of the causes is in effect

There are so many combinations of setup, some users may find:
2 copies of Dump1090 left behind/running and locking the USB stick (any attempt to start FR24feed again would fail unless changed to ARTCP receiver)
DUmp1090-Mutability installed/running locking the USB stick (any attempt to start FR24feed again would fail unless changed to ARTCP receiver)
NO dump1090 installed
No Dump1090 auto starting

WHich is where the bit by bit diagnostics comes in https://forum.flightradar24.com/thre...ll=1#post74851

pgrep commands to look for running services and ensure they're all stopped or at a state that is expected
Not running FR24feed as a service to see errors / what happens when it starts and get Dump1090s feedback after it tries to reload it

It's the issue with automation and assuming everyone will follow the same procedure, when in reality we all like to have different feeders and setups to do other tasks on the device. So theres no 1-hit fix. But we've attempted to outline the most likely scenarios

Just a matter of people getting to know the basic commands and the flow of how the data gets from the airwaves, to the stick, to the decoder, to the uploader and which apps in the chain

[m33as]

Hi all, I must admit, (as a not very confident user) that I don't understand what they really did with 19-2... all I know, I re-downloaded/installed the fr24feed through repo.feed.flightradar24... So I see it installed dump1090-mutability in /usr/bin. But when I run fr24feed-status, I get:

[ ok ] FR 24 Feeder/Decoder Process: running
[ ok ] FR 24 Stats Timestamp...
[ ok ] FR 24 Link: connected [TCP]
[ ok ] FR 24 Radar: <ID>
[ ok ] FR 24 Traced AC: .
[FAIL] Receiver: down ... failed !
[FAIL] FR24 MLAT: not running ... failed!

And I don't quite know (nor understand) why the receiver is down, or fails? What could this be?

Thanks for any hints! Sorry for yet posting again Oblivian - but I honestly don't get it.

[elljay]

The file that runs the update cron job is in /etc/cron.d/fr24feed_updater

[Oblivian]

Thanks Oblivian. I had noticed one of my feeders was offline and followed the instructions in your post #11. I used my same .ini file when asked and no problem. This same feed to PiAware feed to FA never died. The whole deal was a bit of a hassle as this feeder is on the roof, mounted on a 15' aluminum pole with the antenna and Raspberry Pi stuffed in a 2' section of 4" ABS pipe as a radome/protection. I run 5V to the Pi up inside the ABS pipe using outdoor low voltage landscape wiring. The ABS pipe is connected to the aluminum pipe with a reducer coupling. The Pi connects to the internet via wifi. I hope this software glitch is fixed as I really do not want to have to take it down and mess with the Pi. It is just too much trouble. I suspect this was an auto-update feature. Is there a way to block updates (like in the .ini file)? I do not recall an option during installation of FR24 to disable updates. While I am good with computers, I have to cheat using the Linux command line. My other feeder has not missed a beat. I think part of that reason is that I intermittently power down the roof top Pi. My suspicion is that when I power it back up, the software looks for updates. The other Pi is virtually always on--hence the reason it never updated. Maybe I am mistaken, but this makes the most sense.

There is a file you can edit somewhere and disable the updates. Not sure where exactly it was located. Another user posted some instructions if you have a hunt (but it will return after a manual update).

Sent from my XT1092 using Tapatalk

[abcd567]

Wont re-imaging (format microSD card + Pi24 img), or (format microSD card + Raspbian img + feeder install by bash script) or (format microSD card + Piaware img + feeder install by bash script) easier and cleaner solution?

[Oblivian]

FR24feed Purge or Uninstall Commands

AKA DVBT users Fresh install after broken upgrade if you are brave (non brave should just reimage the SD card..)

*results may vary - those with other feeders using dump1090-mutability may be affected or have issues

Note down feeder location and key settings beforehand. Or backup fr24feed.ini and re apply later.

Confirm version via webpage or command - dpkg -s fr24feed | grep Version

sudo apt-get update
sudo apt-get remove -- purge fr24feed
* remove dump1090 at bottom
sudo apt-get clean

Rerun install script

( - may ask if you wish to over-write fr24feed.ini, do so)

Sudo fr24feed - confirm running and config by normal web page method.

OK? - Close down and start as service

sudo service fr24feed start
(may require reboot before/after)

Config not OK?

sudo fr24feed --signup


stop auto-update
sudo rm /etc/cron.d/fr24feed_updater




DVBT stick / Solo + Independent FR24feeders who have not performed dump1090 installs previously -
(removal/stop of newly included dump1090-mutability may be also required as suggested elsewhere - this will most certainly effect units running FA or other feeders.. you have been warned)

pgrep -l dump1090
sudo kill -9 <id of dump1090>
sudo killall dump1090-mutability
sudo apt-get remove --purge dump1090-mutability


Users of FR24feed prebuilt Image
Repeat setup instructions to burn pi24 image
https://www.flightradar24.com/build-your-own (hopefully is 18-9)

Additional step-by-step check commands

https://forum.flightradar24.com/threads/9866-FR24feed-uploader-Additional-Info?p=74851&viewfull=1#post74851

[abcd567]

I was going to ask if .14 had the web portal built in, assumming that is without the extra httpd install?

As that would have sorted antonioag95s concerns by simply re-running the bash scripted install

Yes, the web portal at :8080 came WITHOUT installing lighttpd

And did you have to do the dirmgr install? (that was removed from the linked install guide page by FR24 staff)

YES, both the dirmngr and librtlsdr0
PLUS workaround for Stretch (rtlsdr rules)

STEP-1: UPDATE
pi@raspberrypi:~ $ sudo apt-get update

STEP-2: INSTALL 2 DEPENDENCIES
pi@raspberrypi:~ $ sudo apt-get install dirmngr

pi@raspberrypi:~ $ sudo apt-get install librtlsdr0

STEP-3: INSTALL FR24FEED
pi@raspberrypi:~ $ sudo bash -c "$(wget -O - http://repo.feed.flightradar24.com/install_fr24_rpi.sh)"

#WORKAROUND (ONLY FOR RASPBIAN STRETCH)
pi@raspberrypi:~ $ sudo wget -O  /etc/udev/rules.d/rtl-sdr.rules "https://raw.githubusercontent.com/osmocom/rtl-sdr/master/rtl-sdr.rules"

[abcd567]

FRESH INSTALL OF fr24feed 1.0.19-2 ON RASPBIAN STRETCH (NOT UPDATE OF EXISTING FEEDER)

FR24-1.0.19-2-map.png FR24-1.0.19-2-status.png FR24-1.0.19-2-settings.png

[mbirth]

sudo bash -c "$(wget -O - h**p://repo.feed.flightradar24.com/install_fr24_rpi.sh)"

It installs dump1090-mutability_1.14, instead of dump1090-mr
Please scroll-down and see code lines in red below

# Download and install dump1090-mr
[COLOR="#FF0000"]wget -O /tmp/dump1090-mutability_1.14_armhf.deb h**ps://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[/COLOR]

But why can't that package be included in the repo and set as a dependency for fr24feed? Maybe even with a symlink from /usr/lib/fr24/dump1090 ... that way, a simple update of the (previous) default installation wouldn't break anything.

[abcd567]

SUCCESSFUL FRESH INSTALLATION OF fr24feed 1.0.19-2 ON RASPBIAN STRETCH

SCROLL DOWN TO SEE ALL STEPS

After installation, location of dump1090-mutability is /usr/bin/dump1090-mutability

[COLOR="#FF0000"]STEP-1: UPDATE[/COLOR]
pi@raspberrypi:~ $ sudo apt-get update

[B][COLOR="#FF0000"]STEP-2: INSTALL 2 DEPENDENCIES[/COLOR][/B]
pi@raspberrypi:~ $ sudo apt-get install dirmngr

pi@raspberrypi:~ $ sudo apt-get install librtlsdr0

[B][COLOR="#FF0000"]STEP-3: INSTALL FR24FEED[/COLOR][/B]
pi@raspberrypi:~ $ sudo bash -c "$(wget -O - http://repo.feed.flightradar24.com/install_fr24_rpi.sh)"

[B][COLOR="#FF0000"]STEP-4: CHECK INSTALLED VERSIONS[/COLOR][/B]
pi@raspberrypi:~ $ apt-cache policy fr24feed                                    
fr24feed:
  Installed: 1.0.19-2
  Candidate: 1.0.19-2
  Version table:
 *** 1.0.19-2 500
        500 http://repo.feed.flightradar24.com flightradar24/raspberrypi-stable armhf Packages
        100 /var/lib/dpkg/status

pi@raspberrypi:~ $ apt-cache policy dump1090-mutability
dump1090-mutability:
  Installed: 1.14
  Candidate: 1.14
  Version table:
 *** 1.14 100
        100 /var/lib/dpkg/status

[B][COLOR="#FF0000"]STEP-5: CHECK dump1090-mutability is working OK[/COLOR][/B]
pi@raspberrypi:~ $ sudo systemctl stop dump1090-mutability

pi@raspberrypi:~ $ /usr/bin/dump1090-mutability
Tue Jan 16 04:59:20 2018 EST  dump1090-mutability v1.14 starting up.
Found 1 device(s):
0: , p▒▒v, SN:  (currently selected)
usb_open error -3
[COLOR="#FF0000"]Please fix the device permissions, e.g. by installing the udev rules file rtl-sdr.rules[/COLOR]
Error opening the RTLSDR device: Permission denied

[COLOR="#FF0000"]#Above Error is given in Raspbian STRETCH. In Raspbian JESSIE, this error is not there.[/COLOR]

[COLOR="#FF0000"][B]#WORKAROUND (ONLY FOR RASPBIAN STRETCH)[/B][/COLOR]
pi@raspberrypi:~ $ sudo wget -O  /etc/udev/rules.d/rtl-sdr.rules "https://raw.githubusercontent.com/osmocom/rtl-sdr/master/rtl-sdr.rules"

--2018-01-16 05:00:59--  https://raw.githubusercontent.com/osmocom/rtl-sdr/master/rtl-sdr.rules
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.124.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.124.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5794 (5.7K) [text/plain]
Saving to: ‘/etc/udev/rules.d/rtl-sdr.rules’

/etc/udev/rules.d/r 100%[===================>]   5.66K  --.-KB/s    in 0.001s

2018-01-16 05:00:59 (5.13 MB/s) - ‘/etc/udev/rules.d/rtl-sdr.rules’ saved [5794/5794]


[COLOR="#FF0000"][B]REBOOT TO IMPLEMENT ABOVE WORKAROUND[/B][/COLOR]
pi@raspberrypi:~ $ sudo reboot


[COLOR="#FF0000"][B]STEP-6: CHECK dump1090-mutability is working OK[/B][/COLOR]
pi@raspberrypi:~ $ sudo systemctl stop dump1090-mutability                      

pi@raspberrypi:~ $ /usr/bin/dump1090-mutability
Tue Jan 16 05:03:02 2018 EST  dump1090-mutability v1.14 starting up.
Found 1 device(s):
0: Realtek, RTL2832U, SN: 00001003 (currently selected)
Detached kernel driver
Found Rafael Micro R820T tuner
Max available gain is: 49.60 dB
Setting gain to: 49.60 dB
Exact sample rate is: 2000000.052982 Hz
Gain reported by device: 49.60 dB
*5daaf183137271;
CRC: 000000
RSSI: -32.1 dBFS
Time: 2447729.50us (phase: 0)
DF 11: All Call Reply.
  Capability  : 5 (Level 2+, airborne)
  ICAO Address: aaf183
  IID         : II-00

[Oblivian]

Please don't take offence chaps, need to remove some of those posts/suggestions we come up with prior to not cause confusion to anyone else finding it.

It appears like the bash needs to be re-run for this release to do correctly and reconfigure the .ini to suit the new dependencies.

I've updated a few key threads/posts to reflect

A straight update may break if not a user of Dump1090-mutability or other feeder D1090 version already. But re running the bash looks the ticket.