Board index FlightGear Support Installation

NavCache:init failed:Sqlite error:Sqlite API abuse

Need help getting up and running? Installing FlightGear, add-on planes, sceneries etc.
Forum rules
In order to help you, we need to know a lot of information. Make sure to include answers to at least the following questions in your initial post.

- what OS (Windows Xp/Vista, Mac etc.) are you running?
- what FlightGear version do you use?
- what graphics card do you have?

Please, also see Requesting Technical Help.

Note: If you did not get a reponse, even after 7 days, you may want to check out the FlightGear mailing lists to ask your question there.

NavCache:init failed:Sqlite error:Sqlite API abuse

Postby grimdon » Wed Oct 23, 2013 8:36 pm

I am getting this error message in the console window as FlightGear quits.
I am running FG 2.12.0 on Windows XP. I have been experimenting with system.fgfsrc
but now have deleted it and still getting same failure mode. Earlier attempts worked
as expected (well, almost, but saving that for later.)
I am launching using the desktop icon -> wizard -> C172 -> KSFO -> fail.
Earlier attempts using command line were working with a system.fgfsrc file, but
then started getting subject failure mode. Now nothing gets me away from it.
Perhaps something is being saved somewhere and preventing me from undoing
an ill-advised command line.

I have source code on a Linux system and grep'd for the error message and found it
but can't get any further.

I would, of course, appreciate any advice.
grimdon
 
Posts: 52
Joined: Sat Jun 23, 2012 4:08 am

Re: NavCache:init failed:Sqlite error:Sqlite API abuse

Postby zakalawe » Thu Oct 24, 2013 8:04 am

It is possible you have managed to corrupt you cache file; test this by removing it, and it will be re-created on the next launch. Actually 2.12.0 has a bug where it's created every launch, which slows things down - this is fixed in 2.12.1 which will be released shortly. The cache file lives in the 'FG_HOME' folder, which on Windows lives at C:\Users\<yourusername>\AppData\Roaming\flightgear.org

(The cache will be called navdata_2_12.cache, in that directory)

Explorer hides the AppData folder from you when viewing graphically, but you can type the name into the URL bar to view it.
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: NavCache:init failed:Sqlite error:Sqlite API abuse

Postby Hooray » Thu Oct 24, 2013 2:02 pm

It is possible you have managed to corrupt you cache file; test this by removing it, and it will be re-created on the next launch.

How about adding a simple boolean property to force a rebuild during restart ?
I'm asking because explaining to new users how to locate $FG_HOME and rename/delete their cache seems unnecessarily complicated.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: NavCache:init failed:Sqlite error:Sqlite API abuse

Postby zakalawe » Thu Oct 24, 2013 2:14 pm

Not a property, but a command line argument can certainly be done. However, in these kind of error scenarios, a rebuild is supposed to be triggered anyway. Oh well. I'll add a --rebuild-caches option and it can drop the aircraft and terrasync caches too.
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: NavCache:init failed:Sqlite error:Sqlite API abuse

Postby Hooray » Thu Oct 24, 2013 2:22 pm

Ya, I was thinking in terms of a command-line option - just as a property for simplicity, e.g. --prop:/startup/rebuild-all-caches=1
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: NavCache:init failed:Sqlite error:Sqlite API abuse

Postby grimdon » Thu Oct 24, 2013 7:22 pm

Thanks for the prompt interest guys.
I am running XP.
I found the cache file at C:\Documents and Settings\Don\Application Data\flightgear.org from the command line and deleted it.
It was a little over 80MB in size.
Unfortunately, I get the same old result when launching either from command line (no arguments) or desktop icon.
The failure recently (both before and after deletion of cache) occurs after just about one second from launch. When I first started getting this error, it occurred several seconds
after launch.

When I referred in the previous post to "experiments" I was using system.fgfsrc for initialization of position and orientation of my vehicle with --fdm=null or --fdm=external.
This worked as expected. (Before I started getting this failure mode.)
I never got as far as supplying position and orientation via serial port which is my goal.
grimdon
 
Posts: 52
Joined: Sat Jun 23, 2012 4:08 am

Re: NavCache:init failed:Sqlite error:Sqlite API abuse

Postby Johan G » Sat Oct 26, 2013 10:08 am

zakalawe wrote in Thu Oct 24, 2013 2:14 pm:Oh well. I'll add a --rebuild-caches option and it can drop the aircraft and terrasync caches too.

By "terrasync caches" I hope you don't mean the whole of the downloaded TerraSync scenery. :wink:
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5509
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: NavCache:init failed:Sqlite error:Sqlite API abuse

