Plane Finder Client Beta2 (3.0.1435)

[Lee Armstrong]

@Lee Armstrong
Pf Client Beta2, which worked fine for few days, has stopped feeding data since 30th April. Today I purchased a new microSD Card, and made a fresh install of everything, but pfclient still not feeding data, and also does not show planes on http:<ipaddress of RPi>:30053.
The dump1090-mutability's "gmap.html" is displaying planes, and Piaware & FR24feed are successfully feeding data.
Pfclient Log says "Failed connection to all provided addresses"
Log file is attached.

Settings are:

Tcp Address 192.168.2.17
Tcp Port 30053
Poll Timeout 10000
Data Format Beast
Connection Type TCP
Aircraft Timeout 30
Latitude 43.xxxxxx
Longitude -79.xxxxxx

Port 30053 is our web server port and I think you want 30005 possibly?

 

[ab cd]

Port 30053 is our web server port and I think you want 30005 possibly?

No, I want 30053, the web server, which shows following pages:
map.html, logs.html, stats.html, setup.html
It shows all these pages, but without any aeroplanes!

 

[Lee Armstrong]

Yes but you have configured the web server to listen on port 30053 which is working but you have told the client to connect to itself on 30053 and not Dump1090 looking at the config.

 

[ab cd]

Yes but you have configured the web server to listen on port 30053 which is working but you have told the client to connect to itself on 30053 and not Dump1090 looking at the config.

Thanks a lot! What a silly mistake! now I have changed it to 30005 (Beast out in dump1090-mutability), and planes are now showing, and data is being fed to planefinder servers

2015-05-03 05:09:59.472152 Restarting due to configuration change
2015-05-03 05:09:59.797447 Client restarted successfully
2015-05-03 05:09:59.798805 TCP connection established: 192.168.2.17:30005
2015-05-03 05:10:30.440063 Successfully sent 7 aircraft updates over the past minute (2.00kb)
2015-05-03 05:11:32.960240 Successfully sent 10 aircraft updates over the past minute (2.00kb)
2015-05-03 05:12:35.372063 Successfully sent 14 aircraft updates over the past minute (3.00kb)
2015-05-03 05:12:41.589186 poll timeout occurred, restarting...
2015-05-03 05:12:41.589773 Closed TCP connection
2015-05-03 05:12:41.590103 Client restarted successfully
2015-05-03 05:12:41.591221 TCP connection established: 192.168.2.17:30005
2015-05-03 05:13:37.807677 Successfully sent 11 aircraft updates over the past minute (3.00kb)
2015-05-03 05:14:40.292101 Successfully sent 12 aircraft updates over the past minute (3.00kb)
2015-05-03 05:15:25.649188 poll timeout occurred, restarting...
2015-05-03 05:15:25.649713 Closed TCP connection
2015-05-03 05:15:25.650002 Client restarted successfully
2015-05-03 05:15:25.651122 TCP connection established: 192.168.2.17:30005
2015-05-03 05:15:42.719721 Successfully sent 8 aircraft updates over the past minute (2.00kb)
2015-05-03 05:16:45.172584 Successfully sent 11 aircraft updates over the past minute (2.00kb)

 

[xforce30164]

I've been running the Beta2 fine up untill around 22:00 GMT+2 last night, where it died, I'm not at home right now so cannot check the logs. but I'll reboot the pi via flightaware and that should restart the pfclient.
can't give any more details as I dont know why it stopped. Actually when checkking the graphs, It seems that my whole raspberry pi has crashed,
If I find out more as to why or how I'll post here.

 

[Lee Armstrong]

I've been running the Beta2 fine up untill around 22:00 GMT+2 last night, where it died, I'm not at home right now so cannot check the logs. but I'll reboot the pi via flightaware and that should restart the pfclient.
can't give any more details as I dont know why it stopped. Actually when checkking the graphs, It seems that my whole raspberry pi has crashed,
If I find out more as to why or how I'll post here.

Thanks. It will be interesting to see the logs. We've had a couple of our long running clients show up an issue that has been fixed in our development code and I would like to see if it is happening out in the field.

 

[xforce30164]

Thanks. It will be interesting to see the logs. We've had a couple of our long running clients show up an issue that has been fixed in our development code and I would like to see if it is happening out in the field.

I think it was actually just an internet connection issue for my raspberry pi at my local network at home. The graphs have been generating fine, and the log from pfclient just shows a whooooole load of:

2015-05-08 16:17:57.671172 Failed to establish a data proxy connection. Receiver data cannot be sent!
2015-05-08 16:17:57.671003 Failed to resolve remote address 'dataupload.planefinder.net' (errno: -3)

errors which I'm guessing is down to the fact that the raspberry pi had lost its network connection.

 

[Lee Armstrong]

Yes sounds about right. We should recover if the net comes back though

 

[xforce30164]

Yes sounds about right. We should recover if the net comes back though

