attract
attract copied to clipboard
mickelson
Request: default startup with corrupted attract.am
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?.
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?
Can you drag&drop your attract.cfg here that is causing issues please. I have one suspicion.
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)
Enable the intro, launch AM 50 times repeatedly and tell me if it crashed please ;)
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.
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. :(
It must be then some other unrelated issue. Just to confirm, you've had the intro video actually playing, haven't you?
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?
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.
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.
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.
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).
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.
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
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.
I've tried repeatedly, but unfortunately I was unable to reproduce the crash with your attract.am and script.nv
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.
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?
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.
Without a way of being able to reproduce the issue I cannot be of any help I'm afraid.
I'm going to change to 2.6.1 and I will let it run for >2min before cutting power for further tests.
Please keep in mind that cutting mains may cause myriad of problems with harddrive/windows write caching. It may not be even AM related.
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.
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:
- The game I last played is the current menu highlight
- The game from the previous powercut is highlighted
- 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.
I'm still trying to find a reasoning in cutting the power off before gracefully closing Attract Mode.
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.
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.
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