"Updating Scenario Database" takes forever !

[shinymac]

Hi Chaps

My friend has an annoying problem which has only manifested itself since updating to TS64 Bit....

Whenever he loads up the 64 bit version of the game, and the game gets as far as "updating scenario database", it can take up to TEN MINUTES to do this, although the game EVENTUALLY starts ok.

Can anyone advise what has happened and how to overcome this ?. Personally I find that TS64 Bit loads far QUICKER than the old system. We both have exactly the same hardware, built by the same guy at the same time, and my game starts up in a minute or so. If it helps in the analysis, if he selects TS32 bit, the game starts in SECONDS !

Thanks Guys

Derek

[johnrossetti]

There are a suite of programs written for windows by Mark Russinovich who now works for MS
https://en.wikipedia.org/wiki/Sysinternals
You can download the whole set of programs for free here. (1 download)
https://docs.microsoft.com/en-us/sysint ... downloads/
Its the top item.

The programs will enable to delve deep into your PC and see what is going on
Say you want to look at all the files the HD (or SSD) is calling up

What files railworks.exe looks for

What the processor is doing
All in the suite

BE CAREFUL some programs are VERY powerful
The important ones are:
https://docs.microsoft.com/en-us/sysint ... -utilities
https://docs.microsoft.com/en-us/sysint ... -utilities
Have fun and be careful
John

[Trev123]

TS2019 64bit takes about 3 minutes to load for me. Although after purchasing new DLC it can take quite a bit longer.

[shinymac]

Calling Gary P......are you out there my helpful friend ???

[peterfhayes]

Here are the "P" thoughts
I guess that he has deleted/renamed the SDBCache.bin and .MD5 files in the \STEAM\steamapps\common\RailWorks\Content folder and restarted TS 2019?
Cleared the blueprint cache via settings in TS2019.
Made sure that any part of TS2019 and Steam have permissions set in any anti-malware, AV, and firewall apps?
UAC can sometimes cause this, especially if the TS install is in the Program Files(x86) folder.

Does it happen if you open TS 2019 in Windows safe mode. Ideally check if it happens post a Windows "clean" - boot? (Google if needed)

Diagnostics
sfc /scannow
dxdiag
(Google both if needed)

PeterH - G

Trev - that is too long should be well under a minute!

[Trev123]

It is quicker now than it use to be on 32bit Peter.

[peterfhayes]

Trev
My figures are the same <minute in both 32/64-bit.
PeterH

[Trev123]

Exact time on TS 64bit, 2 minutes 35 seconds. I suppose it depends if TS is on an SSD or not. Mine is on a 2TB Seagate Firecuda HD. It also depends on how much DLC you have. I remember when I did a fresh install of TS a few years ago that it loaded very quick but as I installed all my DLC onto it the startup time became slower and slower.

[peterfhayes]

Trev
That's exactly right - mine is on a dedicated SSD, 79 routes circa 2500 scenarios, circa 265GB folder/file size - mean of 5 starts 18 seconds for both 32/64-bit. So that means the .m2 ssd is only approx 9x faster than a conventional HDD, wrt to loading times.
pH

[Trev123]

I have approx. 160 routes. Railworks folder size 350gb.

[petermargetts]

Just loaded the game which took just over a minute to update scenario database. I have 210 routes loaded with obviously lot of attached scenarios and 457 workshop scenarios that I have downloaded.
IT seems to take the same time in 32 and 64 bit.

PeterM

[gptech]

it can take up to TEN MINUTES to do this

Is that an accurate timed time?...we've had cases before with "takes 10 minutes to load the scenario" turning out to be 4 minutes or so---as a apecies we're terrible at estimating elapsed time, so get him to time how long it takes from clicking on whatever he clicks on to having the game's main menu displayed for both 32 and 64biot iterations of the game. There's no doubt he's experiencing a longer wait in 64bit, but having accurate(ish) timings would help us gauge what's happening better. Get him to work through Peter's suggestions and tell us if he has UAC turned off or on and just where he has the game installed.

