Request: default startup with corrupted attract.am

[jimbowley]

A hard power cut on PC sometimes causes a corruption of attract.am and at next startup Attract Mode won't open. Deleting attract.am and script.nv clears the problem.

Could you catch either the bad file or the bad exit and use a default startup position?.

[SpoonyAllen]

I seem to be having the same issue. I've done some discussion of this on the attract-mode forums http://forum.attractmode.org/index.php?topic=3897.msg27253#msg27253

It seems like the persistence read of the file is causing the issue. should the file only be read and written to immediately after the launch of a game?

[oomek]

Can you drag&drop your attract.cfg here that is causing issues please. I have one suspicion.

[SpoonyAllen]

Sure, here is the current attract.cfg as of last night.

As i mentioned in the AM forums, i get the crash bug about 1 in every 10 or so bootups. If i simply shut down and restart the cab i will continue to get the error. However, if i install a mouse and manually open attract mode, it won't crash but it will launch the first game on the list (005)

attract.cfg.txt

[oomek]

Enable the intro, launch AM 50 times repeatedly and tell me if it crashed please ;)

[SpoonyAllen]

LOL!

Heading for work in a bit. I will do this later this afternoon.

[oomek]

I was having issues as you described. It turned out an intro.nut is loaded even when it's disabled. I have the fix for you if enabling intro solves the crashes on your machine, just make sure you have a video inside intro folder and it's actually playing.

[SpoonyAllen]

i actually had an identical spare pc and SSD sitting here so i cloned the cab's drive and brought the backup upstairs. unfortunately setting the intro video to appear at startup does not help. :(

[oomek]

It must be then some other unrelated issue. Just to confirm, you've had the intro video actually playing, haven't you?

[SpoonyAllen]

yes, the video was left playing then AM crashed. I believe this has to do with the frontend constantly holding ownership of the file.

As i posted on the AM forums, i found that the Attract.AM was written to at sporadic intervals following the launch of a new game. The file would be written to anywhere between 50 seconds to 2 or so minutes following the game launch. This is probably some unintended consequence to having the ability to change settings directly from AM but perhaps only loading and writing to the file if Launch_last_game is set in the config and only immediately after launching a game may alleviate this?

[jimbowley]

I think attract.am is always open ( AM remembers which display/filter/game you are looking at in the menu) and that's why it can get corrupted on power cut.

I would like to see AM safely store the display/filter/game at game selection time, and then recover to that position if attract.am gets corrupted (or do some other scheme that makes AM robust against power cuts).

PS. I'm using 2.5.2.0 and haven't actually tested this since 2.0 or so. So there's a chance it has been fixed, but maybe that's unlikely as you are having the problem.

[SpoonyAllen]

JimeBowley

Thanks for posting this issue. Without your thread i would be going crazy second guessing my setup.

I am using 2.6.1 and I still have this issue. I do agree that there should be a sensible fix for this. It also makes me wonder if any raspberry pi owners have had this issue considering there are some turning on their cabs via the power mains.

[oomek]

How does the corrupted attract.am file look like? I would need one to reproduce the crash on my machine as I've never encountered this issue.

[SpoonyAllen]

oomek

I will attach both the attract.am and script.nv as soon as i can get it to crash. I have just been experimenting and i noticed that if i set script.nv to read-only AM does not crash but it will always launch the first game in the list (005).

[jimbowley]

I'll take a look to see if I can find one, but sadly I may not have saved it. Sounds like Spoony will be able to produce one.

[SpoonyAllen]

Here are my attract.am, attract. cfg, last_run.log and script.nv files from my most recent crash

attract.am.txt attract.cfg.txt last_run.log script.nv.txt

[jimbowley]

I'm sure my corrupted attract.am file had some whacky characters in it but maybe that's a false memory based on what I'd expect to be in a corrupted file.

I'm just building a fresh win7 machine and then I'll do some powercut testing with it and bring back the results.

[oomek]

I've tried repeatedly, but unfortunately I was unable to reproduce the crash with your attract.am and script.nv

[oomek]

The file structure looks perfectly normal to me though.

[jimbowley]

Early testing results (and my preliminary conclusion).

