AirNav Systems Forum
AirNav RadarBox and RadarBox24.com => AirNav RadarBox and RadarBox24.com Discussion => Topic started by: AirNav Development on November 13, 2014, 11:55:49 PM
-
We've created a new version to correct the Alert email problem.
Upgrade: http://www.airnavsystems.com/download/anrb/ANRBUpgradeto50072.exe
Full install: http://www.airnavsystems.com/download/anrb/ANRB50072Setup.exe
Waiting for user feedback.
-
Download the upgrade. Installed and found this error when lunch
"The program can't start because adsb.dll is missing from your computer."
Reapply the upgrade ANRBUpgradeto50071.exe and the ANRB can start again.
Still haven't tried the full install. It shows 1 hr download.
Kenny
-
I tried it. It dies not work missing file
-
I get the same error:-(
-
Hi Airnav Development,
please see my posting here: http://www.airnavsystems.com/forum/index.php?topic=8218.15 and my two PMs.
Did anyone test the full install? If yes, does the problem exist there too? If not, save your time and wait until I've tested it. Full install: 300mb and quite low download speed at the moment.
Thanks Ingo.
-
Full Install has the same problem. ADSB.dll is missing.
Ingo
-
Airnav is aware of the problem and will have a look into it within the next couple of hours.
Ingo
-
Evening all downloaded full version
Does not work missing file etc
Paul
-
Hi Paul,
airnav is informed and they told me that a new download will be available within the next few hours.
Notice:
Both versions full/update are affected with the missing adsb.dll problem.
Ingo
-
Situation with the missing .dll should be corrected now.
Upgrade: http://www.airnavsystems.com/download/anrb/ANRBUpgradeto50072.exe
Full install: http://www.airnavsystems.com/download/anrb/ANRB50072Setup.exe
Waiting for user feedback.
-
Upgrade still doesn't work - now it's missing MSVCR120.dll :-(
Do you test these before you release them?
And it still says it's upgrading to 5.00.71
-
With upgrade the problems are fixed now.
http://www.airnavsystems.com/download/anrb/ANRBUpgradeto50072.exe
Ingo
-
same problem does not work missing file
-
Hi Paul,
which file is missing? Are you shure, that you have used the new downloaded file?
Tested full install. It's working now. http://www.airnavsystems.com/download/anrb/ANRB50072Setup.exe
Ingo
-
done full unstall this is the message
downloaded new upgrade does not open message
the program cant start because MSVCR100 DILL IS MISSING FROM YOUR COMPUTER TRY RENSTALLING THE PROGRAM TO FIXTHE PROBLEM
paul in kent
-
I've informed airnav development.
Ingo
-
Update: Have checked my 24/7 Server. Here I got the missing MSVCR100.dll too. Quick and dirty solution: searched for this dll on my computer and copied the dll (the one from Google Earth) to the airnav radarbox folder.
Ingo
-
Less dirty solution:
Download and install:
http://www.microsoft.com/de-de/download/confirmation.aspx?id=14632
http://www.microsoft.com/de-de/download/details.aspx?id=5555
After that ANRB Software works.
It seems that the reason why it works on two of three of my computers is that I use other software that needs Microsoft Visual C++ 2010 Redistributable (x86 / x64) to work. On the 24/7 server was only GE, firefox and ANRB installed. But no software that needs Microsoft Visual C++ 2010 Redistributable was installed in this PC.
Ingo
-
I have installed the new 5.00.72 full install this morning and alerts, 3D etc working as expected and also showing as 5.00.72
Alan
-
Paul,
Have you got it working yet?
Alan
-
Afternoon Alan,
Glad to see you got back to blighty ok.
Can you confirm that the only thing that the new software version corrects is a problem regarding alerts via email (not sound or notification message alerts). I do not use this email function therefore is it worth me upgrading or would I be missing out on some other enhancements ?
Ian
-
Hi Ian.
Travelled through Spain no problems. Got to UK and found first road works 200m out the port gate and it continued with disruption after disruption until way passed Manchester. Welcome to the UK!!
The new version only sorts alert emails with no other functionality. New server causing the issue.
Alan
-
V5.00.71 had a problem with the populate functionality intergrared in the MyLog Menu. This is also sorted within V5.00.72.
Ingo
-
Hi Alan I'm at work today. I have installed Airnav
Latest version with the error message
Do I download the link you sent then start
Airnav again
-
Cheers Alan.
I'll leave things as they are !
Ian
-
That's right Ingo, I was already using that version prior to this new 5.00.72 and forgot about it..
Alan
-
Alan I also needed some time to figure out what the difference is between v5.00.71 and v5.00.72 I was already using. Figured it out during mail conversation about the missing dll problem with Andre from airnav today night.
Ingo
-
Hi All,
I installed the upgrade latest version 5.00.072 (in message #11, thank you Ingo) a couple of minutes ago without any problems.
Kind Regards, John
-
Have also downloaded (the upgrade version) on my WIN7 Computer without any issues. I dont use alerts so havent tested it. Haven't put it on my WIN8.1 tablet as yet.
tommyg
-
The new built of .72 seem to work now.
Kenny
-
Good evening a big thank you all working
Paul
-
Hi Paul, that tells me (us) that it finally worked for you. Glad to hear.
Airnav has uploaded a new installer with the MSVCR100.dll included. Therefore from now on it should work for everyone. Please tell if not.
Ingo
-
Since I updated to 5.00.72, the log is sent only to the first email address set in "Recipients (comma separated)" in "MyLog/Reporter/Send by mail" section.
-
I will advise Airnav Liviu
I am surprised this hasn't been reported previously, anyone else having the same problem?
Alan
-
Hi Alan, Yes I have the Problem if I send my Logs via Ainav server. I've tested this during the scrambled mail if sent from v5.00.071 problem. but forgot to post it. Sorry for that. I think, that we had this in an earlier version, but there was sending via own mail account affected.
If sending via own mail accountis used, the mail (Alert and Log) is send to both mail addresses. So it could be a problem at airnavs end.
Ingo
-
Noted Ingo, will pass on this further info
Alan
-
Have downloaded .072 upgrade to replace my .071 but the My Log populate log still has 5 aircraft updated, with the .071 version these would have disappeared but they remain when I populate
The Database for the aircraft is 225027 after having updated this just now
Do I need to download anything to correct this ? [ie MyLog problem ?]
Tony
-
Tony,
The populate function didn't work correctly in 71 it was only corrected in 72.
What do you mean they remain do you mean the populate function state there are 5 aircraft to be updated, even after your 5 unknown have populated, or do you mean they didn't populate.
The database update available this morning gave the figure of 225027, can you advise which were the 5 unknowns you picked up today please as if you mean they didn't populate they may not be in the database.
Sometime it takes more than on run of the populate function to get them all in. Also populate only populates for the myview view you are in at the time ie today, if it is outwith that view ie, You noted the unknown in the last month but are in mylog for today it will not populate but it will show as unknown when you try to populate. It may well be there are 5 unknowns in your mylog outwith the view you were in at the time and they are still unknowns. Try running reporter for other view and if there unknowns in that view they will show at the top of the report.
Alan
-
In addition to Alans posting:
Summary of resons why unknowns aren't populated during a populate cycle started from MyLog Menu:
1. unknown isn't in db because of the fact that currently no details of the airframe are available. (cure: time; sooner or later one will Mk1EB it and someone like me will find the detaails and post it in db update request thread and the updaters will add it)
2. unknown isn't in the db because the unknown isn't an unknown but a received corrupted datapackage. (no cure)
3. Human related 1: details were posted but the updaters have forgotten to enter them (from time to time, cure: inform updaters in db update request thread)
4. Human related 2: details were incorrectly entered in the database by updaters (rare, cure: inform updaters in db update request thread)
5. Human related 3: details were correctly entered by updater but not sent (confirmed) to db (rare, cure: inform updaters in db update request thread)
6. Technical issues: details weree added correctly and sent to db, but somehow date gets lost (rare, cure: inform updaters in db update request thread)
7. Unknown(s) to be populated wasn't received in the time span currently shown in MyLog grid. (cure: choose all time and run a populate cycle at least two or three times. Warning: populate cycles can take several hours alternative: perform a database update download (db menu) and run all time populate after new db is applied. This will update the MyLog database)
To get the by now populated unknowns out of the report it is necessary to generate the report again.
Ingo
-
Is says 5 aircraft have been updated in My Log [of 901 aircraft logged today] when populate is used [If is use the one hour slot it says 1 aircraft has been updated but when I enter All Time out of the 16696 aircraft 505 have been updated] so I guess that these have been misread or just not in the DB
Not sure how to find out which aircraft have not been populated though
The latest aircraft DB is 225027 with 5Y-CYB being the last entry along with a couple RNZAF Texans which were also the last entries about 10 days ago
Tony
-
Just did the reporter function and it came up with 4CA7AD as not known at 1609Z if that means anything ?
TT
-
Tony
Don't go with the last aircraft in the database being the last aircraft entered, it isn't. The database you have includes aircraft entered, or amended yesterday and each of the previous days. It will not include aircraft deleted during the period of time since the last update was performed.
Regarding the 505 and other numbers, this is your mylog being updated not the database, 2 entirely different things.
Also if you run reporter the unknowns are at the top of the report. These unknowns are not be in the database and may be aircraft hex codes which are in the database but the other data is unknown or they may simply be decoding error, corrupt packets etc and don't correspond to any aircraft.
4CA7AD is an unknown probably a corrupt packet as it isn't allocated but may be a miscode. Corrupt packets are evidenced by few messages ie.2, no callsign details in mylog and usually no squawk when you see them on the grid.
From the evidence you have given I would suggest there is nothing wrong.
Alan
-
Thanks Alan for that
Cheers
Tony
-
Hi Alan,
do you exactly know, what the number shown at the beginning of the update cycle means?
Regardless the exact number that is shown at the beginning of thr first populate cycle it is always reduced by the number of populated airframes at the beginning of a second populate cycle. E.g.: 1st cyle 469, 4 new entries in nav database after 1st cycle. 465 is shown at the beginning of 2nd populate cycle. It is regardless when and how many times the airframe was received during the timespan and how many populate cycles were ran in between.
Is it possible, that the number shows the count of airframes without details of the currently displayed time span in MyLog grid? If that is the case the text is misleading and should be changed.
Ingo
-
Don't know Ingo, never noted it.
Alan
-
Ok Alan, in that case I'll do some investigation until next weekend. Or maybe I just should ask Andre (Aleksey), what that number is really meaning.
Ingo
-
Do you mean the figure in bold at the left top of the grid. If so I thought it was the number of aircraft picked up in the time span.
Alan
-
No, I don't mean that figure, which is showing the number of aircraft picked up in the selected time span with the exception of all aiframes, that have been picked up later as the selected time span.
That means each airframe that has picked up during the selected time span is remuved from the list, as soon as it is received later as the upper time end of the selected time span. Therefore only airframes with a last receiption time within the selected timespan are shown in the list. If you don't change the timespan, the number of received airframes within the timespan decreases continiously.
Im mean the number that is shown after you go to MyLog -> Tools -> Ppopulate -> confirming 1st message: This function can take some minutes. followed by this message
460 Aircraft(s) Updated. Once all pending photos / aircraft information is downloaded the MyLog Screen is automatically refreshed.
I think, that this figure shows the number of airframes without details in the selected time span. Anyway, the second part of the message is incorrect, as it always needs a second (third) run of populate to get the airframes entries im MyLog updated. It never had worked automatically. Well, unless the particular airframe was received again. In that case MyLog was updated.
Ingo
-
Oh, I have never had more than 3 or 4 when I run populate and it completes in seconds but then I update every day so don't experience what you are experiencing.
Alan
-
Hi Alan, do you by any chance know, how many airframes you have added/amended in the server database since November 19th?
The airframe count shown during populate cycle definitely doesn't show the number of airframes without details of a selected time span.
Ingo
-
No idea Ingo I don't have time to count addition/amendments/deletions. Worth remembering that some that were in have been deleted so its not as simple as only new ones to contend with.
Alan
-
I just wanted to let you know, that the problem "timed out flights remain on map and in the myflights list" is still existing in the actual V5.00.072 Version. Deactivating - Reactivating the processing of flights received by own box using the ckeck-box "Process Hardware Flights" in the bottom left corner of MyFlights list removes them.
Ingo
-
I will forward on this info, thanks Ingo. I believe it may be something to do with the new server software but maybe not.
Alan
-
Hi Alan,
this problem is an old one that hadn't appeared for a while. I just wanted to inform about the fact, that it's still due to be fixed.
This time I had dbwin.exe running while it happened. Unfortunately file is 130MB, so I'll post it only if it's requested by airnav dev.
Ingo
-
Noted Ingo
Alan
-
Hi Alan,
are you and airnav development aware on this one:
http://www.airnavsystems.com/forum/index.php?topic=8254.new#new
Ingo
-
Not until I read the thread so I doubt Airnav will be aware but I will make them aware.
-
Have just sent Andre a mail.
Ingo
-
OK I will update the Task list
Alan
-
I have only access to App and RB24.com task list so I can't do the adding by myself.
Thanks!
Ingo
-
I have updated the Task List and note that your freezing flight has been added.
Alan
-
Thanks for the info!
Ingo
-
I noticed another interesting behaviour:
If an ADS-B equipped airframe enters my area it usually shows to following infos:
mode-s
reg / Type
flight level/(vertical speed)/speed
route info (void)
as soon as flight id is optained it shows up in the MyFlights list, but the airframe label remains as stated above. Although its position has been updated several times in the meantime. It usually takes up to several 10 seconds until the flight id and route info finally shows up at the airframe label.
flight id
reg / type
flight level/(vertical speed)/speed
route info
I can't remeber, that this was the case in earlier versions of the software.
Ingo
-
Ingo it does the same with the other info. If I see an aircraft with an unknown hex code and add the details to the database and then click on the aircraft it comes up quite quickly on the grid, it can take a further minute or so before the map lable updates.
For flight ID's the flight may come up without route info initially while the routine looks it up from the server and then displays it on the grid/map and this usually takes a few seconds.
Alan
-
It's the same with flight id's, in which the route is already in the lokal database.
MyFlight list shows full info immediately after ID is received, but the label on the map remains with hex number as first line for (as you stated) up to one minute until flight id and route info is shown.
Ingo
-
I believe the route info is still checked even if it is in the onboard database to ensure for example it is not time expired and if so it is marked on the server as such.
The server accesses real-time commercial flight information provided by flightstats. Flights are checked to see if is present on this database. If yes the org/fdst is taken from it. If not present we get it from our own database. Alpha-numeric flight ID's usually come from our own database as the commercial providers don't usually have these and the same with cargo flights and charter flights. This is the case for network flights but I don't know about local flights but these go though checking and look up processes as well.
Work is still ongoing with the flight look up routines
Alan
-
Many thanks for background information about the flight look up routines.
I don't think, that the routines are the problem. The problem or better the distraction is, that it seems that we have two different processing procedures for the displaying of that information.
It seems that MyFlight list uses the following procedure:
Look-up info in local db -> display in MyFlights table -> check online if it's still valid, if valid: do nothing / if not valid: alter/update db if not valid anymore -> do nothing / display altered info
Map seems to be altered by following procedure:
do nothing -> do nothing -> do nothing -> update lable
For me it would look more professional, if both would be processed by same procedure and at the same time.
That can be realized in two different ways:
1. receive -> look-up local -> Display -> check online -> (alter) -> (Display)
or, what I would prefer
2. receiver -> look-up local -> check online -> (alter) -> Display
In both cases the time difference between the displaying of the route information in the MyFlights list and in the airframe lable on the Map would be as small as the difference between the two refresh rates.
Maybe we can suggest this to Aleksey after his current work is finished.
Ingo
-
I will try and find out how the local flights work both for the grid and map display I would also state that I can watch flights coming up out of my local airport and as far as I was aware there was no delay/difference between the grid and label. As far as I am aware the display routines have not changed for a good time as it was one of the first corrections carried out in the update process a long time back.
New flights coming up out of the airport don't always display the flight ID initially and it can take a few moments before the flight ID is displayed which then allows the route to be processed and then displayed but as far as I can remember I usually note both the grid and map lable changing at the same time.
I will have a look into it further as I can see flights on the ground at Edinburgh on the network and then pick them up on myflights as they come into my receiver range.
I agree that the grid and label info should change together and if this is not the case I will report this.
Alan
-
Just fished another one:
If you try to add an already existing ICAO airline code you don't get a Software error message but an EurekaLog 6.0.18 error message
Content: SQLite Error 19 - column C3 is not unique.
Seems, that the false use / false input handling procedures are not implemented. I would say this one is medium severity.
EDIT:
Discovered due to a new annoying behaviour of Bundespolizei. Recently they don't enter BPO??? but BP0??? flight id's. Therefore I got the Logo of BOT Air Botswana. That's why I was toying around a little bit in the database to get the Bundespolizei Logo back.
Ingo
-
Alan,
about the info displaying problem.
It just came to my mind:
I've spreaded ANRB window over two monitors. MyFlights List on primary Monitor, Map on the Desktop extension Monitor. Maybe that is, what is causing the strange behaviour.
Ingo
-
Could be, I have been watching 4 flights come out of Edinburgh and at the most a second difference between the grid and the map display and on each occasion the route was on both when the came on screen.
Alan
-
Can you contact me by email regarding the ICAO one to give me a better understanding.
Alan
-
WILCO and done!
Ingo
-
Ta Alan
-
Ingo,
Quick query. How did you manage to separate your My Flights on one monitor and the Map on the other monitor?
Hope you don't mind me asking?
Thanks in advance
Trevor
-
Not so quick answer:
A real separation is not possible.
Under windows you have typically three window states:
1. Maximized (is usually used if only one monitor available)
2. Mimimized
3. Movable Window
I use 3. to get the multiple screen mode realised:
1. Use the window toggle button to get to the window mode.
2. Place it at about 50% on primary screen (for me it's the left one)
3. Use mouse to alter the width until the right edge of second monitor
4. Use the mouse to alter the hight of the window on the right (secondary) monitor
5. As soon as you reach the edge of the visible area the lower part of ANRB window should spread to the bottom of the second monitor.
6. Use mouse to alter the "border" between myflights list and the map
If any further info/help is neede just shout.
Ingo
-
Cheers Ingo, I'll give it a go.
-
Good Day,
after some intense testing with the route amendments from the past one and a half weeks I have to tell, that the route Auto-Update function does only work, if the timestamp of the false route or the whole route is manually deleted from the local database.
list of options that I've tested:
opt. 1: Do nothing. Route is updated in server db and therefore gets a new "timestamp". Although this "timestamp" is younger than the "timestamp" in the local database no update of local db is happening.
opt. 2: Delete "timestamp" in local database. This ends up into "no Route displayed" during the alerts. But is then correctly displayed in Log. I guees that the alert was faster than the update process.
opt. 3: Delete the false route completely from the local database. This option seems actually working.
Would be great, if can get opt. 1 working in one of the futur versions of ANRB software.
Regards Ingo
-
That is correct Ingo, routes are only updated automatically if there is no info against it in the first place.
Alan
-
Hi Alan,
Plus: False routes are updated/changed if their timestamp is removed from db.
It's a shame, that it's not working by checking some kind of timestamp. The timestamp in local db is based on the first reception of the particular flight id on your own system and has nothing to do with the timestamp in database on the server.
Please consider to add this to task system as a feature request (Type: software improvement).
Unfortunately I could imagine that implementing such a timestamp based checking routine may cause "load" problems on the server.
Ingo
-
Ingo,
It only works to populate new routes and does the same for new aircraft picked up and it does not and is not intended to change the information held for the particular route or aircraft picked up.
The database update feature is intended for full revisions of the data held for particular aircraft/routes etc.
I will however add it to the task system as you request however given the number of amendments made to the database each day this may not be possible for the reason you state.
Alan
-
Maybe ckecking the routes could be added to the populate function that can be launched from MyLog. Going that way would reduce the load on the server. Nevertheless a "adding to/last amended in server db" timestamp has to be added.
If it is already added there, we ( I ) have the problem, that it's not working for updated route infos.
In the meantime I'll delete the timestamp form local db of each route amendment that I post under db update requests.
Thanks!
Ingo
-
Ingo,
The populate function in mylog only populates new aircraft it doesn't update aircraft information held in the database and doesn't look at any other information including routes.
Alan
-
Alan,
many thanks for confirming that populate is only for airframe updates. It updates airframes, if the airframe information in local db is incomplete.
Loud thinking: Why not implementing a populate functionality for routes (like the one for airframes) in future versions...
Ingo
-
The request has been added. Just to confirm at this time if the route is added to the database before you pick it up it will update when you pick it up.
Alan