AirNav Systems Forum
AirNav RadarBox and RadarBox24.com => AirNav RadarBox and RadarBox24.com Discussion => Topic started by: fossie1 on April 24, 2011, 11:44:15 AM
-
Hi All
All my routes seem to be in reverse order, is anyone else having this problem today?
Thanks
Stephen
-
Would it be the summer timetables?
-
I think it has happened since installing the new Database update.
Stephen
-
Strangely enough I have noticed that today as well with several routes.
-
Wondered when the Navdata would get the blame, if in doubt blame the Navdata. The Navdata changes amend the data held on aircraft nothing else.
A far better bet would be crap routings being put onto the server since the summer timetables came into effect. The ones I am seeing on Myflights are heading in the correct direction, wrong route possibly in some cases but the correct direction. I have been running Flight Display to update the routes and hopefully it they should settle down over time.
Alan
-
There are incorrect routes also. I am currently looking at a flight that had flown overhead, SHT12N which is actually flying EGLL - EGNT (Newcastle), but it is being displayed as EGLL- EGPF. SHT8C is currently passing on it's way to Edinburgh EGPH, it is being displayed as EGCC - EGLL. I also updated to the new navdata a couple of days ago.
-
Roland, read my reply above. Incorrect routes are not a new thing.
Alan
Alan
-
Flight just passing over heading north to cross the pond.
flight info from bangalore (VOBL) to London(EGLL) something wrong somewhere!
-
The Navdata changes amend the data held on aircraft nothing else.
Hi Alan - can you re-confirm the above please? I have resisted downloading this latest offering as the previous ones played merry hell with my routes.
Thanks.
-
Hi Bratters
Still the same answer as the last time.
Unfortunately althought the Navdata only changed aircraft data, everything else such as routes which you have that you have changed manually will be deleted, so as your route info is precious to you, dont update. Airnav didnt put any route data on the update, only the aircraft data changed and it was the same for at least the last update and possibly/probably the one before.
With the current Navdata/Airnav version, change one thing change everything and it will be this way until we get the next Airnav version.
If you want to keep your routes which you have updated/amemded manually dont update as they wil be deleted.
The routes have been a bone of contention from day one well before any Navdata updates and the changes made by airlines at the start of the summer and winter schedules dont help. They are eventaully updated in the servers as time goes by by Airnav receiving updates from the resources they use. For anyone new to the forum there are plenty of previous thread refering to routes which cover this subject.
Alan
-
Many thanks Alan - I've done tolerably well with FDL, certainly well enough that I'm not inclined to jeopardise what I've compiled.
A bit of a pain, this piecemeal approach to updating and not satisfactory IMO.
-
After the very first update, I asked AirNav if they could incorporate a question in the routine about which tables we want to update. I lose my precious Airlines table, everyone loses their routes.
I've discovered the SQLite Manager FireFox addon which allows me to re-import my old tables into the updated NavData file, but it's a pain, and a bit scary. I do wish they would address this by the next update.
Rod
-
It is a poor situation. I have just noticed flight RYR 8074 supposedly from EBCI to LIPE but actually from GMTT to EBCI. How ridiculous!! And I cant even overwrite it for following days.
Any advice on overwriting welcome.
-
The routes appear correctly in the Database Explorer but are being either reversed or completely corrupted on the display. Switching off hardware processing/network processing and restarting corrects the problem temporarily.
-
That works for me - well spotted GulfTraveller!
Rod
-
In my Radarbox the routes are all wrong. I put in my database TAP1908 as LPFR-LPPT and in Myflight screen appears as LPPT-LPFR. Other example, MON216 is EGKK-LPFR and in my Myflighjt screen appears as EGCC-EGKK.
-
Grahamteale download and install flightdisplaylight from here http://sites.google.com/site/flightdisplaylite/
This will look out for route updates and will save them into your Navdata.
Rod,
Im afraid that it is going to take a complete software re-write to allow the different Navdata tables to be done seperatly thats why we need to wait on the next version of Radarbox.
Alan
-
Alan - thanks (and no thanks ;-) for that info.
Rod
-
I have some strange route info on some blimps on my radar box just this moment around Frankfurt:
ADR117 - Routing shown: LYPR-EDDM - but has just departed in Frankfurt ?!?!?
DLH4MC - Routing shown: EYVI-EDDF - but has just departed in Frankfurt as well ?!?!?
DLH457 - Routing shown: OMDB-EDDF - but is actually coming from LAX !!!
DLH2J - Routing shown: EDDT-EDDF - but is actually coming from Brussels !!!
All these flight are receive from the network. If I turn off the network the routing information show up correctly from my local data base.
Frank
-
Yes same here I can't recall seeing one yesterday that was correct. I tried the switching on and off as suggested earlier with limited effect. I am seeing incorrect routes on both Network and my flights? I thought it was me having changed the pc was the problem.
John
-
Airnav are you out there, lets hear from you. While some routes are correct, there are some wierd routes showing out there, whats happening to your routes, it cant all be due to the summer timetable coming into effect.
For Myflights, Flight display is sorting a lot of them but even it is having problems with some.
Alan
-
Hello
There is something Very strange going on with routes here as well. One of the many examples here is KLM601. It is in my Navdata and on the Airnav database as EHAM-KLAX but it showed in myflights however as ZSDP-EHAM!!
Andrew
-
Yes, the route info problem is older than since the summer timetable change. I am complaining about this since last fall.
Classic example: DLH600 actually running from Frankfurt to Tehran is showing RJBB-EDDF since September 2010 until the recent days. In my local database I have corrected the route info. But when I turn on the network data my local data are ignorred and replace by this annoying crap coming from the airnav server.
Frank
-
And the probable response from AN:
'It will be sorted once we have finished dealing with Shiptrax !'
-
And the probable response from AN:
'It will be sorted once we have finished dealing with Shiptrax !'
no further comment needed...
-
There should at least be the possibility to suppress the route information received from the network so that the local (own compiled) database entries would be used for display.
-
sted,
There is, preferences/radarbox and untick Auto-populate route data.
Alan
-
Sorry for the late reply.
Seems to be a few issues mentioned in this thread and its hard to put in place whether they are all related.
1.) There has been the changeover to summer schedules so if you been using our data then some of these maybe out of date. We will be doing a refresh of the routes soon so new data will start to be pushed back to you (it downloads when your data on your machine is 6 months out of date)
2.) We have uploaded data from other sources recently to our online database. We will check to see whether this has been corrupted, can you also confirm its new data which is looking strange (the row will a timestamp) ?
3.) The route reversal as you mention was something seen in earlier builds and was fixed so we are bit confused to how this could be appearing again considering it hasn't been mentioned for a long while.
While we don't think the aircraft updates are the cause can the users above who have the issue tell us whether they downloaded the update and whether the issues appeared after it.
-
I've only noticed the route reversal since I did the latest update.
Rod
-
I have done no update in the past few days when the issue started to appear and, as I indicated before, the reversal and the corruptions are not present in the database I access through the explorer. Hope that helps.
-
Not sure whether it helps, but a quick check on Libhomeradar suggests the system is showing the previous sector recorded by the aircraft tracked. That would explain both the reversals and the corruptions.
-
Definately a bug in reading the navdata.db3
here is a screenshot of the heathrow approach, with ANA201 in myflights. This route has always been into Heathrow and has not changed with the summer timetable. You can see the info shown, differs from that contained in the Navdata explorer.
Many of the other aircraft visable in myflights are also corrpted.
BMA948 showing EGLL-UUUD - in DB explorer as OSDI-EGLL datestamp 20100407110623
BAW435 showing EGLL-LIMC - in DB explorer as EHAM-EGLL datestamp 20101205141406
SIA308 showing WSSS-YMML - in DB explorer as WSSS-EGLL datestamp 20101203142044
IBE3176 showing correctly as LEMD-EGLL datestamp 20101203150904
-
I'm also having this problem.
Uncheck the automatic update route and did the manual updates.
Still is showing routes to information not listed in my database.
If you do not have an urgent solution to this problem, it would be better not to have this option appearing on the label of the aircraft.
What AirNav doing to correct this problem?
Regards,
-
I can confirm that I did not have this route reversal problem prior to downloading the latest update.
-
A new navdata.db3 installation is now available:
http://www.airnavsystems.com/download/ANRB/DBUpdater/ANRBDBUpdater20110418.exe
Changes: New/Updated aircraft table;
Airnav, if as stated on the start of the d/b update thread as shown above, the only thing changed in the Navdat is the aircraft table, why are we having trouble with the routes table. Was it changed as well and you didnt advise us?
Alan
-
Hello
As yet we have not updated the Navdata on our main computer and we are having this problem too. No idea where the data is coming from as it is correct on the Navdata and the Central Airnav Database is also correct.
Andrew
-
All my observations here in Kuwait suggest that, where there is a corruption, it is showing the previous sector. Currently watching here DLH 618 (EDDF-OMAA-OOMS) as HECA-EDDF which was its previous flight. Would have thought that would lead to a quick solution. Interesting that not all flights are affected.
-
Real junk being displayed here - definitely a corruption
-
Ok, we are trying to gather the reports so far so we can pin point the cause.
Can you please reply stating whether you have used the new database updater and then seen an issue, whether the routes which are wrong have newly updated timestamp. Some of the replies are not helping at all.
-
No update here. DLH618 with previous sector showing has datestamp of 20101025.
-
If it's any help in a negative/positive sense I seem to be having no route problems.
I have NOT updated the navdata; the autopopulate routes is UNTICKED and I am NOT a Network subscriber. Flight display Lite in use, datasharing switched off.
-
That's the same what I can observe on my computer. As long as I don't use the network all route infomation are shown correctly because the route information is taken from my local route data base, which I have created myself using an SQLite Editor and libhomeradar information.
And of course my autopopulate routes is UNTICKED as well.
From the moment I turn on the network all received network received flights suddenly contain wrong route information suggesting that these route information are not taken from my local database but coming in together with the flight data.
That should be avoided by a software change!
Frank
-
I suspect these corrupted routes are coming from network aircraft. These corrupted routes then get passed into the MyFlights list when the aircraft transitions from network to hardware.
I've got network turned off, and I maintain my own routes table, and all routes look okay.
-
BA SHT18V is showing in d/b explorer as Heathrow -Aberdeen which is correct and has a timestamp of 20100817174505
Its is however showing in myflights as Heathrow-Manchester which is wrong
BAW269 is showing in d/b explorer as Heathrow-Los Angeles which is correct and has a timestamp of 2011419210033
Its is however showing in Myflights as routing Heahtrow-Hong Kong
ANZ1 is showing in d/b explorer as Heathrow-Los Angeles which is correct timestamp 20110424215603.
It is however showing on Myflights routing Auckland-Melbourne which is incorrect.
I have updated using all the Navdatas as they become available. From the 3 here chosen at random 2 new timestamps and 1 old, all showing correctly in d/b explorer but incorrectly on the screen
Alan
-
Alan, do you have network turned ON?
-
Yes Chris, I have the network on and route updates ticked,
Alan
-
Okay, I just did some more testing and I'm 99% sure this is being caused by corrupted routes being sent out on the network. Remember, when a network aircraft transitions to hardware reception, it keeps the route information from the network, it doesn't use the route from navdata routes table.
Airnav, you need to focus on fixing the route information being sent out on the network.
-
Okay, I just did some more testing and I'm 99% sure this is being caused by corrupted routes being sent out on the network. Remember, when a network aircraft transitions to hardware reception, it keeps the route information from the network, it doesn't use the route from navdata routes table.
So where do the corrupted network routes orginate tarbat?
-
So where do the corrupted network orginate tarbat?
My guess is in the server software routines that Airnav use to do route lookup on network aircraft on their central server.
-
Just got DLH4YL inbound Edinburgh from Frankfurt. D/b Explorer is blank apart from the timestamp of 201103027144912.
Myflights is showing Hamburg-Frankfurt which is wrong.
I just had a crash of Airnav and on starting up again the ANZ1 and BAW269 are now showing the correct route details
Alan
-
Alan, were they received on your local hardware BEFORE the network populated? The corrupted routes are coming from the Airnav central server, NOT from your local navdata database. But if the aircraft is received on your local hardwarw BEFORE appearing on the network, the route data is retrieved from your local navdata database.
-
Alan, were they received on your local hardware BEFORE the network populated? The corrupted routes are coming from the Airnav central server, NOT from your local navdata database. But if the aircraft is received on your local hardwarw BEFORE appearing on the network, the route data is retrieved from your local navdata database.
That's exactly what I can observe on my machine as well.
-
So where do the corrupted network orginate tarbat?
My guess is in the server software routines that Airnav use to do route lookup on network aircraft on their central server.
Well if the Airnav central server is as bad as it was when so many of us switched it off and started using FDL, then is it reasonable to assume that network flights have been showing wrong route information for ages?
(Not having Network I can't check this for myself)
-
Well if the Airnav central server is as bad as it was when so many of us switched it off and started using FDL, then is it reasonable to assume that network flights have been showing wrong route information for ages?
(Not having Network I can't check this for myself)
Using FDL doesn't change what routes get put on network flights. Turning off route population doesn't change what routes get put on network flights. The routes on network flights get sent with the flight itself from Airnav's central server. When a network flight transitions to a local flight, the corrupted route gets used.
It looks like Airnav have changed something in the software on their central server that processes network flights. It appears to be using the route data from the previous flight of the aircraft. Just my guesswork, maybe Airnav can confirm this diagnosis.
-
Glad to see that this long persisting bug gets finally nailed!
-
Yes yes I follow that but what I'm suggesting is that the airnav server has been churning out bad routes for ages, therefore this problem should not just have surfaced?
-
Hello
This isn't a long persisting bug. There have always been issues with routes but this is a separate issue that started within the last 24-48 hours.
Andrew
-
Yes yes I follow that but what I'm suggesting is that the airnav server has been churning out bad routes for ages, therefore this problem should not just have surfaced?
You're confusing the route lookup routines (that deliver route data to local PCs) and the network aircraft server routines.
I don't think the airnav server is churning out any more bad routes than normal. What this bug is about is the Airnav server assigning route data to all network flights based on the previous flight of that aircraft. Test this by:
1. Turn hardware off.
2. Turn network on.
3. See all the corrupted routes (100's).
4. Turn network off.
5. Turn hardware on.
6. See correct routes.
-
I dont know Chris, they were populated before I noted them but I would go along with what you are stating with the exception that I wouldnt agree with the previous flight data being used. Take ANZ1, its previous flight took it to Heathrow yet it is showing Auckland-Melbourne and it would have reached Heathrow from New Zealand without going to Australia, whether it went east or west.
My observation on the routes before this started is that I thought the routes were being processed quite well with the odd blip but I dont pay particular attention to them as my main priority is the aircraft itself.
Alan
-
I dont know Chris, they were populated before I noted them but I would go along with what you are stating with the exception that I wouldnt agree with the previous flight data being used. Take ANZ1, its previous flight took it to Heathrow yet it is showing Auckland-Melbourne and it would have reached Heathrow from New Zealand without going to Australia, whether it went east or west.
You may be right Alan. I was just guessing that maybe the corrupted route data was the previous flight. We need Airnav to confirm how this corruption of routes for network aircraft is happening on their server.
I suspect this response from Airnav may explain the corruption:
2.) We have uploaded data from other sources recently to our online database. We will check to see whether this has been corrupted, can you also confirm its new data which is looking strange (the row will a timestamp) ?
-
Thanks for clarification Tarbat.
However does it remain the case that if an incoming network flight displaying a wrong route transits, that wrong route will be shown in MyFlights?
-
Thanks for clarification Tarbat.
However does it remain the case that if an incoming network flight displaying a wrong route transits, that wrong route will be shown in MyFlights?
Correct. When a network flight transition to MyFlights, it keeps the same route data as was on the network. This has been confirmed by Airnav a while ago when similar problems occured.
http://www.airnavsystems.com/forum/index.php?topic=4902.msg49255#msg49255
-
We are investigating any corruption which may be occuring on our server, or whether its just the routes are out of date and need refreshing.
-
In the meantime, if end users want routes to be retrieved from your local navdata database routes table, turn the network off and just process local hardware.
-
We are investigating any corruption which may be occuring on our server, or whether its just the routes are out of date and need refreshing.
Hello
The Routes are not out of date on the server. As an example See the server data for KLM601
http://www.airnavsystems.com/cgi-bin/ANLV_SV/ANLV_SV_user.exe?usgetorgdst=0&usemail=PGANRB100001&usversion=ANRB&fnumber=KLM601
This is correct, but it showed ZSDP-EHAM in myflights this morning.
Andrew
-
The Routes are not out of date on the server. As an example See the server data for KLM601
http://www.airnavsystems.com/cgi-bin/ANLV_SV/ANLV_SV_user.exe?usgetorgdst=0&usemail=PGANRB100001&usversion=ANRB&fnumber=KLM601
This is correct, but it showed ZSDP-EHAM in myflights this morning.
Correct. It's NOT the route lookup software routines that are returning incorrect routes. It's the server software routine that populates routes into the network aircraft data stream. These appear to be completely separate software routines.
Was network turned ON? What does KLM601 show in your routes table?
-
We are checking this as I write. Stby for further news.
-
Problem found we are correcting it now.
-
Yes yes I follow that but what I'm suggesting is that the airnav server has been churning out bad routes for ages, therefore this problem should not just have surfaced?
You're confusing the route lookup routines (that deliver route data to local PCs) and the network aircraft server routines.
I don't think the airnav server is churning out any more bad routes than normal. What this bug is about is the Airnav server assigning route data to all network flights based on the previous flight of that aircraft. Test this by:
1. Turn hardware off.
2. Turn network on.
3. See all the corrupted routes (100's).
4. Turn network off.
5. Turn hardware on.
6. See correct routes.
I was fully able to replicate that. Picked up A388 UAE3 (OMDB-EGLL) With network only on it was showing on the network as KJFK-OMDB. If I then turned on hardware it appeared in myflights still with that corruption from the network. Turning both network and hardware back off, I then opened hardware only. It immediately came in as the correct OMDB-EGLL from my navdata.
-
Problem should be corrected now. Close the RadarBox software, start it again and confirm it is not happening.
-
Its looking good for me here, will know better when the network comes back up.
Alan
-
Still having the problem.
See example attached: The flight is on Gol1892 navdata.db3 with the route SBGL - SBPA, but the screen appears as RadarBox SDAM-SBGL.
Where the RadarBox is seeking this route that does not exist? SDAM is small airport that has no commercial flight.
I'm with unchecked "Auto-Populate date Routes" in the Preferences menu.
In this case no use having a correct database on the screen appears RadarBox totally wrong.
-
According to Airnav's route database, the routing displayed is the same:
http://www.airnavsystems.com/cgi-bin/ANLV_SV/ANLV_SV_user.exe?usgetorgdst=0&usemail=PGANRB100001&usversion=ANRB&fnumber=GOL1892
Remember, routes on network aircraft always come from Airnav's server, even if you have unticked "autopopuate routes". Routes on network aircraft are never taken from your local navdata database routes table.
-
Thanks for the reply tarbat!
Then, the information network of aircraft need to be updated!
Is there any preview of this update?
Many people who visit my site question this issue of the routes
-
Many people who visit my site question this issue of the routes
"Routes" have been something of a problem for a long time now. For many users they are not particularly important but for others accurate routes are an important element of using RadarBox.
The introduction of alphanumerics has added to what was already becoming a difficult area for Airnav to keep up to date. Flight Display Lite has helped but there are still a lot of gaps and I don't expect matters to improve much.
Suggestions welcome!
-
Whatever the problems with routes, at least the recent bug seems to be fixed now - so far so good.
Thanks, AirNav.
Rod
-
Watching in Kuwait, even without a restart, everything seems to be back to normal. Well done.
-
Thanks a lot. We are working hard on the background on the flight data servers and sometimes these problems might happen. Tks for all your feedback.