Postby zakalawe » Sat Oct 26, 2013 1:29 pm

Johan G wrote in Sat Oct 26, 2013 10:08 am:By "terrasync caches" I hope you don't mean the whole of the downloaded TerraSync scenery. :wink:

No, I mean the update cache which stops us spamming the server with update requests every launch - instead we only check the server once per 24-hour period, which greatly cuts down on nuisance update polls to the server.

The only thing I can't decide if this option should drop is the auto-save file. Then the options becomes a bit more of a 'reset to defaults', which might be more useful since people often end up with old values in their auto-save and again we don't have a UI to drop it.
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: NavCache:init failed:Sqlite error:Sqlite API abuse

Postby Hooray » Sat Oct 26, 2013 1:57 pm

zakalawe wrote:The only thing I can't decide if this option should drop is the auto-save file. Then the options becomes a bit more of a 'reset to defaults', which might be more useful since people often end up with old values in their auto-save and again we don't have a UI to drop it.


Here's my 2c: Having the option would be awesome, because it would greatly simplify troubleshooting, as you say - so having additional startup options that explicitly override/ignore autosave.xml and ~/.fgfsrc would be awesome as it would be much more straightforward to exclude a plethora of potential problem sources, we could save tons of time that way - but I wouldn't make it part of the same option. Ideally, being able to ignore autosave/fgfsrc would be different command-line arguments.

Preferably, we would have a "soft ignore" mode (retaining data) and a "delete" mode, which resets any local settings that may interfere with FG.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: NavCache:init failed:Sqlite error:Sqlite API abuse

Postby zakalawe » Sat Oct 26, 2013 2:48 pm

Okay, this can be done - need some suggestions for names. To be clear, we write autosave on exit, so we need two modes:
- don't read on launch; this effectively replaces the autosave file on exit, since a new one will be generated and overwrite the current
- don't read but also don't write

I was going to call the option --ignore-autosave but I can't decide if that corresponds to case 1 or case 2 - you might next expect an 'ignore' option to change the file on disk. So maybe the former should be called --reset-autosave and the second should --ignore-autosave?

And I'll call the caches one --reset-caches for a hint of consistency. Seem reasonable? Better naming suggestions?
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: NavCache:init failed:Sqlite error:Sqlite API abuse

Postby zakalawe » Sat Oct 26, 2013 2:51 pm

Spoke too soon; --restore-defaults already does case 1. And --disable-save-on-exit exists which does what you can guess, but would need some work to implement --ignore-autosave. Hmmm.

I am inclined to overload --restore-defaults to reset the caches too, since it already exists and is well defined.
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: NavCache:init failed:Sqlite error:Sqlite API abuse

Postby Hooray » Sat Oct 26, 2013 3:00 pm

Frankly, I wasn't even aware of those existing command line arguments ...

But if we could get that working, it could literally save us hours of troubleshooting each month, so that would be really worthwhile - especially because there's really only half a dozen of folks here who regularly help provide support to new users, and because you obviously need to be fairly familiar with FG internals to troubleshoot in the first place. So excluding autosave/fgfsrc stuff would be a great time-saver, maybe even with an option to override these files by using either custom files via --use-fgfsrc=foo.fgfsrc, or a PropertyList-encoded file with embedded fgfsrc/autosave sections for troubleshooting purposes ?

This may seem a little tangential at the moment, but being able to save/load and override startup profiles without having to teach new users how to locate $FG_HOME would free quite some forum resources :D

Ideally, the log file would explicitly state that these options are in-use, right at the top of the file, maybe even dumping fgfsrc/autosave.xml into the property tree for runtime debugging - but also for replicating all relevant stuff in the log file :D

EDIT: Okay, looking at the code in fg_init.cxx, I think it would also be better to load another preferences.xml from $FG_HOME (and provide an option to override/ignore that), simply because we could then make $FG_ROOT/preferences.xml readonly during installation and generally discourage people from editing the "global/shared" preferences.xml in $FG_ROOT and instead only ever edit their own preferences.xml in $FG_HOME - which should align well with modern multi-user operating systems, and which would also mean that users no longer need to modify the global file, and can't affect other users.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: NavCache:init failed:Sqlite error:Sqlite API abuse

Postby zakalawe » Sat Oct 26, 2013 5:10 pm

What you describe is already the situation - no one should be editing preferences.xml, it should be called 'defaults.xml' really but changing it is probably not a good idea. You can already pass a property list file which over-rides any settings in preferences.xml; any files passed on the command line are treated exactly that way. We don't log the path of such files when processing them but it's trivial to add, and based on the loadDefaults flag, fgInitConfig already logs a 'Ignoring user settings' message.