It might be just a brainderp, but can it be the case that the pfclient shows the time in GMT (without any offset, both on the stats-console and the website?) That would explain why I thought there was a two-hour gap.

====================================================
client uploading part died again, clean logfile, this is the last entry:
(current time 22:23)

2015-05-08 20:20:15.378441 Successfully sent 210 aircraft updates over the past minute (16.00kb)
2015-05-08 20:19:12.830439 Successfully sent 211 aircraft updates over the past minute (16.00kb)

However, pfclient map view clearly shows that planes are currently being received:

Any advice on where I can look in other logfiles for more detailes why uploading fails, but the feeder itself seems to work fine?

ETA: This is my feeder near SPL/EHAM and This is my other feeder near EHEH (running old pfclient)

Edited: Here's a link to a larger piece of the log, don't know if it helps.

 

[Lee Armstrong]

It might be just a brainderp, but can it be the case that the pfclient shows the time in GMT (without any offset, both on the stats-console and the website?) That would explain why I thought there was a two-hour gap.

====================================================
client uploading part died again, clean logfile, this is the last entry:
(current time 22:23)

2015-05-08 20:20:15.378441 Successfully sent 210 aircraft updates over the past minute (16.00kb)
2015-05-08 20:19:12.830439 Successfully sent 211 aircraft updates over the past minute (16.00kb)

However, pfclient map view clearly shows that planes are currently being received:
View attachment 1939
View attachment 1940

Any advice on where I can look in other logfiles for more detailes why uploading fails, but the feeder itself seems to work fine?

ETA: This is my feeder near SPL/EHAM and This is my other feeder near EHEH (running old pfclient)

Edited: Here's a link to a larger piece of the log, don't know if it helps.

All times are UTC. Does that help make sense of it?

We did have a bug with the logging where it would appear to stop. I can't remember if it made it into beta2. The log on the file system carried on ok though.

They are stored in /var/log/pfclient but if you are seeing no gap on the sharing website then it is working ok.

 

[xforce30164]

All times are UTC. Does that help make sense of it?

We did have a bug with the logging where it would appear to stop. I can't remember if it made it into beta2. The log on the file system carried on ok though.

They are stored in /var/log/pfclient but if you are seeing no gap on the sharing website then it is working ok.

Jup, that makes sense, switched my network around a bit, (had a "client down" again this morning) insteadof ethernet-over-power adapter, now connected via network cable.
Also, weird glitch in the plane view just after reconnecting internet:

but after a reboot that was solved.

 

[Lee Armstrong]

Ah thanks. We've been trying to replicate that issue with all the planes but failed. Are you able to give us steps at all to replicate that?

 

[xforce30164]

Ah thanks. We've been trying to replicate that issue with all the planes but failed. Are you able to give us steps at all to replicate that?

Sure, What happenend in my case was:

1. PFclient functioning normally (running with dump1090-mutability), let it run for a bit with working internet connection.
2. Internet connection fails (not sure if there is a difference between disconnecting cable and the way my ethernet over power adapter fails, but just try disconnecting internet).
3. wait for a bit. (In my case there was a break of 6 hours between reconnecting internet/fixing internet connection)
4. reconnect internet
5. open plane/map view and see way to many planes . (atleast in my case).
6. rebooting raspberry pi fixes problem

(just a small note, i think it has to do with some kind of backlog/"traffic jam" of old planes that do not get removed afterwards it might be similar to the peak in the tracks you can see that dump1090 gets when you reboot the system. (because many new tracks after reboot so time interval over which those tracks were collected gets reset, see graph below for what I mean)

 

[Lee Armstrong]

Ah ok. So do you think dump1090 is feeding us those planes?

You didn't see what the time stamps on the data view said did you?

 

[xforce30164]

Ah ok. So do you think dump1090 is feeding us those planes?

You didn't see what the time stamps on the data view said did you?

The timestamp was just before the reboot, so just before the huge peak shown in dump1090. (So i don't think they are directly related as the peak happens AFTER the reboot because of the too many number of planes bug, but something similar happens for the planefeeder client when it reconnects, as if in some way, it keeps the positions of the last planes seen just before the internet connection went down, see graph below)

 

[xforce30164]

The timestamp was just before the reboot, so just before the huge peak shown in dump1090. (So i don't think they are directly related as the peak happens AFTER the reboot because of the too many number of planes bug, but something similar happens for the planefeeder client when it reconnects, as if in some way, it keeps the positions of the last planes seen just before the internet connection went down, see graph below)

Just to let you know, swapping network connection for cable seems to have fixed the crashes. I guess the ethernet over power adapter wasn't stable enough.

 

[giacomo1989]

Happened the same as @xforce30164 today! Map full of planes and feeder stopped!

 

[Lee Armstrong]

Happened the same as @xforce30164 today! Map full of planes and feeder stopped!

Got any more info for us? ;-)

 

[giacomo1989]

Got any more info for us? ;-)

My broadband connection changed public ip and this happened

 

[Lee Armstrong]

Ok thanks. That should be easy enough to simulate actually.