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 Wolli View Post
    Exactly the same happens on my machine (Win Vista SP2). This should be fixed, although I would personally rate this bug as not critical (for my work on my machine). Regards, -Wolli-
    Same here on Win XP. Already reported that the feeder error blocks the shutdown.

    Comment


    • Windows feeder package: DUMP1090 behaviour not satisfactory

      In the recent releases of the Win feeder package (including fr24feed_win32-1.0.11-5) a version of
      -> mr-dump1090.exe
      is contained, which is not working satisfactory.
      When started "directly" (i.e. without the feeder), it shows the version number 1.10.3010.14, file length is @ 148KB.
      Although it is working well together with the feeder, it crashes, when you try to display "http://localhost:8080/" in the browser (FireFox 35.0.1).

      Consequently you can not view a nice graphical display of your feed data, like this one:
      Feeds_Graphical.gif

      Malcolm Robb's website - however - contains a dump1090 package for Windows:

      Note, although this zip contains a dump1090.exe with the same version (1.10.3010.14), the file size of this executable is just @ 116 KB.

      Using this dump1090.exe together with the feeder (by copying it from the MR-zip and renaming it to mr-dump1090.exe) also works fine with the feeder. And it does not crash when displaying "http://localhost:8080/" in the browser.

      So I suggest to include the "116KB-version" of dump1090.exe into the Windows feeder package.

      Note: Additionally, for being able to use "http://localhost:8080/" on Windows machines, the files in the package directory "public_html" (and its subdirectory "coolclock") have to be in the "UNIX format" (they are currently in the "DOS format"). For details concerning this issue, please see the forum thread http://forum.flightradar24.com/threa...lay-in-browser (problem description and - from post #14 - the solution).

      Regards, -Wolli-
      Last edited by Wolli; 2015-01-29, 13:19. Reason: added screenshot of graphical feed display

      Comment


      • I've made a new Windows build 1.0.11-6 that includes the dump1090 build mentioned above together with the HTML files, it also disables the message box when terminal is closed.

        Hope it solves Windows issues for now..

        @toString, What version of RPi do you have? Is it B+ or B? When this happens, can you see if there is no dump1090 process stuck in background? Does it work when you start it manually?

        Comment


        • It did start to work again when I restart it - sometimes. Sometimes I have to restart it twice. But then it appears to randomly stick again.

          FYI
          It's a B+
          Linux rpi 3.12.35+ #730 PREEMPT Fri Dec 19 18:31:24 GMT 2014 armv6l

          I've literally just done some commands I found online to update it:
          sudo apt-get update
          sudo apt-get upgrade
          sudo apt-get dist-upgrade

          So hopefully that is a newest version above.. I'm aware of the possible need to blacklist drivers with new distro updates, so I might need to do that, I've got that tutorial ready(!). I'm hoping all this updating will solve things though.

          Could you tell me how to tell if dump1090 is stuck in the background? The only command I'm aware of is 'ps f' but that doesn't seem to show much.

          Thanks for your help!

          Edit: Up and running again. Will see what happens in the logs.
          Last edited by toString; 2015-01-29, 16:37.
          toString - London, UK
          FR24 - T-EGLC55 / PiAware - toString / PlaneFinder - 9008
          Raspberry Pi B+ | Keedox DVB-T USB RTL-SDR [RTL2832U+R820T] | Stock Antenna

          Comment


          • Feedback to new release fr24feed_win32-1.0.11-6

            Hej Pjotr, my first experiences with the new realease are mixed.

            1 - OK: the mr-dump1090.exe included in this release, works fine. Thank you for the substitution.

            2 - NOT OK: all files in the subdirectories "public_html" and "coolclock" are still in the "DOS format". Note that in MR's zipfile I mentioned in my recent posting, these files are probably already therein (incorrectly!) in the DOS format. This won't bring the graphical display ("http://localhost:8080") to work. Consequently I did not overwrite my production directory with these files, I'm still using the old ones which I manually converted to the UNIX format some weeks ago.

            3 - NOT OK: after terminating the feeder the console window stays (still) open. Closing it manually results in a crash. Same behaviour as in release fr24feed_win32-1.0.11-5. Interesting here is, that the logfile does not contain all messages:

            Please compare the console window's contents...

            2015-01-29 19:08:29 | [main][i]FR24 Feeder/Decoder [0x02107000]
            2015-01-29 19:08:29 | [main][i]Version: 1.0.11-6/generic
            2015-01-29 19:08:29 | [main][i]Built on Jan 29 2015 15:59:23 (r:284/Windows/i386)
            2015-01-29 19:08:29 | [main][i]Copyright 2008-2015 (c) Piotr Pawluczuk
            2015-01-29 19:08:29 | [main][i]Flightradar24 AB(http://flightradar24.com)
            2015-01-29 19:08:29 | [httpd][i]Server started, listening on 0.0.0.0:8754
            2015-01-29 19:08:29 | [master][i]Starting processing thread
            2015-01-29 19:08:29 | [main][i]Reader 0 started
            2015-01-29 19:08:29 | [time][i]Synchronizing time via NTP
            2015-01-29 19:08:29 | [reader][i][0]Initializing reader
            2015-01-29 19:08:29 | [reader][i][0]Connecting to Generic receiver via (exe://mr-dump1090.exe --net --raw)
            2015-01-29 19:08:30 | [reader][i][0]Connected to the receiver, authenticating
            2015-01-29 19:08:30 | [reader][i][0]Authenticated, processing messages
            2015-01-29 19:08:34 | [time][i]Time synchronized correctly, offset -0.0123 seconds
            2015-01-29 19:08:34 | [main][i]Feed Network client started
            2015-01-29 19:08:34 | [feed][i]Downloading configuration
            2015-01-29 19:08:34 | [feed][c]Interval: 5s
            2015-01-29 19:08:34 | [feed][c]Latitude: 51.1900
            2015-01-29 19:08:34 | [feed][c]Longitude: 6.9300
            2015-01-29 19:08:34 | [feed][c]GND: YES
            2015-01-29 19:08:34 | [feed][c]NonADSB: YES
            2015-01-29 19:08:34 | [feed][c]Timestamps: optional
            2015-01-29 19:08:34 | [feed][c]Max range AIR: 350.0nm
            2015-01-29 19:08:34 | [feed][c]Max range GND: 100.0nm
            2015-01-29 19:08:34 | [feed][i]defined 1 server
            2015-01-29 19:08:34 | [feed][n]EDDL27@83.140.21.66:8099/UDP
            2015-01-29 19:08:34 | [feed][n]connecting
            2015-01-29 19:08:34 | [stats][i]Stats thread started
            2015-01-29 19:08:35 | [feed][n]connected
            2015-01-29 19:08:35 | [feed][n]switching to UDP
            2015-01-29 19:08:35 | [feed][n]working
            2015-01-29 19:08:35 | [feed][n]ping 1
            2015-01-29 19:08:35 | [feed][i]sent 1 AC in 1 packet
            2015-01-29 19:08:40 | [feed][i]sent 11 AC in 1 packet
            2015-01-29 19:08:45 | [feed][i]sent 10 AC in 1 packet
            2015-01-29 19:08:50 | [feed][i]sent 12 AC in 1 packet
            2015-01-29 19:08:51 | [reader][i][0]Connection terminated
            2015-01-29 19:08:51 | [reader][i]Terminating on request
            2015-01-29 19:08:54 | [main][i]Terminating worker threads
            2015-01-29 19:08:55 | [master][i]Terminating on request
            2015-01-29 19:08:55 | [feed][n]busy
            2015-01-29 19:08:55 | [feed][n]disconnected
            2015-01-29 19:08:55 | [feed][x]Feeding thread terminated
            2015-01-29 19:08:55 | [main][i]Terminated successfully


            ...with the contents of the logfile:

            2015-01-29 19:08:29 | [main][i]Version: 1.0.11-6/generic
            2015-01-29 19:08:29 | [main][i]Built on Jan 29 2015 15:59:23 (r:284/Windows/i386)
            2015-01-29 19:08:29 | [main][i]Copyright 2008-2015 (c) Piotr Pawluczuk
            2015-01-29 19:08:29 | [main][i]Flightradar24 AB(http://flightradar24.com)
            2015-01-29 19:08:29 | [httpd][i]Server started, listening on 0.0.0.0:8754
            2015-01-29 19:08:29 | [master][i]Starting processing thread
            2015-01-29 19:08:29 | [main][i]Reader 0 started
            2015-01-29 19:08:29 | [time][i]Synchronizing time via NTP
            2015-01-29 19:08:29 | [reader][i][0]Initializing reader
            2015-01-29 19:08:29 | [reader][i][0]Connecting to Generic receiver via (exe://mr-dump1090.exe --net --raw)
            2015-01-29 19:08:30 | [reader][i][0]Connected to the receiver, authenticating
            2015-01-29 19:08:30 | [reader][i][0]Authenticated, processing messages
            2015-01-29 19:08:34 | [time][i]Time synchronized correctly, offset -0.0123 seconds
            2015-01-29 19:08:34 | [main][i]Feed Network client started
            2015-01-29 19:08:34 | [feed][i]Downloading configuration
            2015-01-29 19:08:34 | [feed][c]Interval: 5s
            2015-01-29 19:08:34 | [feed][c]Latitude: 51.1900
            2015-01-29 19:08:34 | [feed][c]Longitude: 6.9300
            2015-01-29 19:08:34 | [feed][c]GND: YES
            2015-01-29 19:08:34 | [feed][c]NonADSB: YES
            2015-01-29 19:08:34 | [feed][c]Timestamps: optional
            2015-01-29 19:08:34 | [feed][c]Max range AIR: 350.0nm
            2015-01-29 19:08:34 | [feed][c]Max range GND: 100.0nm
            2015-01-29 19:08:34 | [feed][i]defined 1 server
            2015-01-29 19:08:34 | [feed][n]EDDL27@83.140.21.66:8099/UDP
            2015-01-29 19:08:34 | [feed][n]connecting
            2015-01-29 19:08:34 | [stats][i]Stats thread started
            2015-01-29 19:08:35 | [feed][n]connected
            2015-01-29 19:08:35 | [feed][n]switching to UDP
            2015-01-29 19:08:35 | [feed][n]working
            2015-01-29 19:08:35 | [feed][n]ping 1
            2015-01-29 19:08:35 | [feed][i]sent 1 AC in 1 packet
            2015-01-29 19:08:40 | [feed][i]sent 11 AC in 1 packet
            2015-01-29 19:08:45 | [feed][i]sent 10 AC in 1 packet
            2015-01-29 19:08:50 | [feed][i]se


            Note, that the logfile ends abruptly: it does not contain the last lines from the console window. Maybe this info will help. Regards, -Wolli-
            Last edited by Wolli; 2015-01-29, 19:47. Reason: minor corrections

            Comment


            • Hej Piotr, concerning the bug "console window does not close automatically when the feeder is terminated, crashes" (Windows) I notice the following behaviour, which may help to find the reason:

              I generally start the feeder with the option "Window mode: Start normal", i.e. after feeder start the console window is open. Motivation: watching the first console messages to be sure, that the feeder starts successfully. After some seconds (when the feeder has sent his first AC data packages to the FR24-server) I like to close the console window using "right-click" "Toggle Console".

              BUT: When I start the feeder for the first time in a new "uptime" - i.e. first feeder start after machine (re-)boot - "Toggle Console" won't work: the console window stays open. As this is a little bit annoying, I then terminate the feeder using "right-click" "Terminate Feeder".
              Now, the feeder terminates and produces a crash automatically (!).
              This behaviour occurs, as I stated, only in the first feeder session. This "first time feeder session behaviour" occurs - at least - very often; I'm not sure though, whether this happens *always*. If you like I can investigate (which will last some days though).

              From the second und subsequent feeder sessions, the "Toggle Console" function works fine, but when terminating the feeder, the console window stays open and the crash happens only, when the console window is closed manually (as described in the postings above by me and other users).

              Config here: RTL2832U dongle connected to notebook (Vista SP2), feeder fr24feed_win32-1.0.11-6 running on notebook.

              Kind regards, -Wolli-
              Last edited by Wolli; 2015-01-30, 10:21. Reason: minor corrections

              Comment


              • Originally posted by toString View Post
                It did start to work again when I restart it - sometimes. Sometimes I have to restart it twice. But then it appears to randomly stick again.

                FYI
                It's a B+
                Linux rpi 3.12.35+ #730 PREEMPT Fri Dec 19 18:31:24 GMT 2014 armv6l

                I've literally just done some commands I found online to update it:
                sudo apt-get update
                sudo apt-get upgrade
                sudo apt-get dist-upgrade

                So hopefully that is a newest version above.. I'm aware of the possible need to blacklist drivers with new distro updates, so I might need to do that, I've got that tutorial ready(!). I'm hoping all this updating will solve things though.

                Could you tell me how to tell if dump1090 is stuck in the background? The only command I'm aware of is 'ps f' but that doesn't seem to show much.

                Thanks for your help!

                Edit: Up and running again. Will see what happens in the logs.

                Well had the first night in ages where it quietly sat there and did the normal 600 seconds reconnects and didn't spazz out 50 times a minute and fill my logs!

                PHP Code:
                2015-01-30 02:23:45 | [feed][n]ping 113
                2015
                -01-30 02:24:15 | [feed][n]ping 114
                2015
                -01-30 02:24:45 | [feed][n]ping 115
                2015
                -01-30 02:25:15 | [feed][n]ping 116
                2015
                -01-30 02:25:27 | [stats][i]sent 16 bytes
                2015
                -01-30 02:25:45 | [feed][n]ping 117
                2015
                -01-30 02:26:15 | [feed][n]ping 118
                2015
                -01-30 02:26:45 | [feed][n]ping 119
                2015
                -01-30 02:27:15 | [feed][n]ping 120
                2015
                -01-30 02:27:45 | [feed][n]ping 121
                2015
                -01-30 02:28:15 | [feed][n]ping 122
                2015
                -01-30 02:28:28 | [reader][w][0]Global timeout exceeded0 msgs0 resyncsreconnecting
                2015
                -01-30 02:28:28 | [reader][i][0]Connection terminated
                2015
                -01-30 02:28:28 | [main][i]Terminating child process 3181 with SIGETERM
                2015
                -01-30 02:28:29 | [time][i]Synchronizing time via NTP
                2015
                -01-30 02:28:33 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
                2015-01-30 02:28:33 | [reader][i][0]Connected to the receiverauthenticating
                2015
                -01-30 02:28:33 | [reader][i][0]Authenticatedprocessing messages
                2015
                -01-30 02:28:36 | [time][i]Time synchronized correctlyoffset -0.0028 secondsdrift -0.0000 seconds/minute
                2015
                -01-30 02:28:45 | [feed][n]ping 123
                2015
                -01-30 02:29:16 | [feed][n]ping 124
                2015
                -01-30 02:29:46 | [feed][n]ping 125
                2015
                -01-30 02:30:16 | [feed][n]ping 126
                2015
                -01-30 02:30:46 | [feed][n]ping 127
                2015
                -01-30 02:31:16 | [feed][n]ping 128
                2015
                -01-30 02:31:46 | [feed][n]ping 129
                2015
                -01-30 02:32:16 | [feed][n]ping 130
                2015
                -01-30 02:32:46 | [feed][n]ping 131
                2015
                -01-30 02:33:16 | [feed][n]ping 132
                2015
                -01-30 02:33:46 | [feed][n]ping 133
                2015
                -01-30 02:34:16 | [feed][n]ping 134
                2015
                -01-30 02:34:46 | [feed][n]ping 135
                2015
                -01-30 02:35:16 | [feed][n]ping 136
                2015
                -01-30 02:35:27 | [stats][i]sent 16 bytes
                2015
                -01-30 02:35:46 | [feed][n]ping 137
                2015
                -01-30 02:36:16 | [feed][n]ping 138
                2015
                -01-30 02:36:46 | [feed][n]ping 139
                2015
                -01-30 02:37:16 | [feed][n]ping 140
                2015
                -01-30 02:37:46 | [feed][n]ping 141
                2015
                -01-30 02:38:16 | [feed][n]ping 142
                2015
                -01-30 02:38:36 | [time][i]Synchronizing time via NTP
                2015
                -01-30 02:38:40 | [time][i]Time synchronized correctlyoffset -0.0023 secondsdrift 0.0000 seconds/minute
                2015
                -01-30 02:38:46 | [feed][n]ping 143
                2015
                -01-30 02:38:49 | [reader][w][0]Global timeout exceeded0 msgs0 resyncsreconnecting
                2015
                -01-30 02:38:49 | [reader][i][0]Connection terminated
                2015
                -01-30 02:38:49 | [main][i]Terminating child process 3184 with SIGETERM
                2015
                -01-30 02:38:55 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
                2015-01-30 02:38:55 | [reader][i][0]Connected to the receiverauthenticating
                2015
                -01-30 02:38:55 | [reader][i][0]Authenticatedprocessing messages
                2015
                -01-30 02:39:16 | [feed][n]ping 144
                2015
                -01-30 02:39:47 | [feed][n]ping 145
                2015
                -01-30 02:40:17 | [feed][n]ping 146
                2015
                -01-30 02:40:47 | [feed][n]ping 147
                2015
                -01-30 02:41:17 | [feed][n]ping 148
                2015
                -01-30 02:41:47 | [feed][n]ping 149
                2015
                -01-30 02:42:17 | [feed][n]ping 150
                2015
                -01-30 02:42:47 | [feed][n]ping 151
                2015
                -01-30 02:43:17 | [feed][n]ping 152
                2015
                -01-30 02:43:47 | [feed][n]ping 153
                2015
                -01-30 02:44:17 | [feed][n]ping 154
                2015
                -01-30 02:44:47 | [feed][n]ping 155
                2015
                -01-30 02:45:17 | [feed][n]ping 156
                2015
                -01-30 02:45:28 | [stats][i]sent 16 bytes
                2015
                -01-30 02:45:47 | [feed][n]ping 157
                2015
                -01-30 02:46:17 | [feed][n]ping 158
                2015
                -01-30 02:46:47 | [feed][n]ping 159
                2015
                -01-30 02:47:17 | [feed][n]ping 160
                2015
                -01-30 02:47:47 | [feed][n]ping 161
                2015
                -01-30 02:48:17 | [feed][n]ping 162
                2015
                -01-30 02:48:37 | [feed][n]disconnected
                2015
                -01-30 02:48:37 | [feed][n]waiting 5 seconds
                2015
                -01-30 02:48:40 | [time][i]Synchronizing time via NTP
                2015
                -01-30 02:48:42 | [feed][n]EGLC55@83.140.21.66:8099/UDP
                2015
                -01-30 02:48:42 | [feed][n]connecting
                2015
                -01-30 02:48:43 | [feed][n]connected
                2015
                -01-30 02:48:43 | [feed][n]switching to UDP
                2015
                -01-30 02:48:43 | [feed][n]working
                2015
                -01-30 02:48:43 | [time][i]Time synchronized correctlyoffset -0.0030 secondsdrift -0.0000 seconds/minute
                2015
                -01-30 02:49:10 | [reader][w][0]Global timeout exceeded0 msgs0 resyncsreconnecting
                2015
                -01-30 02:49:10 | [reader][i][0]Connection terminated
                2015
                -01-30 02:49:10 | [main][i]Terminating child process 3186 with SIGETERM
                2015
                -01-30 02:49:13 | [feed][n]ping 1
                2015
                -01-30 02:49:16 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
                2015-01-30 02:49:16 | [reader][i][0]Connected to the receiverauthenticating
                2015
                -01-30 02:49:16 | [reader][i][0]Authenticatedprocessing messages
                2015
                -01-30 02:49:43 | [feed][n]ping 2
                2015
                -01-30 02:50:13 | [feed][n]ping 3
                2015
                -01-30 02:50:43 | [feed][n]ping 4
                2015
                -01-30 02:51:13 | [feed][n]ping 5 
                Not sure if it's luck, or by updating my Pi as per the commands in the quote above...
                toString - London, UK
                FR24 - T-EGLC55 / PiAware - toString / PlaneFinder - 9008
                Raspberry Pi B+ | Keedox DVB-T USB RTL-SDR [RTL2832U+R820T] | Stock Antenna

                Comment


                • @Wolli, try this version http://feed.flightradar24.com/window...2-1.0.11-7.zip it should terminate.. tested on Win 8.1 and I converted line endings to LF only in all files but the web interface doesn't seem to work anyway.

                  Comment


                  • Originally posted by piopawlu View Post
                    @Wolli, try this version http://feed.flightradar24.com/window...2-1.0.11-7.zip it should terminate.. tested on Win 8.1 and I converted line endings to LF only in all files but the web interface doesn't seem to work anyway.
                    I would if I could, but your weblink unfortunately delivers a "404 - Not found" (also the one on website http://feed.flightradar24.com/windows/).

                    Comment


                    • Please try again.. I do it every time,, wrong file name

                      Comment


                      • Originally posted by piopawlu View Post
                        Please try again.. I do it every time,, wrong file name
                        Yeah, three times now. This will cost you an after-work drink in Nordic's Ice Bar, when I'm in Stockholm again.

                        Got the new release and will do some tests. Hej då, -Wolli-

                        Comment


                        • Piotr, I performed the following test sequence with fr24feed_win32-1.0.11-7:

                          1) Backup of old production directory, then overwrote production directory with all files of the new release. A quick look at some files in the production directory's subdirectory "public_html" showed they are (still) in DOS format (my editor tells me so, I believe him). Leave all files (for the moment) unchanged.

                          2) Booted the machine.

                          3) Started the feeder ("first startup after boot", as described in my above posting #408). Feeder started correctly and began to send AC data. "Right-click" "Toggle Console" did not close the console window (same behaviour like in posting #408).
                          "Right-click" "Terminate Feeder". Feeder ran down, last line in console window: "2015-01-30 21:09:00 | [main][i]Terminated successfully".
                          I see this line now also in the logfile, very good. Seems you perform some message buffer flushing now.
                          But the console window remains still open (like in posting #408). Closing it manually results in a crash (like in posting #408). Screencopy of crash window:

                          WHAT THE HELL is happening with the attachments? The upper one was visible for hours. Now it's gone! Second attempt:
                          CRASH.gif
                          Closed the crash window. Task Manager shows that both processes (feeder and mr-dump1090) are gone.

                          4) Started the feeder again ("second start", see posting #408). Console window open. Feeder started and sent AC data.
                          "Toggle Console": console window closes. Again "Toggle Console": console window is displayed. (same behaviour as in posting #408).
                          "Right-click" "Terminate Feeder". Feeder terminates correctly, console window is closed automatically, no crash. Happy!

                          5) Started the feeder again ("subsequent start", see posting #408). Console window open. Feeder started and sent AC data.
                          "Toggle Console": console window closes. Again "Toggle Console": console window is displayed. (same behaviour as in posting #408).
                          Opened new browser window, URL "http://localhost:8080/". Showed rubbish/incomplete display, not usable (as assumed in step 1). Closed this browser window. Terminated the feeder. Feeder ran down. Console window still open. Terminated the feeder. Feeder ran down. Console window still open. Closing it manually results in a crash (like in posting #408)

                          6) Repeated Start Feeder / Terminate Feeder several times. Feeder always started correctly and ran down after terminating. One time automatic close of console window and automatic crash. The remaining attempts the console window stayed open, manual close resulted in crashes.

                          Summary: What makes me nervous: one time no crash, one time automatic crash, remaining times manual close and crash. One should think that the behaviour is always the same (i.e. some systematical behaviour), but not in this case. Hard to track. Welcome to Microsoft Windows! I will do some more testing on weekend (hopefully) and let you know about the results. Till then, have a nice weekend, -Wolli-
                          Last edited by Wolli; 2015-01-31, 22:50. Reason: AGAIN UPLOAD of screenshot!!!

                          Comment


                          • more testings of fr24feed_win32-1.0.11-7

                            Hi Piotr, today I performed some more tests with this release. As in the yesterday tests the results were mixed, I decided to do some tests this time with the setting "Window mode: start hidden". Motivation: as yesterday results with "Window mode: start normal" were frustrating due to non-systematical behaviour, I was interested in the feeder's behaviour with the "start hidden" option. Maybe - so I thought - we have no problems here. So I configured the feeder with "Start hidden" and booted the machine, then run some test sequences. Here the results:

                            1) "first feeder run after boot":
                            Feeder started and opened the console window. Console window stayed open (mmmh??? - actually it should not have been stayed open, due to the config "start hidden"..). However, feeder began its work correctly an sent AC data. Now "Right click" "Terminate feeder". Feeder terminated and closed the console window automatically. No crash. OK and as desired.

                            2) "second feeder run after boot"
                            Feeder started and opened the console window. A fraction of a second later the feeder closed the console window automatically. According to setting this time. After a dozen or so seconds "right click" "Terminate Feeder". Console window opened (mmmh? settings are not in this way...), the usual terminating messages were displayed. Console window stayed open. Manual close of console window resulted in crash.

                            3) "subsequent feeder runs after boot"
                            Behaviour - in general - similar (not equal!) to "second feeder run after boot": After feeder start, the console window was always displayed for a fraction of a second, then automatically closed, and the feeder obviously began its work.
                            "Right click" "Terminate Feeder" showed - in all testing sequences - the following behaviour: console window opened (mmh???), the usual terminating massages were displayed, feeder terminated its work, console window stayed open, no automatic close of console window. Manual close of console window resulted in crash.
                            BUT: In some - not all! - of these subsequent feeder sessions, after manual close of the console window and the display of the crash window, the OS displayed the following note in the lower right corner of the desktop (please see Screenshot):

                            Second attempt to post the screenshot (the first was visible only for 10 minutes or so):
                            DEP.gif
                            Rough translation: "feeder was closed by the Data Execution Prevention (DEP)" (in German: "Datenausführungsverhinderung"). Well, actually the feeder was closed by me myself, not by the OS!?! So this message confuses me somewhat (well, Windows is often confusing users, in so far not a real surprise). However, the message appeared. As I know absolutely nothing about the "DEP", I nevertheless detected a wikipedia article about DEP. Maybe this can help?

                            Momentarily I am "out of ideas", which additional tests could be performed in order to find the reason for the crashes. Maybe I should install an old release and perform similar tests with that. Any suggestions? Regards, -Wolli-
                            Last edited by Wolli; 2015-01-31, 22:27. Reason: second upload of attachment the first disappeard for resons I don't know

                            Comment


                            • DOS/UNIX format of files in directories "public_html" and "coolclock"

                              Piotr, the files you delivered in fr24feed_win32-1.0.11-7 within the above mentioned directories seem to be obviously corrupt.

                              I don't know what you did there and how you did it (surely in best intention). However, the files are... best for the trash can.

                              Just - for example - have a look (using a plain editor) into the file
                              -> public_html/script.js

                              In your fr24feed_win32-1.0.11-7 release I see the first two lines:
                              // Define ou global vaiables
                              va GoogleMap = null;


                              In both lines the letter "r" is missing. While in the first line this is no problem (as it is JavaScript comment), in the second line this is an unvalid statement, as it should read "var GoogleMap = null;"

                              No wonder that "http://localhost:8080" does not work.

                              Correctly the first two lines should read:
                              // Define our global variables
                              var GoogleMap = null;


                              Regards, -Wolli-

                              P.S.: The number of drinks for me in the Ice Bar put on your bill increased to two.
                              Last edited by Wolli; 2015-02-01, 00:50. Reason: minor corrections

                              Comment


                              • Yeah,, sed replace must have stripped "r" rather than "\r" which I was going for. Even if I don't understand why the LF/CRLF would make any difference for JS/HTML code... I will make yet another build tomorrow.. but it's difficult to fix the crash problem not being able to reproduce it in any way...

                                Thanks for your feedback.. I will read it more throughly tomorrow at work.

                                Comment

                                Working...
                                X