So I think only the following is missing:
- make --restore-defaults kill the caches (nav-cache, aircraft cache and terrasync update cache)
- add a --ignore-defaults which stops both read *and* writing of autosave.xml
- log any XML config file we process

And we should absolutely stop telling anyone to edit preferences.xml in FG_ROOT; any documentation or advice which says to should be changes ASAP.

Does that cover the basics cases? (I'm sure there are many other more subtle ones, but that list is relatively simple to do and low-risk, compared to renaming long-standing files or modifying startup parse order, both of which are more or less guaranteed to break someone's workflow)
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: NavCache:init failed:Sqlite error:Sqlite API abuse

Postby grimdon » Sat Oct 26, 2013 6:00 pm

Glad to see my problem is getting attention. I appreciate it.
Here are more results from my troubleshooting: I have re-installed from the DVD four times.
After each time I get the same failure mode.
I have determined that some stuff is remembered between installations. I think that is why
the reinstallations are not curing the problem. (Windows "remove" resource was used at least
one of the times. There are files remaining in ..\Application Data\flightgear.org\ after removal.
I would think that a user removing Flightgear would not appreciate an 80MB file being left around.)
Anyhow the fgfs.log file has many lines similar to:
"navaid:4:..\..\..\flightgear\src\Navaids\NavdataCache.cxx:1974:findAirportRunway:unknown airport\runway:KSAV 01 MM
Maybe this is relevant. I don't think any such directories as ....flightgear\src... were installed.

In any case, it sounds like this "autosave" stuff you guys are concerned about is on the right track.
grimdon
 
Posts: 52
Joined: Sat Jun 23, 2012 4:08 am

Re: NavCache:init failed:Sqlite error:Sqlite API abuse

Postby Hooray » Sat Oct 26, 2013 6:02 pm

I would think that a user removing Flightgear would not appreciate an 80MB file being left around.

the installer could provide an option that says

[x] delete $FG_HOME (user settings, nav cache etc)

(defaulting it to true)


log any XML config file we process


I'd suggest to not only log paths/file name, but also dump files that are not part of $FG_ROOT - i.e. anything outside $FG_ROOT is likely to be custom and should be included verbatim for troubleshooting purposes, including XML parser errors - which should remove most of the guesswork for people providing support here.

And we should absolutely stop telling anyone to edit preferences.xml in FG_ROOT; any documentation or advice which says to should be changes ASAP.

I think the wiki contains plenty of those ... for starters, we should add a header to the file and make it readonly during installation - along with a header that explains how to override these defaults.

Yes, that should work well enough - regarding renaming of preferences.xml, I agree - we once talked about cleaning it up, and moving major parts to separate files, in some dedicated $FG_ROOT/Defaults folder - for now, preferences.xml could remain, but introducing defaults.xml would seem like a good idea, while it would merely include preferences.xml for now - to help prepare the migration. FlightGear is never going to work without some form of fgdata, so moving all the preferences/presets stuff to $FG_ROOT/Defaults would seem like a sane idea, Stuart also seemed supportive of the idea back then:

Subject: Aircraft Rating System
stuart wrote:
Hooray wrote:As another example, have you recently had a look into $FG_ROOT/preferences.xml ?
That's another excellent example for a huge XML file that could be EASILY split into a number of separate XML files that could be simply referenced from the top level preferences.xml via an include directive, so that the defaults could be stored separately - i.e. in $FG_ROOT/Preferences or $FG_ROOT/Defaults

You would end up with separate XML files for all important setting:
  • $FG_ROOT/Preferences/startup.xml
  • $FG_ROOT/Preferences/rendering.xml
  • $FG_ROOT/Preferences/sound.xml
  • $FG_ROOT/Preferences/systems.xml
  • $FG_ROOT/Preferences/views.xml
  • $FG_ROOT/Preferences/multiplay.xml
  • $FG_ROOT/Preferences/terrasync.xml
  • $FG_ROOT/Preferences/controls.xml
  • $FG_ROOT/Preferences/instrumentation.xml
  • $FG_ROOT/Preferences/logging.xml
    and so on


It's not that the current technique would be bad, it's just that it isn't as intuitive and self-documenting as possible.

I don't know if you agree or disagree, but I can assure you that if you do disagree, then it's because you are also a long-time FlightGear user and developer with plenty of experience ;-)

I very much like your idea of providing a "template" aircraft, and also splitting up preferences.xml
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Next

Return to Installation

Who is online

Users browsing this forum: No registered users and 1 guest

cron