Hi. I came to the forum looking for just such a post: I normally have to restart my FSNavDBC at least a dozen times, often more than that, before I get it to complete a new database. Certain sceneries (like LLBG) hang every time, others hang just on a particular run, then work fine next time - or vice versa. Today for example, FSNavDBC hung on a scenery called 'Aegean Small Airports', but when I re-ran the programme, it went through it just fine. A few runs later it stuck again, then was OK next time. Odd. (The programme can be said to 'hang' when clicking the FSNavDBC 'cancel' button no longer works, the programme just freezes up when you click it: sometimes the programme is using full CPU (as per Task Manager) and takes a while to process a folder, but it is not actually stuck and the cancel button works in that case. Other times, when the programme really has hung, the only way to close the programme is to kill the process in Task Manager).My Scenery.000 and Scenery.001 files are both well over 10MBs by the way and I have more than 1000 sceneries in the library. Removing Scenery.000 and Scenery.001 from the FSNav folder doesn't stop Scenery.000 and Scenery.001 from hanging.It occurred to me today that I ought to create a copy of my addon scenery folder and remove all bgl files from that copy apart from AFCADs, (not forgetting all the other scenery folders installed elsewhere, like Aerosoft, Lago, UK2000 etc. etc.) then use that folder for the FSNavDBC run. I see a couple of people have had exactly the same idea. My worry is that FSNavDBC does not only look at files starting AF2 or AFX. Some afcad files are labelled quite differently - if you run ScanAFD you can see this - and some navaid data seems to be contained in separate files (e.g. "navaid.bgl"), not in the afcad itself. I assume FSNavDBC needs those files too. For now, when FSNavDBC hangs on a particular scenery I temporarily remove all the files apart from the afcads in that folder and rerun FSNavDBC, but when I have a dozen or more sceneries that cause the programme to hang, and they are not always the same every time, it's a long, annoying process by trial and error. It certainly puts me off redoing the FSNav database too often. Making a special "FSNavDBC folder" would certainly save a lot of time and frustration in the long run!Does anyone (Ernst, Hans?) who uses such a special folder with only AF2/AFX files in it for FSNavDBC runs notice any oddities or anything missing in FSNavigator afterwards? I can probably use ScanAFD to search for all AFCADs, regardless of what they are called (an afternoon's work!), but does anyone definitely know which files FSNavDBC incorporates into its database files? What about those separate navaid files?Martin

Hi. I came to the forum looking for just such a post: I normally have to restart my FSNavDBC at least a dozen times, often more than that, before I get it to complete a new database. Certain sceneries (like LLBG) hang every time, others hang just on a particular run, then work fine next time - or vice versa. Today for example, FSNavDBC hung on a scenery called 'Aegean Small Airports', but when I re-ran the programme, it went through it just fine. A few runs later it stuck again, then was OK next time. Odd. (The programme can be said to 'hang' when clicking the FSNavDBC 'cancel' button no longer works, the programme just freezes up when you click it: sometimes the programme is using full CPU (as per Task Manager) and takes a while to process a folder, but it is not actually stuck and the cancel button works in that case. Other times, when the programme really has hung, the only way to close the programme is to kill the process in Task Manager).My Scenery.000 and Scenery.001 files are both well over 10MBs by the way and I have more than 1000 sceneries in the library. Removing Scenery.000 and Scenery.001 from the FSNav folder doesn't stop Scenery.000 and Scenery.001 from hanging.It occurred to me today that I ought to create a copy of my addon scenery folder and remove all bgl files from that copy apart from AFCADs, (not forgetting all the other scenery folders installed elsewhere, like Aerosoft, Lago, UK2000 etc. etc.) then use that folder for the FSNavDBC run. I see a couple of people have had exactly the same idea. My worry is that FSNavDBC does not only look at files starting AF2 or AFX. Some afcad files are labelled quite differently - if you run ScanAFD you can see this - and some navaid data seems to be contained in separate files (e.g. "navaid.bgl"), not in the afcad itself. I assume FSNavDBC needs those files too. For now, when FSNavDBC hangs on a particular scenery I temporarily remove all the files apart from the afcads in that folder and rerun FSNavDBC, but when I have a dozen or more sceneries that cause the programme to hang, and they are not always the same every time, it's a long, annoying process by trial and error. It certainly puts me off redoing the FSNav database too often. Making a special "FSNavDBC folder" would certainly save a lot of time and frustration in the long run!Does anyone (Ernst, Hans?) who uses such a special folder with only AF2/AFX files in it for FSNavDBC runs notice any oddities or anything missing in FSNavigator afterwards? I can probably use ScanAFD to search for all AFCADs, regardless of what they are called (an afternoon's work!), but does anyone definitely know which files FSNavDBC incorporates into its database files? What about those separate navaid files?Martin

Yes, Martin, it can be frustrating but with a little tuning it can be made to work smoothly. I have a similar-sized quantity of scenery as your goodself, and there are several different things that will make it stall but they can all be overcome:1. First of all, the idea of deleting the Scenery.000 and Scenery.001 files will not deal with all of the different things that will make the generation process stall, so although it may work for some , I don't bother with that.2. One of the stalling problems can easily be resolved by re-arranging the scenery order slightly - don't ask me why. Watch where it repetitively stalls ( the generator will show where it has stopped) and try moving it up or down one position. (But allow it plenty of time, it will take a lot of time chewing its way through some sceneries, sometimes it is still running when you think it has given up.)3. In the case of sceneries with troublesome files within that cannot be solved by the above, I move the AFCAD to a separate (higher) directory, I have one reserved for such situations right at the top of my list in FS Navigator. I then mark the scenery with a distinct symbol so that I can easily identify it and de-select it during the generation process (but don't save the de-selections!). I rename mine ~~LLBG Ben Gurion, or whatever. I also move all sceneries with similar problems so that they are in a group together in the list - that way you don't miss any in a long list.4. Note also that I found that the base libraries for EZ scenery force themsleves into the addonscenery/scenery directory (move them and it just reinstalls them!), and these always cause my FSN to stall. For that reason (and one or two other good reasons) I have moved everything else out of there into a separate directory so that I can deselect it also during database generation.5. There is also an issue with some sceneries that have more than one file containing data for the same airport that perhaps should all be in one A&FD file and FSN only recognises one (the first it comes to, I think) per scenery layer and this is why some airports don't display the full airport on the map. Moving the proper A&FD file up (as per 2 above) will resolve that issue.With those steps done it is only once in a blue moon that addition of a new scenery upsets the balance of existing directory order but a quick shuffle per item two usually fixes it quickly and it is rare to have to run the generator more than twice to get the desired result.In terms of possibly losing navaids by moving files around, I have never (over many years) had FS direct me to a Navaid not on the map, so I don't think you are likely to lose a lot that way.Hope this helps,John

Thanks for the reply John: since I posted my comments though I decided to take the bull by the horns & fix this once and for all.Using XXCopy (an invaluable programme for writing advanced batch files) I first of all made a backup of my complete FS2004 folders, but creating only the folder structure, not copying any files (so that FS9 will not report folders missing at startup). Then I ran ScanAFD, & created & ran another script with XXCopy that copied all the AFCAD files that showed in ScanAFD to the new dummy 'folder only' copy of FS2004: this included any file with AF2, AFX, afcad, navaid etc. etc. in the file name. Then I made a copy of my scenery.cfg file and altered all the relevant entries (using EditPad which enables you to make multiple changes in text files at a mouse click) to point to the files in the new 'dummy' FSNav folder, and after backing up my original scenery.cfg file, overwrote it with the new one. Then I ran FS9 to create the new database and closed it down.Finally I ran FSNavigator database creator. It now uses the dummy FS9 folder instead of the real one (as one or two people in this thread have already suggested) to create its database files. Because there are only some 5% of the original files present (95% of the bgls in FS9 are of course irrelevant to FSNav), it runs in next to no time and there were no problems at all with hanging. Closed FSNavDBC when it had done and then restored my original scenery.cfg file before starting FS9.Now I have done all that I'll be able to run my batch scripts before I start FSNavDBC, in order to update the folder with new sceneries. I hope it will save me a lot of frustration in the future! (Seems to work fine in FS9 - all my sceneries show correctly as far as I can tell in FSNav).Martin

Well guys,We all seem to be shooting in the dark at this FSNav DBC hang issue and although none of us seem to be directly hitting it, something seems to have moved after every shot. Even my latest shot at creating a separate highest priority active scenery folder containing ALL my AFD/AFX files, is not a definite cure because totally unexpected new hangs still take place, also after deleting the two data base files.I am now convinced that the DBC program does not search for files with a specific name, e.g. those beginning with "AF2_", but it somehow searches for files containing specific Afcad and navigational types of data while at the same time taking their priorities into account. Because of this it sometimes runs up against a combination of data which it's internal decision tables are not fully programmed to handle, causing it to hang.Well, it may be a little tedious but when I now run my DBC program (with all my AF2/AFX files in one Afcad folder), I uncheck every one of my ADDON sceneries (including mesh and LC), leaving only my Afcad folder and ALL standard sceneries checked. After all, the DBC process ONLY creates the two FSNav data base files and in no way influences any active scenery or dynamic files sometimes contained within them. When FS9 itself is started up, all sceneries and anything within them are activated according to FS9's own rules, irrespective of what's being shown on the FSNav map or what the DBC process collected earlier.In this way the FSNav map does not show, e.g. secondry or overlay "airports" contained within certain addon sceneries themselves but which are used only for ground traffic tracks anyway. Quite frankly, I havn't run up against any problems when using this method .......... yet....... even after running the DBC process quite some times and flying/navigating around the world quite normally.Comments are welcome.Hans

I am now convinced that the DBC program does not search for files with a specific name, e.g. those beginning with "AF2_", but it somehow searches for files containing specific Afcad and navigational types of data while at the same time taking their priorities into account. Because of this it sometimes runs up against a combination of data which it's internal decision tables are not fully programmed to handle, causing it to hang

Hi Hans,I doubt we will ever know what causes it to hang, given that it is a dead product, but I can confirm from what I have read in previous discussion on the subject that the database searches for files with A&FD headers within. This is why it picks up individual files with Navaids or taxi signs but of course many AF&D files with add-on scenery are named differently so we would have far greater a problem to circumvent if it went by file names. I'm not sure what you mean by priorities but I already said that I thought it only read the first it came to when searching if there are multiple A&FD files per airport in one scenery layer.John

That's why ScanAFD is a good tool for picking up all AFCADs in all folders - the results bring up some unlikely 'suspects' for AFCAD files, but when you open them in AFCAD2 you can see that they do contain airport data. My FSNav database compilation last night ran without any hitches for the first time ever and the results look good in FSNav itself, so I';; be using that method in future.Martin