Sysinternal's tools are brilliant, but like all tools are next to useless unless you know how to use them and how to interpret any reports generated; no offence intended, but you and your chumaren't the kind of guys who are au fait with delving into the hidden bits of Windows. They still may be needed of course, but as you've said the game gets to loading the Scenario database and then slows we know what it's doing, so that's the first place to look if after doing the above the situation is no better.
Renaming the SDBCache.bin file to something along the lines of SDBCache.bin.X (any name will do, as long as it makes sense to him and ideally as an addition after the .bin extension to make the renamed file one that the game won't even attempt to read) and loading the game again will create a new file---it'll take a while so a subsequent re-start of TS will be needed to see if that clears things up at all.
We know that existing content will/should run OK in 64bit so as it loads in 32bit there can't be much amiss. That doesn't of course preclude something in the cache or one of the scenarios *upsetting* the 64bit routine so we can't take it as a certainty. If it still loads slowly, removing half the routes and testing again would be the next step. If that suddenly causes the game to load in 64bit as fast as it does in 32 then there could be a dodgy file amongst the half of the routes that have been removed, so put half of those removed routes back in and test again.
If, on the other hand, the loading time in 64bit is still too long, then remove half of the remaining half of the routes and test again. Eventually he should end up with a half of something that makes a big difference to the loading time, which narrows the search for an answer down dramatically.

That'll do for now....thankfully the clocks go back tonight so he's an extra hour to spend messing about with it...

[peterfhayes]

Gary's right

Sysinternal's tools are brilliant, but like all tools are next to useless unless you know how to use them and how to interpret any reports generated;

Absolutely spot on!
I recently analysed a railworks file for a colleague, (using ProcMon - Process Monitor) I had to wade through 32,000,000 lines of code and after 8 hours of searching and enumerable filters I came to the conclusion that the "error" was not going to be recorded in Process Monitor

The ones I use are ProcMon, Process Explorer, XPerf (when I am really desperate) and VMMAP. All take a lot of time to ascertain any results and they are most useful in detecting Windows based errors and usually won't pick up TS internally generated ones.

Great tools but very difficult to analyse successfully. - Not for the faint hearted.
pH

[shinymac]

Hi Everyone

Thanks for all your replies re this subject.

I know the solution to my friends problem isnt likely to be easy, but sadly I feel that all of the solutions offered so far, are beyond both of our skills to apply.

If anyone can suggest a simpler solution that MIGHT work, please let me know.

Thanks Gary and everyone else

Derek

[21C164FighterCommand]

Hi Everyone

Thanks for all your replies re this subject.

I know the solution to my friends problem isnt likely to be easy, but sadly I feel that all of the solutions offered so far, are beyond both of our skills to apply.

If anyone can suggest a simpler solution that MIGHT work, please let me know.

Thanks Gary and everyone else

Derek

How many Workshop subscriptions has your friend? Having too many will cause errors in the scenario database. For whatever reason, DTG never explained there is a maximum number.

In the Railworks folder there is a small executable called NameMyRoute.exe.
Run it, and it will produce a list of routes.
You'll find 'missing RouteProperties.xml' errors, for these routes are in packed in .ap format. But there should be Workshop or 3rd party scenarios listed still.
Click on each of the little [+] symbols to expand the listing of each route.

If you find any 'missing ScenarioProperties.xml', this means that particular scenario is corrupted and possibly broken.
If you find any 'reading ScenarioProperties.xml failed' errors, that particular scenario is most certainly corrupted.
I have a hunch the Railworks unzip.dll is faulty and corrupts scenarios.

However, the original Workshop scenario is still to be found in its zipped form in the cache folder: Steam\steamapps\workshop\content\24010, but you'll have to search for it using the UUID from the expanded listing by NameMyRoute.exe. The UUID is the large number, the first 8 values before the hyphen will usually do.
Unzip that scenario, and copy the Content folder into Railworks, overwriting the faulty content.
When done, click View => Refresh in the NameMyRoute window and wait for the listing to refresh. There should be fewer to no errors.

Delete any scenarios still listed as faulty from the route folder, or at least move them somewhere where you can examine the .xml contents.

Hope this cures some of the errors, as I find Railworks is sometimes taking very long op Updating and/or Saving Scenario Database, and often crashes with errors.