Previous Thread
Next Thread
Print Thread
Joined: Oct 2007
Posts: 1
T
Teras Offline OP
Member
OP Offline
Member
T
Joined: Oct 2007
Posts: 1
Hello
I am running MAME OS X for the first time, so probably this is a stupid question, though I didn't find any info in the Docs/FAQ

When I start the application, it tries to update every possible ROM, making the application almost to freeze, not to mention that it is a painfully slow procedure.
Since when I click on the application, the cursor becomes a spinning ball, I am not even able to open preferences and see what to do.

How can I overcome this problem? Is there any way just to browse the ROMs I have in my directory and play these?

Joined: Jul 2007
Posts: 225
Senior Member
Offline
Senior Member
Joined: Jul 2007
Posts: 225
Think you have to just let it run its course once..
THEN itll free up so you can check the option NOT to audit at startup hehe.


Joined: Aug 2006
Posts: 423
D
Senior Member
Offline
Senior Member
D
Joined: Aug 2006
Posts: 423
You could try this command, from the terminal, before running it:

Code:
defaults write net.mame.mameosx AuditAtStartup -bool NO


-Dave


Joined: Oct 2007
Posts: 9
Z
Member
Offline
Member
Z
Joined: Oct 2007
Posts: 9
I liked that it did it, but I felt kinda impatient because I wanted to play a game as soon as the program opened

Joined: Oct 2000
Posts: 139
Senior Member
Offline
Senior Member
Joined: Oct 2000
Posts: 139
The ROM auditing is excruciatingly slow! Even ClrMamePro on my much slower PC can audit all of the ROMs in a fraction of the time that MAME OS X takes. I suspect there's some optimization that can be done here...

I have a MacBook Pro (Core 2 Duo 2.2GHz) and 394 romsets, and after ten minutes it's not even through auditing the Cs.



Joined: Mar 2001
Posts: 16,741
Likes: 28
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,741
Likes: 28
To be fair, notebook HDDs are quite slow compared to full-size ones and auditing is almost 100% disk-bound - any processor above 100 MHz will handle the calculation end of it fine ;-) That said, Dave's audit is quite a bit slower than the core MAME audit code used by baseline and SDLMAME.

Joined: Oct 2000
Posts: 139
Senior Member
Offline
Senior Member
Joined: Oct 2000
Posts: 139
It's still doing my initial ROM audit, more than an hour in... it's up to the Js now.

I noticed that even when it tries to audit a ROM that I don't have, for which no zip file even exists, it still takes 2-5 seconds to audit it and move on to the next...


Joined: Aug 2006
Posts: 423
D
Senior Member
Offline
Senior Member
D
Joined: Aug 2006
Posts: 423
Like RB said, it takes so long (even for ROMs that you don't have) because of disk access. Remember, there's no 1:1 mapping between game name and zip file name, so it's more than just a simple "file-exists" check. Then again MAME32 seems to fly through missing ROMs really fast, so I need to look at their code to see what they are doing. Maybe they're not doing a full audit.

Also, it takes longer than straight-up core MAME or SDLMAME because it's doing the work in the idle loop, when nothing else is active nor events are happening. So it doesn't just bear on full-speed ahead. The idea was to keep the UI usable, without spawning a separate thread. In practice, this doesn't seem to work so well, especially on slower machines like a PowerBook G4. I may use the osd_work stuff, but as RB said this is I/O bound so it's not much of a speed-up.

Yes, this all sucks. Yes, I know it. No, I don't have a solution right now, and probably won't before the next release. I'll probably just disable the update, by default. Sorry, but for now, we're just gonna have to deal.

-Dave

Joined: Oct 2000
Posts: 139
Senior Member
Offline
Senior Member
Joined: Oct 2000
Posts: 139
No problem! I appreciate all the effort you've put into this software, and it's a terrific version of MAME. Once I figure out all the angles of it, I'll work on some documentation for you.

Spawning a separate thread for the audit would probably be a really good idea, since all new Macs these days are at least dual-core, and therefore the audit wouldn't slow down the UI at all. (Aside from disk access, but you're going to hit that either way.)

Actually, is auditing necessary for MAME OS X to be able to figure out what games it has available, or is it only done to make sure the games will run? I don't think a time-consuming audit is necessary unless the user wants to verify his romsets. I think it'd make sense to separate the "check to see what games are available" (which only involves seeing what romfiles are in the zips) from the "make sure the romfiles have the correct checksums" (which is the time-consuming part, and should only be done if the user asks for it).


Joined: Oct 2000
Posts: 139
Senior Member
Offline
Senior Member
Joined: Oct 2000
Posts: 139
One more bit of information - on my Power Mac G5 1.8GHz (single), with no MAME OS X folder in Application Support to begin with, it takes MAME OS X thirty seconds or more for each game to determine that the game is not there at all.

And while it's checking each and every game, I have the spinning beach ball and MAME OS X is completely unresponsive. I had to force-quit it.

Edit: I put my 394 romsets into the right folder and ran MAME OS X... and then I decided to kill it five hours later 'cos it had only gotten up to the Cs. There's definitely something wrong with auditing. If I can get a chance soon, I'll have a look at the code.



Last edited by Brian Kendig; 11/09/07 05:13 AM.

Moderated by  Dave Dribin 

Link Copied to Clipboard
Who's Online Now
6 members (Praxis, Pernod, Duke, Dam0, 2 invisible), 31 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,933
Posts117,434
Members4,994
Most Online890
Jan 17th, 2020
Forum Host
These forums are hosted by www.retrogamesformac.com
Forum hosted by www.retrogamesformac.com