Romcenter

It seems the merge and rename processes are specially slow. I will analyse the database queries involved to see what's wrong.
I'm also currently moving the 'rename files' operation to the multithread engine.

I will publish an update (3.42) as soon as possible.

subzero1155 wrote:What has changed since the old 2.71 I used to use.

Actually, quite a lot. There's a new engine, using an SQL database now. Datafiles are not used directly anymore. They are actually "converted" to databases instead.

Granted, i don't have much time to regularly use Romcenter anymore but i've worked for quite some time with versions in the 3.x series under Win2K and WinXP32 and i've seen a pretty good performance. Better than the 2.x series anyway.

subzero1155 wrote:Also, should I move this over to the bug forum? When I originally started this whole thing it was like 3am and I don't think I was firing on all thrusters when I created the post. I feel like I'm dirtying up your Wish List thread.

You're right, this does not belong in the wishlist.

Administrative action: Posts split from "Wishlist" thread.

What is the reason for this though I wonder? What has changed since the old 2.71 I used to use. A large ROM set would understandably take a long time to work with, but it always seemed like it was moving along at a fair pace throughout. As I stated in a previous post it seems like something is happening during the process 'Analyse new files' that is compounding over time or gets worse the more files it continues to handle. When I first begin my merge which as you can see below has at least gotten into the I's now that command takes maybe 3-5 seconds, but as of this moment this is how the log is going.

Merge rom ipminvad1.zip\b1g/b1g with roms\ipminvad.zip/b1g
Merge rom ipminvad1.zip\b2f with roms\ipminvad.zip/b2f
Merge rom ipminvad1.zip\b3f with roms\ipminvad.zip/b3f
Merge rom ipminvad1.zip\b4f with roms\ipminvad.zip/b4f
Merge rom ipminvad1.zip\b5f with roms\ipminvad.zip/b5f
Merge rom ipminvad1.zip\b7f with roms\ipminvad.zip/b7f
Merge rom ipminvad1.zip\b9 with roms\ipminvad.zip/b9
Analyse new files - Start Time 8:43:15 PM

The program now sits and hangs unresponsive for a total of 5 minutes and 15 seconds and comes back alive at 8:48:30 PM where we receive the following messages.

Update date and size of file roms/ipminvad.zip
Delete file roms\ipminvad1.zip
Merge rom iqblocka.zip\cg.u7/cg.u7 with roms iqblock.zip/cg.u7
Merge rom iqblocka.zip\speech.u17/speech.u17 with roms iqblock.zip/speech.u17
Merge rom iqblocka.zip\text.u8/text.u8 with roms iqblock.zip/text.u8
Merge rom iqblocka.zip\v.u18/v.u18 with roms iqblock.zip/cg.u18
Analyse new files - Start Time 8:48:37 PM

Again, the program is unresponsive for 5 minutes and 9 seconds. Slightly less, but still not good. It then updates the date and size of iqblock.zip and deletes the file iqblocka.zip before merging another set into a parent, begins analysing and hangs. This is how it goes and I would assume is going to continue to get worse.

Also, should I move this over to the bug forum? When I originally started this whole thing it was like 3am and I don't think I was firing on all thrusters when I created the post. I feel like I'm dirtying up your Wish List thread.

Try to clean your dat (menu tools/clean db).
This export datas from your db, get a clean empty db and re-import datas.

I notice the merge and rename are quite slow and I will move these two operations in the multithread framework for rc 3.50.
This will speed things a lot.

subzero1155 wrote:I am now running the program using 'Run as administrator' to execute (which is amusing since the account I run primarily has administrator credentials anyway)

Yes, it seems that in Vista+ OS's, an account having administrative rights is not as powerful as the Administrator account. Supposedly, it's more secure that way...

I went ahead and stopped the audit since it was moving so slow (see Edit in post above on that). I then ran the remove zip comment command on 1943kai.zip and it completed successfully. Then proceeded to run it again on the remainder of what was visible on the screen and was successful and finally ran it on the entire romset and it also completed successfully with the following message.

Done. Zip comments removed: 7397 in 0h 0m 27s

Now that's what I'm talking about So perhaps the access violation yesterday was a fluke?? I don't know, but the audit is still running very slow. I will start it again in 'High Priority' and see if that has any effect.

Hmm.....I just closed the program while it was doing nothing at all to restart it and Windows acted as if it had crashed by my clicking the 'X' in the upper right of the window. I told it to go ahead and close the program and then got this unexpected message.

Application Error
Exception EAccessViolation in module romcenter.exe at 00000000.
Access violation at address 00000000. Read of address 00000000.

