Announcement

Collapse
No announcement yet.

Flightradar24 decoder/feeder BETA testing (Win/RPi/Linux/OSX)

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by piopawlu View Post
    That's exactly what happens.. it will split and rotate when it's active at midnight UTC. I will add a check for last modified timestamp when writing to a log so it splits when the feeding starts. The same behaviour is true for all platforms.
    Thank you. Hej då, -Wolli-

    Comment


    • release notes / date instructions manual

      Hej Piotr, I'm sorry, two more issues:

      1) I just installed fr24feed_win32-1.0.10-6.zip (issued today) and found that the "logfile bug" (see posting #326, three postings above) is still not fixed. A minor problem actually, but due to the lack of release notes in the zipfile I don't know whether this should have been fixed with 1.0.10-6 or not. Could you please add release notes to future zipfiles?

      2) "By chance" I just noticed that a new release of the "fr24feed-manual.pdf" is online (PDF internal date 2015-01-08). I did not notice this earlier as the page http://feed.flightradar24.com/windows/ states that this manual is (still) dated 2014-10-29. Maybe you wish to update this date, occasionally.

      Kind regards, -Wolli-
      Last edited by Wolli; 2015-01-13, 18:26.

      Comment


      • 1) The logfile bug is fixed, but it does not read the contents of the logfile, it checks the latest modification timestamp. As a further improvement a rotate by size option will be added later.

        2) Yes,, I think I modified that for most platforms, must have forgotten about Windows, thanks, will fix it tomorrow.

        Comment


        • Originally posted by piopawlu View Post
          1) The logfile bug is fixed, but it does not read the contents of the logfile, it checks the latest modification timestamp. As a further improvement a rotate by size option will be added later.

          2) Yes,, I think I modified that for most platforms, must have forgotten about Windows, thanks, will fix it tomorrow.
          Reply to 1): It is - of course - up to you, in which way you make sure, that the logfile's size does not increase "beyond all borders". This has to be fixed. Not tomorrow though, but in the near future. Generally, please include release notes into the zipfile in future releases. Thank you.

          Reply to 2): Thank you.

          Hej då, -Wolli-

          Comment


          • Piotr,

            concerning the "logfile bug", as I see today, the logfile was splitted by the feeder when I started the feeder today (fr24feed_win32-1.0.10-6). I now understand your statement concerning the modification timestamp. The split is obviously performed if the feeder detects, that the day-part of the modification timestamp is not today (or is in the past, respectively). This is a nice, suitable and satisfactory solution. Thank you very much. I see the "logfile bug" now as fixed.

            Hej då, -Wolli-

            Comment


            • Would you consider a change to the license to allow redistribution of unmodified binaries? (e.g. as part of a sdcard image)

              Comment


              • @obj, I will contact you by email about it.

                Comment


                • piopawlu, if you see now my feed is suddenly offline. I'm using fr24feed_win32-1.0.10-6.
                  Internet and decoder are ok.

                  Comment


                  • When my PC goes to 'sleep' or I put it to 'sleep' - on waking up, I don't seem to pick up any aircraft... I find I have to restart to get things back to normal. The usb device is still detected etc. It's quite odd..

                    Not sure if this is my problem or something others have noticed..
                    toString - London, UK
                    FR24 - T-EGLC55 / PiAware - toString / PlaneFinder - 9008
                    Raspberry Pi B+ | Keedox DVB-T USB RTL-SDR [RTL2832U+R820T] | Stock Antenna

                    Comment


                    • Originally posted by toString View Post
                      When my PC goes to 'sleep' or I put it to 'sleep' - on waking up, I don't seem to pick up any aircraft... I find I have to restart to get things back to normal. The usb device is still detected etc. It's quite odd..

                      Not sure if this is my problem or something others have noticed..
                      This is a windows function, not the software in question. Serial devices are reset when PC is suspended/sleep so connection is severed.
                      Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                      Comment


                      • I am having problems getting the new fr24feed program to work.

                        Here is the log of how it starts up:

                        >>>>>> fr24feed Feeder version = 1.0.10-6 <<<<<<
                        [main][i]Built on 20150113-1449 (r:master-4fda2ef.git/Linux/armv6l)
                        [main][i]Flightradar24 AB(http://flightradar24.com)
                        2015-01-16 05:36:59 | [main][i]FR24 Feeder/Decoder [0x02117000]
                        2015-01-16 05:36:59 | [main][i]Version: 1.0.10-6/generic
                        2015-01-16 05:36:59 | [main][i]Copyright 2008-2015 (c) Piotr Pawluczuk
                        2015-01-16 05:36:59 | [httpd][i]Server started, listening on 0.0.0.0:8754
                        2015-01-16 05:36:59 | [main][i]Reader 0 started
                        [master][i]Starting processing thread
                        [time][i]Synchronizing time via NTP
                        2015-01-16 05:36:59 | [reader][i][0]Initializing reader
                        2015-01-16 05:36:59 | [reader][i][0]Connecting to Generic receiver via (tcp://127.0.0.1:45105)
                        2015-01-16 05:36:59 | [reader][i][0]Connected to the receiver, authenticating
                        2015-01-16 05:36:59 | [reader][i][0]Authenticated, processing messages
                        [main][i]Feed Network client started
                        [feed][i]Downloading configuration
                        2015-01-16 05:37:02 | [time][i]Time synchronized correctly, offset +0.0009 seconds
                        2015-01-16 05:37:03 | [e]HTTP Response: [HTTP/1.1 404 Not Found]
                        [feed][i]Failed on start, Sleeping 120 seconds

                        [reader][i]Terminating on request
                        2015-01-16 05:38:36 | [reader][i][0]Connection terminated
                        [feed][x]Feeding thread terminated
                        [main][i]Terminating worker threads
                        [master][i]Terminating on request
                        [main][i]Terminated successfully, restarting

                        [main][i]Built on 20150113-1449 (r:master-4fda2ef.git/Linux/armv6l)
                        [main][i]Flightradar24 AB(http://flightradar24.com)
                        2015-01-16 05:38:40 | [main][i]FR24 Feeder/Decoder [0x02117000]
                        2015-01-16 05:38:40 | [main][i]Version: 1.0.10-6/generic
                        2015-01-16 05:38:40 | [main][i]Copyright 2008-2015 (c) Piotr Pawluczuk
                        [master][i]Starting processing thread
                        [time][i]Synchronizing time via NTP
                        2015-01-16 05:38:40 | [httpd][i]Server started, listening on 0.0.0.0:8754
                        2015-01-16 05:38:40 | [main][i]Reader 0 started
                        2015-01-16 05:38:40 | [reader][i][0]Initializing reader
                        2015-01-16 05:38:40 | [reader][i][0]Connecting to Generic receiver via (tcp://127.0.0.1:45105)
                        2015-01-16 05:38:40 | [reader][i][0]Connected to the receiver, authenticating
                        2015-01-16 05:38:40 | [reader][i][0]Authenticated, processing messages
                        [main][i]Feed Network client started
                        [feed][i]Downloading configuration
                        2015-01-16 05:38:43 | [time][i]Time synchronized correctly, offset +0.0010 seconds
                        2015-01-16 05:38:44 | [e]HTTP Response: [HTTP/1.1 404 Not Found]
                        [feed][i]Failed on start, Sleeping 120 seconds

                        ************* The following sequence repeats forever *************

                        [feed][i]Downloading configuration
                        2015-01-16 05:40:44 | [e]HTTP Response: [HTTP/1.1 404 Not Found]
                        [feed][i]Failed on start, Sleeping 120 seconds



                        On the port 8754 HTTP interface, I see that fr24feed is disconnected from the link:

                        Flightradar24 Feeder/Decoder
                        Linux/generic/armv6l/1.0.10-6
                        Updated: 05:54:36 GMT-0800 (Pacific Standard Time)

                        FR24 Link: Disconnected ()
                        FR24 Radar Code: N/A
                        Aircraft Tracked (ModeS & ADS-B): 29
                        Aircraft Uploaded: N/A
                        Receiver: beast-tcp, Connected

                        I'm not sure what is wrong. The software is tracking aircraft but the data isn't being uploaded.

                        Blort

                        Comment


                        • It seems a problem with the time sync logic in the feeder appeared starting in one of the recent versions.
                          I'm currently running fr24feed_1.0.10-6 on my raspberry but I might have seen that problem around revision 3 ou 4 of 1.0.10.

                          My feeder system box sits in a remote location and is powered with a (too) small solar panel/battery system.
                          The system works 24/7 in the summer months, but definitely lacks sunny hours at this time of year.

                          When the power source is too weak the raspberry shuts itself down automatically.
                          It then restarts when the battery gets fully recharged again.

                          After that the ntp daemon takes some time before getting properly synced with remote time servers.

                          The problem with the recent versions of fr24feed (that comes alive at the raspberry startup) is that, even when the ntp daemon finally gets in sync after around 20/30 minutes, it keeps 'resyncing' time, pinging BUT doesn't seem to send any data to the server, plus on my premium account page the feeder appears offline.
                          I then need to manually restart the feeder to get it back on its feet feeding again.

                          Here is a example of the log when that occurs :

                          2015-01-15 22:17:20 | [main][i]FR24 Feeder/Decoder [0x02117000]
                          2015-01-15 22:17:20 | [main][i]Version: 1.0.10-6/generic
                          2015-01-15 22:17:20 | [main][i]Copyright 2008-2015 (c) Piotr Pawluczuk
                          2015-01-15 22:17:20 | [main][i]Reader 0 started
                          2015-01-15 22:17:20 | [httpd][i]Server started, listening on 0.0.0.0:8754
                          2015-01-15 22:17:20 | [reader][i][0]Initializing reader
                          2015-01-15 22:17:20 | [reader][i][0]Connecting to Generic receiver via (tcp://192.168.2.12:30005)
                          2015-01-15 22:17:20 | [reader][i][0]Connected to the receiver, authenticating
                          2015-01-15 22:17:20 | [reader][i][0]Authenticated, processing messages
                          2015-01-15 22:17:23 | [time][i]Time synchronized correctly, offset +134812.0680 seconds
                          2015-01-15 22:17:23 | [feed][c]Interval: 5s
                          2015-01-15 22:17:23 | [feed][c]Latitude: XX.XXXX
                          2015-01-15 22:17:23 | [feed][c]Longitude: XX.XXXX
                          2015-01-15 22:17:23 | [feed][c]GND: YES
                          2015-01-15 22:17:23 | [feed][c]NonADSB: YES
                          2015-01-15 22:17:23 | [feed][c]Max range AIR: 350.0nm
                          2015-01-15 22:17:23 | [feed][c]Max range GND: 100.0nm
                          2015-01-15 22:17:23 | [feed][i]defined 1 server
                          2015-01-15 22:17:23 | [feed][n]XXXXX@83.140.21.66:8099/UDP
                          2015-01-15 22:17:23 | [feed][n]connecting
                          2015-01-15 22:17:23 | [feed][n]connected
                          2015-01-15 22:17:23 | [feed][n]switching to UDP
                          2015-01-15 22:17:23 | [feed][n]working
                          2015-01-17 11:44:20 | [time][w]Time jump detected 134813s, resynchronizing
                          2015-01-17 11:44:21 | [feed][i]removed 3 of 4 AC
                          2015-01-17 11:44:21 | [feed][i]sent 3 AC in 1 packet
                          2015-01-17 11:44:21 | [feed][n]syncing stream
                          2015-01-17 11:44:22 | [stats][e][stats][i]sent 55 bytes
                          2015-01-17 11:44:23 | [time][i]Time synchronized correctly, offset +0.0020 seconds
                          2015-01-17 11:44:51 | [feed][n]ping 1
                          2015-01-17 11:45:21 | [feed][n]ping 2
                          2015-01-17 11:45:51 | [feed][n]ping 3
                          2015-01-17 11:46:21 | [feed][n]ping 4
                          2015-01-17 11:46:51 | [feed][n]ping 5
                          2015-01-17 11:47:21 | [feed][n]ping 6
                          2015-01-17 11:47:51 | [feed][n]ping 7
                          2015-01-17 11:48:21 | [feed][n]ping 8
                          2015-01-17 11:48:51 | [feed][n]ping 9
                          2015-01-17 11:49:22 | [feed][n]ping 10
                          2015-01-17 11:49:52 | [feed][n]ping 11
                          2015-01-17 11:50:22 | [feed][n]ping 12
                          2015-01-17 11:50:52 | [feed][n]ping 13
                          2015-01-17 11:51:22 | [feed][n]ping 14
                          2015-01-17 11:51:52 | [feed][n]ping 15
                          2015-01-17 11:52:22 | [feed][n]ping 16
                          2015-01-17 11:52:52 | [feed][n]ping 17
                          2015-01-17 11:53:22 | [feed][n]ping 18
                          2015-01-17 11:53:52 | [feed][n]ping 19
                          2015-01-17 11:54:22 | [feed][n]ping 20
                          2015-01-17 11:54:22 | [stats][i]sent 16 bytes
                          2015-01-17 11:54:26 | [time][i]Time synchronized correctly, offset +0.0016 seconds, drift -0.0003 seconds/minute
                          2015-01-17 11:54:52 | [feed][n]ping 21
                          2015-01-17 11:55:22 | [feed][n]ping 22
                          2015-01-17 11:55:52 | [feed][n]ping 23
                          2015-01-17 11:56:22 | [feed][n]ping 24
                          2015-01-17 11:56:52 | [feed][n]ping 25
                          2015-01-17 11:57:22 | [feed][n]ping 26
                          2015-01-17 11:57:53 | [feed][n]ping 27
                          2015-01-17 11:58:23 | [feed][n]ping 28

                          Comment


                          • 1.0.10-3 on a RPi does not terminate properly on SIGTERM:

                            Code:
                            2015-01-18 11:20:30 | [feed][i]sent 91 AC in 3 packets
                            [main][i]Terminating on user request
                            [reader][i]Terminating on request
                            2015-01-18 11:20:34 | [reader][i][0]Connection terminated
                            [main][i]Terminating worker threads
                            [master][i]Terminating on request
                            2015-01-18 11:20:38 | [feed][n]busy
                            2015-01-18 11:20:38 | [feed][n]disconnected
                            [feed][x]Feeding thread terminated
                            [main][i]Terminated successfully
                            but the process is still running:

                            Code:
                            $ ps awuxf | grep fr24
                            fr24      2645  0.8  0.9  48052  4788 pts/1    SNl  11:19   0:01 /usr/local/fr24feed_rpi_1.0.10-3/fr24feed
                            $ gdb -p 2645
                            [...]
                            (gdb) info threads
                              Id   Target Id         Frame 
                              3    Thread 0xb6a37460 (LWP 2646) "fr24feed" 0xb6d7cee0 in read () from /lib/arm-linux-gnueabihf/libc.so.6
                              2    Thread 0xb4a01460 (LWP 2651) "stats_thread" 0xb6d59700 in nanosleep () from /lib/arm-linux-gnueabihf/libc.so.6
                            * 1    Thread 0xb6fdc430 (LWP 2645) "fr24feed" 0xb6f8be48 in pthread_join () from /lib/arm-linux-gnueabihf/libpthread.so.0
                            (gdb) thread 3
                            [Switching to thread 3 (Thread 0xb6a37460 (LWP 2646))]
                            #0  0xb6d7cee0 in read () from /lib/arm-linux-gnueabihf/libc.so.6
                            (gdb) bt
                            #0  0xb6d7cee0 in read () from /lib/arm-linux-gnueabihf/libc.so.6
                            #1  0xb6d98ae8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
                            #2  0xb6d2a2e8 in _IO_file_underflow () from /lib/arm-linux-gnueabihf/libc.so.6
                            #3  0xb6d2b5a8 in _IO_default_uflow () from /lib/arm-linux-gnueabihf/libc.so.6
                            #4  0xb6d2b454 in __uflow () from /lib/arm-linux-gnueabihf/libc.so.6
                            #5  0xb6d1ec24 in _IO_getline_info () from /lib/arm-linux-gnueabihf/libc.so.6
                            #6  0xb6d1eb70 in _IO_getline () from /lib/arm-linux-gnueabihf/libc.so.6
                            #7  0xb6d1d8c0 in fgets () from /lib/arm-linux-gnueabihf/libc.so.6
                            #8  0x00061c04 in ?? ()
                            #9  0xb6f8ac00 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
                            #10 0xb6d8b358 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
                            #11 0xb6d8b358 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
                            (gdb) thread 2
                            [Switching to thread 2 (Thread 0xb4a01460 (LWP 2651))]
                            #0  0xb6d59700 in nanosleep () from /lib/arm-linux-gnueabihf/libc.so.6
                            (gdb) bt
                            #0  0xb6d59700 in nanosleep () from /lib/arm-linux-gnueabihf/libc.so.6
                            #1  0xb6d98ae8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
                            #2  0xb6d594d0 in sleep () from /lib/arm-linux-gnueabihf/libc.so.6
                            #3  0x0004e11c in ?? ()
                            #4  0xb6f8ac00 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
                            #5  0xb6d8b358 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
                            #6  0xb6d8b358 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
                            (gdb) thread 1
                            [Switching to thread 1 (Thread 0xb6fdc430 (LWP 2645))]
                            #0  0xb6f8be48 in pthread_join () from /lib/arm-linux-gnueabihf/libpthread.so.0
                            (gdb) bt
                            #0  0xb6f8be48 in pthread_join () from /lib/arm-linux-gnueabihf/libpthread.so.0
                            #1  0x00061ec4 in ?? ()
                            #2  0x00061d58 in ?? ()
                            #3  0x00061dbc in ?? ()
                            #4  0x0000fcd8 in ?? ()
                            #5  0xb6cf0dec in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
                            #6  0xb6cd6820 in __libc_start_main () from /lib/arm-linux-gnueabihf/libc.so.6
                            #7  0x0000fc00 in ?? ()
                            Will try again with the latest release.

                            edit: Tried a few times with 1.0.10-6, couldn't reproduce it.
                            Last edited by obj; 2015-01-18, 11:32.

                            Comment


                            • What is the purpose of the "timestamper" program and how should it be run?

                              Blort

                              Comment


                              • Just a short update.. I am aware of the time sync bug and I am working on a fix,, hopefully there will be a new release tomorrow.
                                Timestamper utility is now deprecated,, it was used to put timestamps on the app output.

                                Comment

                                Working...
                                X