AM version 2.5.2.0 After power cut AM starts at display 1, filter 1, game 1 (0,0,0 in AM indexes) Examination of attract.am after powercut shows it is empty.

I don't think that was the case with AM 2.0 (ie the file wasn't empty after powercut) so I suspect something changed between 2.0 and 2.5.2.0, effectively what I asked for above had already been done but I was using an old version (due to other problems).

I will powercut my system another 100times just to be sure. But certainly if the behaviour is now to write an empty file to attract.am and then write the proper file at exit, then that looks robust against powercut.

I'd still prefer to have the file written and closed after each Display change, but that's just a nicety.

[jimbowley]

This doesn't solve Spoony's problem, but it should encourage him that win7+AM can be powercut reliably, at least when AM is called from windows explorer shell(???). Shelling into AM might be different?

[SpoonyAllen]

JimBowley

I found that unless you run the game for anywhere between ~50 seconds to 2 minutes, attract.am won't be updated and AM will not launch the game when you boot up the following time.

I am not replacing windows shell with AM. I simply dragged a AM shortcut to my startup folder. I tend to no longer shell windows because it just makes it more annoying when i need to modify something.

[oomek]

Without a way of being able to reproduce the issue I cannot be of any help I'm afraid.

[jimbowley]

I'm going to change to 2.6.1 and I will let it run for >2min before cutting power for further tests.

[oomek]

Please keep in mind that cutting mains may cause myriad of problems with harddrive/windows write caching. It may not be even AM related.

[jimbowley]

After turning off write caching my win7 HDD system was 100% reliable in powercut testing (samples >100) that was 2years? ago. I've not tested the SSD system which is why I'm happy to do it now.

[jimbowley]

with 2.6.1 I did 5 tries of calling a game and cutting power about 5 to 10 seconds later.

On restarting I've hit 3 different behaviours: 1) The game I last played is the current menu highlight 2) The game from the previous powercut is highlighted 3) Game1 Display1 is highlighted.

Here is the 'empty' file that gives 0,0,0 (it is 52 bytes of zero) attract.am.txt

But AM hasn't failed to start yet. More testing needed but it looks like my main worry could be solved.

[oomek]

I'm still trying to find a reasoning in cutting the power off before gracefully closing Attract Mode.

[jimbowley]

I can't control what my customers or the electric company does to the power supply. I could add a battery powered system shutdown but that's not cheap.

Example: Customer has a gamesroom with a big On/Off switch at the door that turns everything on and off.

Or: Kids turn Dad's machine on at the wall socket. After they've finished what are they going to do? Answer: Turn it off at the wall socket.

Those aren't reasons for cutting the power. But they are reasons for wanting the machine to cope with it.

[SpoonyAllen]

jimbowley

tests i ran showed that AM will not write to the attract.am and flag the last game played until anywhere between 45 seconds to 2 full minutes after the game was launched. I think this also plays into some of the issues. I know i have launched a game in order to play it later only to find out AM crashed on my next bootup.

oomek

shutting off mains power on mame cabs has been something that has been done since the dawn of mame. This goes back to classic arcades that were all powered up either by using a big kill switch or cutting power at the fuse breaker box. Attract mode still handles all of this wonderfully with the exception of these two files. I don't have customers but i have a garage full of real and mame powered cabinets. I chose attract mode in this case because AM just has better handling for vertical projects.

As i mentioned, if the handling of these files were changed just a bit, it would do a world of good for this feature. I come from other frontends. Nobody else has this feature. It's just in this scenario it does not work very well. My coding abilities are almost two decades rusty and I'm not here to tell anyone how to run the project. I just think a more simplified way of handling these two files would do a world of good. It is supposed to log the last game launched. AM seems to hold persistent ownership of this file for way too long and write to it a bit too late IMO. Simply logging the last game played, writing to the attract.am and relinquishing the file should greatly alleviate the issue.

[oomek]

Please use the following build and post your last_run.log after a crash or attract.am corruption. https://1drv.ms/u/s!Ag7uFeM0f_fziYRpclD4RzAARGkLwg?e=nRgXM9

[oomek]

Actually I will require also the last_run.log from the previous launch. Do you want me to make another build that saves last_run_old.log, or you are ok saving a copy of that file before executing AM?

