Originally posted by Wolli
View Post
Announcement
Collapse
No announcement yet.
Flightradar24 decoder/feeder BETA testing (Win/RPi/Linux/OSX)
Collapse
This topic is closed.
X
X
-
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-
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-
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-
Comment
-
Originally posted by toString View PostIt 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 exceeded, 0 msgs, 0 resyncs, reconnecting
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 receiver, authenticating
2015-01-30 02:28:33 | [reader][i][0]Authenticated, processing messages
2015-01-30 02:28:36 | [time][i]Time synchronized correctly, offset -0.0028 seconds, drift -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 correctly, offset -0.0023 seconds, drift 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 exceeded, 0 msgs, 0 resyncs, reconnecting
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 receiver, authenticating
2015-01-30 02:38:55 | [reader][i][0]Authenticated, processing 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 correctly, offset -0.0030 seconds, drift -0.0000 seconds/minute
2015-01-30 02:49:10 | [reader][w][0]Global timeout exceeded, 0 msgs, 0 resyncs, reconnecting
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 receiver, authenticating
2015-01-30 02:49:16 | [reader][i][0]Authenticated, processing 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
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.
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-
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.
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
Comment