Edit: It would seem someone has already been through this ... imagine that. I'm obviously retarded. I am now running the program using 'Run as administrator' to execute (which is amusing since the account I run primarily has administrator credentials anyway) and with romcenter.exe set to 'High priority' in Task Manager. It is running well at the moment, but time will tell at this point.

viewtopic.php?f=2&t=2036&p=6703&hilit=a ... ator#p6703

When it crashed was just after I first installed 3.71 and I noticed my ROMs still had all their zip comment even though I swore I already had 3.70 complete that task. When I asked it to do it, it errored out almost immediately as shown with the screenshot of the program having Access Violations along with the crashlogtop / middle / bottom shots. That specific event is those 4 pics. Once I relaunched the program and decided to try an audit (which is still running and made it to the Cs' ) I did notice that the command to remove the zip comments successfully got to 1943kai.zip before it crapped out . This is also noticeable in the shot of the log in romcentercrash.jpg.

I will try the remove zip comment again once this audit completes which could be awhile since I'm having it change a split full MAME romset to a merged MAME romset. I will update when I am able to attempt it again. I will say though it is still taking awhile - it seems like between every operation it is showing 'Analyse new files' in the log which causes it to sit for awhile every time it comes up. Is this necessary or is there an option to disable it from happening or at least happening so often?

Edit: Well, it hasn't locked up completely yet, but is running very slow. After sleeping for 8 hours and letting it run overnight I got back up and it is just now past digdug.zip and the 'Analyse new files' process after each merge seems to be taking several minutes to complete before it moves to the next .zip file. I can't say for sure because I don't have a stopwatch on it, but I would guess the problem is compounding over time.

Thank you very much for these screenshots.
After a google search, it is a known problem, but the solution is unknown.
Does it happen on a special file ? only during zip comment removing ?

Hello,

This is the poster above that was having some problems on his Core i7 / Win64 setup. 3.41 continues to crash. The following shot of the program itself crashing is the first operation I tried to perform which was to erase all Zip Comments in a directory of ROMs. In addition I have included shots of the event log errors.

I hope this isn't too troublesome and if you have any questions or would like any more info that I could provide let me know by some means or another.

Edit: Now that I've said that, of course, the new version seems to be moving through a MAME ROM audit at an expected pace. I don't want to stop it while it's on a roll so I'll try the zip comment command again when it's finished and see if it hangs the program up again.

I don't see why.
But maybe ...

RomCenter wrote:Yes, give a try to 3.41.

I will try myself to fix a several gigas collection to see how it goes...

guest wrote:...now I am running a Core i7 920 with 6GB RAM and Win7(x64)...

Maybe the fact he is using Win7x64 is causing the delays he describes...

Yes, give a try to 3.41.

I will try myself to fix a several gigas collection to see how it goes...

guest wrote:At its current speed I would guess it would take me 3-4 weeks to finish auditing a full MAME set with Romcenter 3.70.

guest wrote:I am Eagerly awaiting 3.71, but am suspect the problem I am experiencing will persist.

Wow, talk about a trip to the future...

Eric has just released RC v3.41. Maybe you wish to try this version and see how it goes...

I had strayed from keeping my ROMs audited for quite awhile though I did use RomCenter back around the 2.7 releases.

I've been trying to get back on the ball and catch up with my MAME ROMs and RomCenter's performance is abyssmal. I start a fix command on my directory so it can reorganize a set the way I want it to be so I let it run overnight and when I get back in the morning the program has hung up after doing very few files. So, I babysit it and it seems to start moving at a reasonable pace, but seems to become more and more bogged down the further it gets and eventually becomes completely unresponsive and I have to kill the process. When I do so it still shows it is using 13% CPU in Task Manager and between 180-190MB of memory, but if it's minimized it will never come back up and if it is up and I click on it the window fades out, the title bar adds 'Not responding' to it and the program has to be shut down forcefully.

This program used to run great back on v2.7x on my P4 3.2GHz with 1GB RAM in WinXP even with some of the early CHDs in the mix, but now I am running a Core i7 920 with 6GB RAM and Win7(x64) and am not even auditing CHDs - just roms and samples - and the performance / stability makes the program borderline unusable. I am also using a brand new internal 750GB WD Caviar Black SATA2 HDD that I work with uncompressed video on so I know it's speed is not in question either.

At its current speed I would guess it would take me 3-4 weeks to finish auditing a full MAME set with Romcenter 3.70. If there's anything I can do to assist in testing please let me know because I think you've got a great tool, but something has definitely gone awry when it meets newer hardware / operating systems. Also, I agree with a previous poster about adding support for multiple threads. The 13% usage I mentioned earlier is the program locking up one of the 8 threads on my Core i7 (100%CPU / 8 logical threads = 12.5% which gets rounded up to 13 in Task Manager). I am Eagerly awaiting 3.71, but am suspect the problem I am experiencing will persist.