Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 44

Thread: DUMP1090 on Windows: no map display in browser

  1. #11
    Flight attendant Wolli's Avatar
    Join Date
    Dec 2014
    Location
    Germany
    Posts
    82
    @F-EGLF1: Ben, you're right. I tried this already, also "--net-http-port 8081" and then in the browser "http://localhost:8081". Same result.

    @obj: A good idea, thank you very much indeed. I looked up in FireFox's Web Console and found this (please see Screenshot):
    JS-ERROR.gif
    Definitely JS errors, as you can see. In my experience: the more errors occur, the more simple is the reason for the error - at least in most cases. BTW: JS is, of course, enabled in the browser.
    It seems to me, that the error displayed at the bottom ("initialize is not defined") may lead to a solution. Maybe I can fix it, but I'm not too optimistic though...
    Last edited by Wolli; 2014-12-29 at 14:40.

  2. #12
    Passenger
    Join Date
    Nov 2014
    Posts
    31
    Have you made any modifications to config.js? If you introduced a syntax error there, that would explain most of those errors.

  3. #13
    Flight attendant Wolli's Avatar
    Join Date
    Dec 2014
    Location
    Germany
    Posts
    82
    Quote Originally Posted by obj View Post
    Have you made any modifications to config.js? If you introduced a syntax error there, that would explain most of those errors.
    No modifications. All files are original, taken out of the zipfile I mentioned in my 1st posting.

    However, I'm watching an interesting effect, that I've never seen before:
    When I see the "white window" (which you can see in the screenshot of my 1st posting), I displayed - just for interest - the source code by "right click->show source code" (in German "Seitenquelltext anzeigen") of the "white window". What I see is - as expected - the same source code as it can be seen when opening the file "gmap.html" (this is the only html-file contained in the zip). BUT: at the end of the file additional code is added, which is identical to the last lines of the source code.

    To make it more clear, see the following screen shot of FireFox's "display source code":
    SourceCodeDisplay.gif
    Note, that the last four lines appear twice (!), and the first of the repeated 4 lines appears as a fragment! This happens not just to the html file, but also to all (!) JS-files contained in the zipfile. No wonder, that they produce errors!
    To make it clear: but when I open the file(s) with a plain text editor, I do *not* see the additional four lines. Strange, eh?

    I've never seen such an effect before. But I will perform more investigations concerning this effect and will make a further posting about the results.
    Last edited by Wolli; 2014-12-29 at 20:47.

  4. #14
    Flight attendant Wolli's Avatar
    Join Date
    Dec 2014
    Location
    Germany
    Posts
    82

    Problem solved: now running!

    I have found the reason for that "bug", described in my 1st posting: I have now converted all files in the subdirectory "public-html" and its subdirectory "coolclock" from the DOS text format into the UNIX text format and now it's running as supposed to be, look here:
    NowRunning.gif

    An open question for me is now, why the files contained in the zipfile were originally - obviously - in the DOS text format. I downloaded the zipfile from Malcolm Robb's website straight into a new folder on my local HD drive and extracted the files using the Windows built-in ZIP tool. This was obviously the BIG mistake. Had I used WinZip for extracing, I would have had probably absolutely no problems.

    However: thank you all for your friendly support. Kind regards, and have Happy New Year, -Wolli-

  5. #15
    Passenger
    Join Date
    Nov 2014
    Posts
    31
    Yeah, sounds like some serious weirdness in dump1090's internal webserver, I really don't trust that code at all.

    From a quick skim the only way I can see this happening is if stat() is returning a too-large size for the file on disk. dump1090 doesn't actually check the return value of read() so a short read won't be noticed and you'll get whatever happens to be hanging around at the end of the buffer from last time. No idea why stat() would be returning a different value. I wonder if Windows is doing some mangling in read() that ends up reading fewer bytes than stat reports. Silly idea of "text mode" files strikes again? Workaround would be to convert all the files to have LF endings, not CRLF.

    (I'd get you a build with a bugfix, except I have no Windows development/test environment and frankly no desire to set one up!)

    edit: snap, I see you worked it out yourself

  6. #16
    Passenger
    Join Date
    Nov 2014
    Posts
    31
    I created a pull request for this bug here: https://github.com/MalcolmRobb/dump1090/pull/63

  7. #17
    First officer
    Join Date
    Feb 2014
    Location
    Aldershot, Hampshire. UK
    Posts
    262
    Quote Originally Posted by Wolli View Post
    I have found the reason for that "bug", described in my 1st posting: I have now converted all files in the subdirectory "public-html" and its subdirectory "coolclock" from the DOS text format into the UNIX text format and now it's running as supposed to be,
    Wolli,
    Fantastic detective work, thank you.
    I loaded each file into notepad and did a save-as but changed the encoding from ANSI to Unicode,
    I had to do this for each .js file and the .css file.
    The other thing I noticed was that under win7 the security setting when you opened the properties dialog was set to blocked for most of the .js files, however selecting unblock and restarting did not help, it only worked after changing the encoding.
    I also tried a new installation using WinZip, however that did not work either.(the encoding was still wrong)
    It looks like the files had the wrong encoding from the start.
    Again many thanks for solving the mystery.
    Ben.
    FR24 F-EGLF1, Blitzortung station 878, OGN Aldersht2, PilotAware PWAldersht, PlanePlotter M7.

  8. #18
    Flight attendant Wolli's Avatar
    Join Date
    Dec 2014
    Location
    Germany
    Posts
    82
    Quote Originally Posted by F-EGLF1 View Post
    ...I also tried a new installation using WinZip, however that did not work either.(the encoding was still wrong)
    It looks like the files had the wrong encoding from the start....
    Ah. So this sounds as if the html/css/js-files contained in the zipfile are already in the Windows/DOS text file format (i.e. with CR+LF at the end of each line). OK, good to know. So Windows users should check after extracting, whether these files are in the UNIX format (i.e. line separator is just LF) or in DOS/Windows format (line separator is CR+LF). They have to be in the UNIX format, otherwise problems like the one I noticed (in my 1st posting) may occur.

    Thread readers not familiar with this rather technical matter may have a look at the Newline article in wikipedia, especially the sections "History" and "Common problems", to understand what it's all about, and the section "Conversion utilities" to see, how to convert a text file into the UNIX text file format. I myself use the text editor PFE for plain text editing for about 20 years now (which has also the mentioned conversion feature).
    Last edited by Wolli; 2014-12-30 at 10:12.

  9. #19
    First officer
    Join Date
    Sep 2013
    Location
    Farnborough, UK
    Posts
    204
    i was looking a the firefox debug and noticed the the JS errors too, the weird thing is if you double click the gmap.html directly the page will load with the map displayed.

    So it must be the way dump1090 uses the files.
    T-EGLF8

  10. #20
    Passenger
    Join Date
    Nov 2014
    Posts
    31
    Quote Originally Posted by SpaxmoidJAm View Post
    i was looking a the firefox debug and noticed the the JS errors too, the weird thing is if you double click the gmap.html directly the page will load with the map displayed.

    So it must be the way dump1090 uses the files.
    It is a bug in how the dump1090 internal webserver serves the static files, on Windows only - see my post above.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •