1.0.24-5 AMD64 error

[Saturnus]

I found out there is a new AMD64 release FINALLY. Gave it a try and despite the "Aircraft Uploaded: 0" error as discussed in the other topic, it seems to work. But still the log notes 2 errors:

Log says:

2019-11-06 11:49:52 | [e]PacketSenderConfiguration::fetch_config(): Unable to parse jsoned response
2019-11-06 11:49:52 | [d]TLSConnection::ctor(): Enable verify_peer in production code!

Not sure if the same happens on ARM, I did not upgrade that one yet.

[wiedehopf]

That's from 1.0.24-2 on armhf:

2019-11-06 15:07:29 | [e]PacketSenderConfiguration::fetch_config(): Unable to parse jsoned response
2019-11-06 15:07:29 | [d]TLSConnection::ctor(): Enable verify_peer in production code!

Typical output while running:

2019-11-06 15:09:00 | [feed][i]sent 6,72 AC
2019-11-06 15:09:05 | [feed][i]sent 9,67 AC
2019-11-06 15:09:05 | [feed][n]syncing stream async: 1
2019-11-06 15:09:06 | [feed][n]syncing stream result: 1
2019-11-06 15:09:10 | [feed][i]sent 10,70 AC
2019-11-06 15:09:10 | [mlat][i]Pinging the server
2019-11-06 15:09:10 | [mlat][i]Stats 644796/2066
2019-11-06 15:09:15 | [feed][i]sent 11,69 AC
2019-11-06 15:09:19 | [feed][i]removed 2 of 95 AC
2019-11-06 15:09:20 | [feed][i]sent 12,67 AC
2019-11-06 15:09:23 | [feed][i]removed 2 of 93 AC
2019-11-06 15:09:25 | [feed][i]sent 11,67 AC
2019-11-06 15:09:30 | [feed][i]sent 13,67 AC
2019-11-06 15:09:30 | [mlat][i]Pinging the server
2019-11-06 15:09:30 | [mlat][i]Stats 646784/1988
2019-11-06 15:09:31 | [feed][i]removed 2 of 92 AC
2019-11-06 15:09:35 | [feed][i]sent 13,65 AC
2019-11-06 15:09:36 | [feed][i]filtering out 86 overlapping AC (saving bandwidth)
2019-11-06 15:09:39 | [feed][i]removed 1 of 90 AC
2019-11-06 15:09:40 | [feed][i]sent 2,76 AC
2019-11-06 15:09:43 | [feed][i]removed 1 of 90 AC
2019-11-06 15:09:45 | [feed][i]sent 5,77 AC

[vk6xlr]

I'm getting a similar error on armhf 1.0.24-7

2019-11-21 14:03:59 | [i]PacketSenderConfiguration::on_periodic_refresh: refreshing configuration
2019-11-21 14:03:59 | [e]PacketSenderConfiguration::fetch_config(): Unable to parse jsoned response

Been happening for a few weeks now.

[wiedehopf]

That's not a "similar error". I guess it's not crashing either?

And as long as it works it works i'd say, some stray errors in the logs have always been there.

[abcd567]

I found out there is a new AMD64 release FINALLY. Gave it a try and despite the "Aircraft Uploaded: 0" error as discussed in the other topic, it seems to work. But still the log notes 2 errors:

Log says:

2019-11-06 11:49:52 | [e]PacketSenderConfiguration::fetch_config(): Unable to parse jsoned response
2019-11-06 11:49:52 | [d]TLSConnection::ctor(): Enable verify_peer in production code!

Not sure if the same happens on ARM, I did not upgrade that one yet.

I'm getting a similar error on armhf 1.0.24-7

2019-11-21 14:03:59 | [i]PacketSenderConfiguration::on_periodic_refresh: refreshing configuration
2019-11-21 14:03:59 | [e]PacketSenderConfiguration::fetch_config(): Unable to parse jsoned response

Been happening for a few weeks now.

Disable mlat, and this error will disappear.

sudo nano /etc/fr24feed.ini

Change
mlat="yes" to "no"
mlat-without-gps="yes" to "no"
Save file (ctrl+o) and close (ctrl+x)
Restart fr24feed

sudo systemctl restart fr24feed

Now check logs.

[wiedehopf]

Why would you disable MLAT to remove an error that doesn't break anything?

The error is just there, it's not an actual problem.

[abcd567]

Why would you disable MLAT to remove an error that doesn't break anything?

The error is just there, it's not an actual problem.

Yes, you are right. There is no need to disable mlat if this error does not give any problem. What I wrote was to:
(1) demonstrate that error message is related to mlat

(2) In my installs on Ubuntu & Debian, there was no uploads untill I disabled mlat. I continously get following message if mlat was enabled:

[i]Timestamp source changed from UNKNOWN to SYSTEM-UNCERTAIN
[i]Synchronizing time via NTP
[w]Failed to synchronize time, waiting 8 seconds
[i]Synchronizing time via NTP
[w]Failed to synchronize time, waiting 16 seconds
[i]Synchronizing time via NTP
[w]Failed to synchronize time, waiting 24 seconds

[SlashbNL]

After mailing with FR24 Support they told me only MLAT data is used from Raspberry Pis with dvbt dongles and their shipped receivers.

[Saturnus]

From what I read in my logs, MLAT is just working normally on 1.0.24-5.

If you just run a nice image in Docker, you don't need all those scripts, mods, init this that, etc.