[jimbowley]

No failures of my setup so far (N=20), so I changed my startup behaviour to: run last game. On the very first powercut I got a failure to restart. Note: I'm back to using 2.5.2.0 for the testing.

Here is the attract.am and script.nv It's the script.nv that is the problem. Sympton on win7 is a visual C++ runtime library error. I tried it on my win10 machine and also got an error but with no useful information.

attract.am.txt script.nv.txt

oomek, I'll see how frequent the failure is, and then try out the build you just posted (and collect the log files).

[SpoonyAllen]

The build you posted has not 'crashed' yet. I did noticed it does read attract.am much much faster. If i do cut off power following the launch of a game, it does default back to launching the first game on the list (005)

edit: I just did this behavior to see how well it holds. I opened up the folder containing AM and sorted all the files to show me the most recently modified files first. i toggled back to attract mode and launched a game. Then i waited a few seconds and toggled back to windows file explorer and noticed attract.am had just been modified then i shut down power right at that second. Attract mode fails to launch the last game but will continue launching the first game on the list.

[oomek]

Please post that logs I asked for, before and after the crash

[SpoonyAllen]

last_run_soft_crash.log attract_soft_crash.am.txt last_run_clean_boot.log attract.am_clean_boot.txt

[oomek]

I'm gonna need to do the same for script.nv as the attract.am is saved cleanly from what I see

[SpoonyAllen]

here is the latest crash (just happened moments ago) Script.NV has not been changed since yesterday but i included it anyway. I do appreciate all the work you've put into this so far oomek. 👍

attract_latest_soft_crash.am.txt last_run_latest_soft_crash.log script.nv.txt

[oomek]

I do not see anything abnormal here. I'm gonna prepare another build. In the meantime, just to be sure it's not the intro bug, replace please the following file ( remove the txt extension and overwrite the intro.nut file inside the intro folder )

intro.nut.txt

[SpoonyAllen]

No change with the new intro.nut in place attract_soft_crash_new_intronut.am.txt last_run_soft_crash_new_intronut.log

[oomek]

Here is extended logging, I don't believe that it will give any more insight as script.nv is read on the launch and file acces is then closed, then it's written when you exit am. These configuration files are opened to read/write only when it's required to read/save data as you can see in the log. I still strongly believe the disk caching has some role in that data corruption you're experiencing.

Anyways, please use the build from the following link and launch AM with the following commandline switches: attract-console --logfile log_1.txt --loglevel debug change the nr until it crashes, zip all the logs and attach to your post.

https://1drv.ms/u/s!Ag7uFeM0f_fziYRqiIqZVsk03I-vTg?e=D6L4GX

Please also disable logging in your layout.

[SpoonyAllen]

not sure how to disable logging in the layout so i just switched to another, more basic layout. soft crashed the first time around. As soon as it loaded 005 i just entered windows explorer with AM still running and copied the files.

script.nv.txt attract.am.txt log_1.txt

[oomek]

I would need to see the files and the log before and after the launch that leads to the crash

[SpoonyAllen]

Ok log_1_clean_boot.txt attract.am_clean_boot.txt attract_soft_crash.am.txt log_1_soft_crash.txt

[oomek]

After analyzing the log I've come to the conclusion that this issue is not attract.am related

[SpoonyAllen]

Not really sure what else could be causing the issue. I will say it is doing it significantly less and defaulting to the first game on the list is definitely better than a full-on crash.

[oomek]

Does this problem happen on any layout?

[SpoonyAllen]

yes

[oomek]

Can you reproduce the issue by force closing AM with a task manager in the same fashion as you would do it with a power button?

[SpoonyAllen]

Currently doing more tests now but it seems with your last build i've only been able to get it to 'soft crash' and load the first game one time so far using the task manager to kill AM. It seems greatly dependent on how fast i can get the task manager up to kill AM.

Ive been tinkering with both the vanilla build and yours all day. I am noticing that my chances of the last game loading greatly increases using your last build and doing the following: if i load the game up, leave it on for just over a minute, escape the game and leave AM idle for about another minute then shutting down power via the mains.

[oomek]

You got me confused with your terminology. What do you mean by saying soft crash?