.
Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 38

Thread: Weird bug in TRS19

  1. #16
    Join Date
    Nov 2011
    Location
    United States of America, Tampa, FL
    Posts
    1,109
     

    Default

    Quote Originally Posted by horacefithers View Post
    After exiting TRS19 in my previous post, I ctrl-alt-deleted my way to the task manager and check to see if TRS19 had left anything running. It had. This was in the list of background tasks. There was nothing in the list of foreground tasks. Trouble is, I didn't verify whether or not this process existed before I started TRS19 this time...
    (pic removed)


    So I restarted windows then restarted TRS19 where I entered Surveyor with the same route file as used in the previous post.

    There were NO TRS19 background processes.

    I exited game from the Surveyor upper left menu (but Launcher still running).

    Still NO TRS19 background processes.

    So I start TRS19 and Surveyor one more time and Quick Drive into Driver.

    Still no textures, splines, or track.

    I Exit Game from the Driver upper left menu.

    Still NO TRS19 background processes.

    I quit out of Launcher and presto, a background process which task manager says is using 11.8% of the CPU (AMD 2950x) and 2GB of mem (out of 64GB installed).

    Now to try some non-BCSJ routes...

    HF
    As long as the launcher window is still open, it is still a foreground task. When this launcher is closed it then switches to a BG task. AFAIK, this is normal behavior and hurts nothing. Something to do with post app cleanup and storage I think.
    (-3-)y-~~

  2. #17
    Join Date
    Dec 2018
    Location
    United States of America
    Posts
    240
     

    Default Extended db repair helped a lot - NOT

    I'm running an extended database repair.

    An impressive task - it's using 1/3 of a 4ghz 32 thread cpu...

    Clearly there's a lot more going on here than in the "simple" db repair.

    After about 8 minutes it finished. Thank the Lord for nmve m.2 ssd drives!

    Starting up driver on version 304 (the first rev in which textures, track, and splines weren't present).

    Now there's NOTHING showing except white and sky.

    Running an errors/warnings report on version 304 in content manager shows 0 errors and 0 warnings after the route is scanned. Displaying all dependencies recursively shows no place where problems were found.

    Impressive. Really stinkin' impressive.

    The good news is that rev 303 still comes up in Driver and shows what it should be showing. So I'm only out 2 days of work plus the wasted time trying to recover the stoopid database.

    But is rev 303 (and some derivatives I was working on earlier today) safe to continue with? Or are there mystery defects in it that haven't shown up yet?

    Why am I bothering to route build when the environment is so stinking fragile?????

    Horace Ruffled Feathers

  3. #18
    Join Date
    Nov 2006
    Location
    Australia, Qld
    Posts
    5,515
     

    Default

    Sounds like some corrupt data somewhere. Check your backups folder (and search on restoring backups for guidance how to install the backups). Worth a shot.
    Tony Hilliam

    Got questions about TRS19? Click here for TRS19 FAQs

    Looking for answers to in-game functionality? Click here for help

  4. #19
    Join Date
    Jun 2013
    Location
    Port Noarlunga South Australia
    Posts
    1,213
     

    Default

    Quote Originally Posted by horacefithers View Post
    I'm running an extended database repair.

    An impressive task - it's using 1/3 of a 4ghz 32 thread cpu...

    Clearly there's a lot more going on here than in the "simple" db repair.

    After about 8 minutes it finished. Thank the Lord for nmve m.2 ssd drives!

    Starting up driver on version 304 (the first rev in which textures, track, and splines weren't present).

    Now there's NOTHING showing except white and sky.

    Running an errors/warnings report on version 304 in content manager shows 0 errors and 0 warnings after the route is scanned. Displaying all dependencies recursively shows no place where problems were found.

    Impressive. Really stinkin' impressive.

    The good news is that rev 303 still comes up in Driver and shows what it should be showing. So I'm only out 2 days of work plus the wasted time trying to recover the stoopid database.

    But is rev 303 (and some derivatives I was working on earlier today) safe to continue with? Or are there mystery defects in it that haven't shown up yet?

    Why am I bothering to route build when the environment is so stinking fragile?????

    Horace Ruffled Feathers
    I greatly sympathize,I suppose we all have to remember that this is computing, this stuff happens on occasions, but its a total drag when it does , i had something similar occur a few years back and lost about 4 weeks work as all creek splines disappeared over a 17 mile stretch. Took me a while to get the mojo back to remake all of that lost work , all that was left were white spline tracks which all had to be deleted and replaced. In retrospect, i perhaps made it better as i was then more experienced, but it was a real blow at the time. Now I back up every half hour and make a new version every day or so. However ,perhaps its not as final as the fire that destroyed the legendary Gorre and Daphetid layout....hope your backups work ok.
    WARNING! The Surgeon General has determined that the use of the simulator Trainz is highly addictive,

  5. #20
    Join Date
    Nov 2006
    Location
    United States of America, Massachusetts, Haverhill
    Posts
    25,409
     

    Default

    Quote Originally Posted by horacefithers View Post
    I'm running an extended database repair.

    An impressive task - it's using 1/3 of a 4ghz 32 thread cpu...

    Clearly there's a lot more going on here than in the "simple" db repair.

    After about 8 minutes it finished. Thank the Lord for nmve m.2 ssd drives!

    Starting up driver on version 304 (the first rev in which textures, track, and splines weren't present).

    Now there's NOTHING showing except white and sky.

    Running an errors/warnings report on version 304 in content manager shows 0 errors and 0 warnings after the route is scanned. Displaying all dependencies recursively shows no place where problems were found.

    Impressive. Really stinkin' impressive.

    The good news is that rev 303 still comes up in Driver and shows what it should be showing. So I'm only out 2 days of work plus the wasted time trying to recover the stoopid database.

    But is rev 303 (and some derivatives I was working on earlier today) safe to continue with? Or are there mystery defects in it that haven't shown up yet?

    Why am I bothering to route build when the environment is so stinking fragile?????

    Horace Ruffled Feathers
    Check for assets open for edit. Anything left open can cause that issue.

    In addition, let the data revalidate. Remember I said it has to be reindexed after the database repair (DBR) and cached since the cached information was flushed during the repair process. Once the data is indexed and cached, it will show up on the route again much faster.
    John
    Trainz User Since: 12-2003
    Trainz User ID: 124863
    T:ANE Build: 94829
    TRS2019: 98592

  6. #21
    Join Date
    Dec 2018
    Location
    United States of America
    Posts
    240
     

    Default

    I gave up on trying to resurrect the most recent versions of the BC&SJ. I went back to version 303 and started to redo the work that got lost.

    So far, so good. Surveyor and Driver have been working OK (except for Surveyor abruptly disappearing on me one time - but the recovery got back nearly all my unsaved changes since the most recent save).

    I hope there are no hidden gotchas in version 303 (now up to version 320 - I've been making a lot of saves in new files just in case)

    HF

  7. #22
    Join Date
    Dec 2018
    Location
    United States of America
    Posts
    240
     

    Default And I think to myself, what a wonderful world...

    With apologies to Louis Armstrong....

    Good news:

    I worked diligently for a couple of days and got the older version of the route updated to where it was before. Life was wonderful.

    Bad news:

    Then I installed a few new trains on the route, saved it under a new name and clicked for Quick Drive.

    Sigh... You guessed it. I'm back to the Driver screen being entire white except for the sky.

    Strangely Quick Drive worked on the route before I added the new trains.

    One of the trains was a Piper Cub (aeroplane). I removed that from the route, saved under yet another route name, and tried Quick Drive.

    No dice, so I tried double clicking the Default route. Still nothing. But upon exiting out of the program my little background task friend was running.

    Instead of ending this background task I'm letting it run...

    None of the new trains I added were anything I've not run before.

    Given the size of the route, 99 miles of mainline, a couple of branch lines and almost as many trees and other vegetations as the prototype Oregon has in real life, could I be knocking on the door of too much stuff for TRS19 to handle? The Task Manager sez it's using 2.4GB of ram, but all tasks running ATM are using only 18% of system memory (64GB). Cpu usage is also pretty low.

    Ya know, a feller dealing with this might find hisself getting kind of irate...

    Horace (still with ruffled) Fithers

  8. #23
    Join Date
    Dec 2018
    Location
    United States of America
    Posts
    240
     

    Default

    Here it is 12:56 AM the next day and the TRS19 background process is still grinding away doing heaven knows what using 11% to 12% of a 16 core Threadripper 2950x.

    If it's doing database repair as was suggested previously it must be one doozy of a repair job. Of course, it might just be doing Anitra's dance.

    Judging by some other comments in the TRS 2019 forum area, I'm not the only person experiencing the joys of recovering from major data corruption, either.

    It's beginning to remind me of a girl I once knew. Really, really pretty, but after a while it became apparent she came with some big problems.

    HF

  9. #24
    Join Date
    Jun 2013
    Location
    Port Noarlunga South Australia
    Posts
    1,213
     

    Default

    Quote Originally Posted by horacefithers View Post
    Here it is 12:56 AM the next day and the TRS19 background process is still grinding away doing heaven knows what using 11% to 12% of a 16 core Threadripper 2950x.

    If it's doing database repair as was suggested previously it must be one doozy of a repair job. Of course, it might just be doing Anitra's dance.

    Judging by some other comments in the TRS 2019 forum area, I'm not the only person experiencing the joys of recovering from major data corruption, either.

    It's beginning to remind me of a girl I once knew. Really, really pretty, but after a while it became apparent she came with some big problems.

    HF
    This is one of the reasons i've stayed with TANE, its been around longer, and generally SP3 seems quite stable ( now i've said this it no doubt will crash and i'll lose everything) . it may be you have a corruption as it should not take this long to repair, even big database installs of 100 gigs or so will generally sort themselves out after an hour or so. Did other routes run ok ?
    WARNING! The Surgeon General has determined that the use of the simulator Trainz is highly addictive,

  10. #25
    Join Date
    Nov 2006
    Location
    Netherlands
    Posts
    649
     

    Default

    Quote Originally Posted by horacefithers View Post
    ... really pretty, but after a while it became apparent she came with some big problems ...
    ... so recognizable ...

  11. #26
    Join Date
    Dec 2018
    Location
    United States of America
    Posts
    240
     

    Default

    I listed dependencies recursively for the version of the BC&SJ that I had fun with tonight (er, last night as it's now tomorrow morning...)

    I notched a strange coincidence:

    There were a bunch of dependencies with an install date of 16-AUG-2019 or earlier (on the 16th I installed a bunch of 2-bay open hoppers). These are now marked "modified" with a modification date of 22-AUG-2019.

    Does that imply that a third party tweaked some of those assets? Or did the DB repairs I attempted reset the modification dates? They're listed below. I really doubt that they all were updated on Aug 22 by human hands, but I don't know for sure.

    Also, for what its worth, I used the content manager filter described by John in the "strange effect" TRS19 topic to search for out-of-date items in my DB and it found none.

    When I searched my installed stuff for "obsolete and not built-in" I got a number of hits. I searched for more up-to-date versions assets marked "Open for edit, Obsolete" and installed them. Most of those seem to be JR freeware which got installed in the DLS.

    With the newer version installed, will the route automagically update to the newer versions or do I need to crawl around in a contents file and manually update them. I looked for a way to determine the actual KUID of an installed object in my route but didn't find a way to do so.

    HF

    Installed assets tagged "modified" and with 22-AUG-2019 modified date:

    <kuid:68926:300004> Steve Lerro Engineer
    <kuid:648132:101540> SP ALCo PA-1
    <kuid:421503:15012> 2bay hopper A.T.S.F.
    <kuid:648132:101542> SP ALCo PB Rebuilt
    <kuid:421503:15014> 2bay hopper ATSF
    <kuid:648132:89819> AAR Type B bogey
    <kuid:421503:15011> 2bay hopper UP
    <kuid:438995:1170> SP Baldwin #3299 2-8-2 Vanderbuilt Tender
    <kuid:103021:100050> Coupler Bogey Back 4-10-2
    <kuid2:103021:100114:1> 40ft Boxcar CN Late Leaf
    <kuid:68926:300002> Bill Klene Fireman
    <kuid:421503:15010> 2bay hopper UP Billboard
    <kuid:438995:1169> SP Baldwin #3299 2-8-2
    <kuid2:103021:100113:1> 40ft Boxcar CN Late Leaf Textures
    <kuid2:103021:100105:1> 40ft Boxcar CN
    <kuid2:103021:100104:1> 40ft Boxcar CN Textures
    <kuid:648132:89779> AAR Type B bogey - SP
    <kuid:278716:100976> Alco 244 V16
    <kuid2:648132:89734:2> Alco PA PB bogey black
    <kuid2:103021:10103:2> Red Corona
    <kuid:648132:89783> ALCo RS-11 SP
    <kuid2:103021:10102:2> Green Corona
    <kuid:648132:89782> ALCo RS-11 SP BW
    <kuid:156765:1509> Bettendorf truck high detail red
    <kuid:475197:100714> CNW Airchime M3 #1 - 3 Part
    <kuid:648132:101543> SP Train Indicator Numbers
    <kuid:68926:819047> SP GS-8 Whistle (3 Part)
    <kuid:103021:100903> Commonwealth Tender Truck Black
    <kuid:648132:89851> SP Depot CS-22
    <kuid:68926:819003> Cotton Belt L1 Drivers
    <kuid:103021:100990> SP 4-10-2 SP-2 Late
    <kuid:68926:819006> Cotton Belt L1 Engine Spec
    <kuid:103021:100993> SP 4-10-2 Drivers Disc
    <kuid:68926:819009> Cotton Belt L1 Enginesound
    <kuid:68926:819004> Cotton Belt L1 Pilot Wheels
    <kuid:103021:100992> SP 4-10-2 Pilot Truck
    <kuid:68926:819008> Cotton Belt L1 Tender Truck
    <kuid:68926:819005> Cotton Belt L1 Trailing Truck
    <kuid:103021:100051> Coupler Bogey Front 4-10-2
    <kuid:103021:100994> SP 4-10-2 Engine Spec
    <kuid2:38408:10050:1> CS Water 01
    <kuid:884720:9100001> hf_bcsj Custom 40' Boxcar - #1
    <kuid2:200687:120032:1> JR Generic House 1 Story w/Porch 05
    <kuid:884720:900000> hf_bcsj Custom 40' Boxcar Lib
    <kuid2:103021:10101:2> Incandescent Corona
    <kuid:200687:120094> JR Flag US 30ft 5x8ft
    <kuid:68926:81901100> SP GS-8 Tender
    <kuid2:200687:120044:1> JR Generic 1 Story House Simple 01
    <kuid2:200687:120045:1> JR Generic 1 Story House Simple 02
    <kuid2:200687:120046:1> JR Generic 1 Story House Simple 03
    <kuid2:200687:120028:1> JR Generic House 1 Story w/Porch 01
    <kuid2:200687:120031:1> JR Generic House 1 Story w/Porch 04
    <kuid:175455:100885> JR Small Tank Loading Platform
    <kuid:103021:100991> SP 4-10-2 Trailing Truck
    <kuid2:348207:100223:1> JR US Phonebooth 1a
    <kuid2:69593:49007:1> mesh library distanziatore
    <kuid:103021:100904> SP 4-10-2 Tender
    <kuid:467590:100841> SP 2472 6 Chime Whistle with Air Actuated Bell
    <kuid2:103021:10100:1> White Corona
    <kuid:68926:8190004> SP GS-8 Engine
    <kuid:103021:100039> SP Number Board Textures
    <kuid:103021:100052> US 6 Axle Tender 70 PSI

  12. #27
    Join Date
    Dec 2018
    Location
    United States of America
    Posts
    240
     

    Default I found an error in my DB

    I was updating an asset USA SP Class GS-4 Steam Engine kuid2_59906_4449_1.cdp

    There was an error loading dependency: USA SP Class GS-4 Engine Rear Bogey <kuid:59906:50011>

    Failed to load child images for texture file: 'sp_classgs-4_4_8_4_body.texture.txt'

    Could this be causing the troubles I was seeing?

    I took the version of the route that I had not installed three trains and a piper cub airplane and could open that in Driver. One of those trains had a GS-4 in it.

    I was then able to Edit Trains and add the three trains and Piper Cub and run them all without experiencing the white out.

    Question: Should all my locomotives and other rolling stock be installed in the session-layer? Could this be causing problems?

    HF

  13. #28
    Join Date
    Nov 2006
    Location
    United States of America, Massachusetts, Haverhill
    Posts
    25,409
     

    Default

    Quote Originally Posted by horacefithers View Post
    I was updating an asset USA SP Class GS-4 Steam Engine kuid2_59906_4449_1.cdp

    There was an error loading dependency: USA SP Class GS-4 Engine Rear Bogey <kuid:59906:50011>

    Failed to load child images for texture file: 'sp_classgs-4_4_8_4_body.texture.txt'

    Could this be causing the troubles I was seeing?

    I took the version of the route that I had not installed three trains and a piper cub airplane and could open that in Driver. One of those trains had a GS-4 in it.

    I was then able to Edit Trains and add the three trains and Piper Cub and run them all without experiencing the white out.

    Question: Should all my locomotives and other rolling stock be installed in the session-layer? Could this be causing problems?

    HF
    Definitely put all rolling stock on your session layer. There have been reports of issues with putting rolling stock on the route layer, but I have never experienced that. Sessions are things that are dynamic such as rolling stock, therefore, put the trains there. I believe in KISS and I've done it this way for years with zero confusion.

    If this content has been installed from CDPs, and it has been, it'll appear as modified in Content Manager rather than Built-in, Payware, or Installed from Download Station.

    It's possibility that this asset is corrupted, but that should not stop the program from working, or your route from loading, it may however, break a driving session by being missing. Delete this dependency and reinstall from your CDP. That will repair the asset since this should not have this error.

    Sometimes errors will appear in content after running an EDR. Viewing the errors and warnings generally will make them disappear. Why this happens, I don't remember as it was explained once to us ages ago.

    With my 1.5 TB of content, an EDR will take about 4 hours on my regular hard drive, therefore, your 100GB database shouldn't take as long to repair as it did. Hopefully your hardware is okay. There are things I can think of that can cause that off the top of my head: A full disk, a highly fragmented older-type disk, a failing disk, malware scanning, background processes other than TRS19 running - watching videos, listening to music, browsing, malware infections, etc.
    John
    Trainz User Since: 12-2003
    Trainz User ID: 124863
    T:ANE Build: 94829
    TRS2019: 98592

  14. #29

    Default

    Are you opening route for edit when you place the trains? If this is the case you also have a blank session attached and no allocated drivers. Quick drive takes you to the first driver allocated which is held in the session, not the route. Select your route and select a session that was used when life was wonderful and select edit session. Now add your trains and then go to quick drive. save all under the new name.

  15. #30
    Join Date
    Dec 2018
    Location
    United States of America
    Posts
    240
     

    Default

    John,

    The drives in question are ultra fast m.2 pcie/x4 drives.

    I don't think there's malware - I keep eset up to date.

    When things are working I periodically see hiccups in Driver playback (a slight hesitation).

    I'll move the rolling stock into there own layers.

    I manually ran a DB repair which took under 1/2 minute.
    Then I ran an extended DB repair which took around 5 to 10 minutes (iirc) and after which the no textures, track, or splines became the vast white fog with sky above.

    A while back, I ran into a problem when doing lots of large cut and paste operations (F5) the resulted in the program hanging. I recently (2 or 3 weeks ago) experienced this again. Because all this madness started when using the "move asset(s) into selected layer" when within selected rectangle I wondered if there was a relationship. I was able to create a test case that locks up the program on the third paste operation (copy, paste, paste, paste - locks up). I submitted a ticket on Friday and am waiting for N3V to come off their weekend and see if they can reproduce the problem on their end. However, it only seemed to happen with large routes and large copy rectangles. I couldn't get it to fail with a simple test case so I ended up including the entire BCSJ (earlier, working version) in the bug report.

    Question: What other things can result in a "modified" asset state?

    HF

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •