Any idea what that means?
My device works without issues, also the network from there is working.
I used the search here but find posts from 2016 only.
I assume there’s nothing i need to do, or?
Any idea what that means?
My device works without issues, also the network from there is working.
I used the search here but find posts from 2016 only.
I assume there’s nothing i need to do, or?
Well, that message is an issue, so how can you say that you have “no issues”?
If you are connecting over WiFi, do a WiFi sweep with a smartphone (for example use WiFi Analyzer), maybe a new router appeared around you and packet collisions makes you lose samples. You can then try to change the channel, but in my experience the 2.4GHz band is super crowded.
Because others feed sites do not see it. In addtion my stats on FA at the given time are normal.
I did not change anyhting after approx an hour the error went away
It’s (unfortunately) fairly normal to get some level of UDP loss. It may be happening elsewhere on the route between your system and FlightAware’s servers, out of your control. mlat will still function with some packet loss (just not quite as well, obviously)
Seems to be a bit of a problem again
The fifth Site 69773 is not located here and use a different service provider.
(37955 is not a problem)
Pingplotter shows no obvious path problems from here and 100% return from Flightaware.com
Any idea where the problem may be?
S
In my experience: not worth to worry about
It’s really hard to track down.
In the thread MLAT not synchronised but connected?
…I had similar symptoms, but can’t say for sure if it was the same root cause.
My theory was that I got stuck on a port at 70.42.6.224 that started to misbehave
Whatever the cause, the following approach resolved the issue for me:
Thanks @obj I have rebooted my pi for site 117925 around 11:17 and have not seen the loss of UDP messages since. The only difference appears to be I am now connecting to a different port.
Using UDP transport to 70.42.6.224 port 11700
To expedite matters I’ll just reboot my other site and hopefully the issue will be resolved.
UPDATE:
Both sites now behaving correctly. No loss of UDP messages. All seems fine.
I did observe at the time, though I didn’t mention it, that the graphs1090 showed a steady increase in memory utilization, almost as if each time there was an anomaly reported (in my case the log also showed a reconnection) the memory leaked very slightly.
Suggest you just reboot and see what happens