[gpz]

This delay problem makes me wonder (without checking the code itself), which of the processes is doing the save. It mustn't be the Render or Updater, but looks like currently it is one of them. That's why the hang happens. It would be good to delegate this task to loader process instead.

[Csantucci]

Accordingly to Herb's logfile it's the Updater Process. The hang occurs in the loop of method ReportReplayCommands() at line 176 of CommandLog.cs. I tried to add a watchdog ping there every 500 commands saved, but I have problems with namespaces and similars, and so I am not able to develop a clean solution. I'm sure everyone that knows better how to behave with namespaces and similars would be able to make that in few minutes.

[atsf37l]

Keep digging guys! I know you're getting closer. Go Team! :bigboss:

[markus_GE]

What about making the replay feature work just like the log file? When something noteworthy happens (control changes, what have you) it´s simply written to a file on disk. That file can then be renamed, in order to preserve the data, or it will be overwritten by the next run. That way, we´d always have all control data recorded until e.g. a crash happens. That would of course leave the normal saves to be just a "snapshot" of what´s currently, in the moment of the save going one.

Taking the thought a little farther, what about two files to save it all - one snapshot file, written every time the save button is pressed, and one continuously written to that contains all the replay data, as described in the above paragraph (but specific to one session, without overwrites, and somehow linked to the "snapshot" saves, so one can e.g. "resume from snapshot xyz")?

I know this would mean major restructuring of the code, but in the end it might be worth it?

Cheers, Markus

[cjakeman]

markus_GE, on 22 December 2014 - 09:10 AM, said:

What about making the replay feature work just like the log file?

Good idea. When I added Replay I never envisaged the lengths to which our users would push Open Rails - Day 3 of a 3-day activity indeed. Herb rocks !

[R H Steele]

atsf37l, on 21 December 2014 - 07:48 PM, said:

If it were removed from the software it would probably speed up the saving process, particularly on day 3 of a three day activity on the north end of the RGS! Hit save and go make a sandwich! :pleasantry:

WHAT! Day three of a three day activity and you forgot to pack a lunch? Geeze. :rofl2: :clown: :crazy:

(and seriously, fasinating reading/watching you guys (OR Team) work it out. I know a solution will be found) Now if only someone can find a sandwich for Herb.

[atsf37l]

cjakeman, on 22 December 2014 - 11:09 AM, said:

Good idea. When I added Replay I never envisaged the lengths to which our users would push Open Rails - Day 3 of a 3-day activity indeed. Herb rocks !

Day 1, Ridgway to Telluride, switching out cars and making pickups along the way. Day 2, Telluride and Pandora mine switching and run to Rico. Day 3, Rico to Ridgway picking up cars left the day before. Now that we can make the clock run to the next day the sky's the limit! But the third day saves take forever!!! :pleasantry:

[cjakeman]

atsf37l, on 22 December 2014 - 04:46 PM, said:

Now that we can make the clock run to the next day the sky's the limit! But the third day saves take forever!

Tomorrow I'll build you a modified RunActivity.exe which skips the save of Replay commands so you can finish your activity while we work on a permanent solution.

[atsf37l]

Excellent, but I'm away from my computer for the holidays. I'll give it a go when I get back. :bigboss:

[cjakeman]

atsf37l, on 23 December 2014 - 08:14 PM, said:

I'll give it a go when I get back.

You (and anyone that needs it) can download it from Google Drive. It's based on v2736.

In exchange, I'm hoping that you will test out the bug-fix version once we get one. It's not everyone who has a 3-day activity saved so please don't delete any ones useful for testing.

Enjoy your Christmas break from the computer . . .