Gap in stats at same time most days

[steve-b]

I have been feeding data using a RPi for many years with no problems that I couldn't sort out for myself. This one has got me beat, though.

For several days over the past week or so, my stats have shown a gap from 0803UTC to 0820UTC - always the same times (see screenshot taken this morning). For the past three days I have monitored my data feed during that time. The RPi reports the number of aircraft tracked and the number uploaded in the usual way, and I can filter on my feed and see the uploaded aircraft appearing on FR24. The FR24 stats page says "Online". In other words the feed is working correctly between those times, whatever the stats say.

The really odd thing is that, after doing the spell of monitoring this morning, I checked the stats page. The bar for today's date had passed the 0820 mark so I thought that the problem had not appeared today. When I checked again an hour or so later the 17-minute gap was there - it had appeared retrospectively, as it were. Now I am completely mystified, and thought I would ask here (I did raise a ticket a few days ago but no response as yet).

Has anyone seen this before?

screenshot.jpg

[EGUB55]

This is sounding very similar to my problem https://forum.flightradar24.com/foru...orting-no-data

The only difference is that my outage was from about 0800 each morning until I forced a reset of the Pi (off then on again later in the day after getting back from work). Eventually, even that wasn't working, and now I am in the situation described in my post.

EGUB55

[Oblivian]

Watch your logs during a startup sometime.

The stats are done independently from the main feeder processes. And by the looks totally different servers etc. This is the sub threads kicked off under fr24feed

fr24feed (multiple) server_master
client_handler
master_tcp
reader
mlat thread
socket_server
reconfigure thread
stats thread

Which is why they can be down while you're happily still sending stuff. Or go out of whack with daylight zone changes etc.

If you've set it up and not trying to upgrade hardware to improve. Safe to just ignore the glitches. Not much use outside that.

The feed process status on the local device is far more accurate and of use than time it gets to the remote point

[steve-b]

Watch your logs during a startup sometime.

The stats are done independently from the main feeder processes. And by the looks totally different servers etc. This is the sub threads kicked off under fr24feed

fr24feed (multiple) server_master
client_handler
master_tcp
reader
mlat thread
socket_server
reconfigure thread
stats thread

Which is why they can be down while you're happily still sending stuff. Or go out of whack with daylight zone changes etc.

If you've set it up and not trying to upgrade hardware to improve. Safe to just ignore the glitches. Not much use outside that.

The feed process status on the local device is far more accurate and of use than time it gets to the remote point

Thanks - my experience this morning confirms for me that the problem is with the stats monitoring, and not with the feed itself.

From about 0900UTC today the stats for my feeder were unavailable for about an hour, although the status remained "Online". When the stats came back, the 0803-0820 gap was there agian. Meanwhile the feed has been working normally, based on the data from the RPi and what I could see by filtering on FR24.

As long as I know it isn't a problem at my end, I'm not too bothered - I don't follow the scores on the stats page closely, but the regular gap at the same time each day made me curious.

[steve-b]

This is sounding very similar to my problem https://forum.flightradar24.com/foru...orting-no-data

The only difference is that my outage was from about 0800 each morning until I forced a reset of the Pi (off then on again later in the day after getting back from work). Eventually, even that wasn't working, and now I am in the situation described in my post.

EGUB55

I think you are right, it could well be a similar problem, but as you will see from my reply to Oblivian I don't think the problem is here so not much I can do about it.

[Warpc0il]

I had a similar issue, for a while, last year.
One thing that suggested that the problem was at their end, rather than mine, was the line on the header above the section that you screenshot that says Uptime (as % of available time) which was always 100%.
Does yours say 100% or less?

[steve-b]

I had a similar issue, for a while, last year.
One thing that suggested that the problem was at their end, rather than mine, was the line on the header above the section that you screenshot that says Uptime (as % of available time) which was always 100%.
Does yours say 100% or less?

It says 98.5% at the moment which, if you take into account that we're not quite up to 24 hours for today, is consistent with the break (which was 18 minutes today, not 17). The figure varies very slightly on each day when the break occurs, but it's below 100%.

[steve-b]

I had a response to my ticket today, which I'm not sure I understand:-

"It could be that it is checking for updates and that is where it stops sending status messages, that is why you see that gap. This is done separately than the data messages."

I'm not sure whether it is being suggested that the RPi is checking for updates or the stats process at FR24, but as we have seen there is no break in the data feed so I don't think there is anything I can do from my end. I've sent the support people a copy of the screenshot shown above just to be sure they know what I'm talking about. As long as the feed is working OK I'm not going to worry too much.

[Oblivian]

The client does to a self update check daily.

You can kill the cron job for that if you wish. (Tips here somewhere in the forum)

In finding this, (searching disable auto update) there's a number of images of stats with gaps going back as far as 2016.

So take that as you will. But obviously low pri

https://forum.flightradar24.com/forum/radar-forums/flightradar24-feeding-data-to-flightradar24/11128-how-to-disable-fr24feed_updater-sh?p=121787#post121787

[steve-b]

The client does to a self update check daily.

You can kill the cron job for that if you wish. (Tips here somewhere in the forum)

In finding this, (searching disable auto update) there's a number of images of stats with gaps going back as far as 2016.

So take that as you will. But obviously low pri

https://forum.flightradar24.com/foru...787#post121787

I wouldn't want to kill the updater unless there was a good reason to do so, but the cron job does appear to be enabled.

However, you prompted me to run apt-get update which told me there was an update from 1.0.48-0 to 1.0.51-0 available, so I went ahead and upgraded followed by a reboot for luck. Everything looks OK - Status is "Online" with the new version number shown, Tracked / Uploaded aircraft looks OK and I can filter the aircraft uploaded by my receiver.

I don't know why the cron job didn't pick up the update automatically, but anyway it's done now. It will be interesting to see if the gaps in availability cease.

[steve-b]

. . .
I don't know why the cron job didn't pick up the update automatically, but anyway it's done now. It will be interesting to see if the gaps in availability cease.

The answer is that, following the manual upgrade to 1.0.51-0, I've gone 48 hours without a break showing on the stats page. Fingers crossed this is now resolved.