Romcenter

Hi

Version 2.70 beta 5 released
This update includes the romcenter.exe and datutil 2.14 from Logiqx (http://www.logiqx.com)

What's new
beta 3:
- Clrmame pro datafile support (through Datutil)
- registry replaced by ini file
- fixed french error messages.
beta 4:
- fixed a bug creating a crash during a fix operation.
beta 5:
- Fix sublist not working on previous beta. Datutil 2.14 can now generate sublists. See Logiqx utility documentation (included in datutil zip) and this topic.
- Fix 'index out of bound' when duplicates entries in datafile
- Fix troubles with '[]' in config.ini

Please test this release and report remaining bugs in the forum (http://www.romcenter.com/forum).

- Backup your files before using this version.
- Use the forum rss feed to stay informed of forum activity: rss.php

Note:
- Rc datafile generated by winkawaks 1.53 is corrupted. Use the Clrmame dat instead.

Installation:
- install version 2.62
- unzip rc270b4 and replace files in your romcenter folder

Backup your files before using this version.

Download:
- RomCenter 2.62 (2.5 MB)

- RomCenter 2.70 beta 5 (1 MB)

Hmmm, the "copy n" thing seems to have a problem... I was afraid of that....

The "copy n" is appended to the wrong files inside the zip. Also, file "copy 2" is named "xxx copy1 copy2" instead of "xxx copy2". Can you take a look at i pls?

At least we don't get the "index out of bounds" error any more...

I believe the "copy n" should exist in the name of the zip file and perhaps in all files that are included in that zip file. It seems that now, the "n" count is increased for each file of the same zip.....

The 'copy n' is added as soon as a rom with a same name than another one in the game is added to the database.

For example, if the datafile gives
pacman.zip
- pcmn.bin crc 12341234
- pcmn.bin crc 56785678

Then, romcenter will record
pacman.zip
- pcmn.bin crc 12341234
- pcmn copy 1.bin crc 56785678
At least, it should
I tested it on the tosec Sinclair ZX Spectrum and it was ok.

I will do some more test then

RomCenter wrote:The 'copy n' is added as soon as a rom with a same name than another one in the game is added to the database.

Well, the problem here is that in the dat file, there are 2 or more zips with the same name but with different CRCs so perhaps the zip name should have the "copy n" and the files inside it shout have the same "copy n" as the zip file.

Now, if there are two zip files, zip1 and zip2 which both contain a rom with the same name (i.e. rom1) but different CRCs, perhaps a different text should be added (i.e. "version n"), i don't know if it's needed or not.

In the first case, there are 2 zips with the same name probably containing files with the same name but different CRCs. What if you have both zips and you want to see them in RC? How can they exist in the same dir and how will they be shown in RC? In the second case, there are 2 zips with different name containing files with the same name but different CRCs.

Hmmm I believe the things I read above.
But and but again when I use beta4 I have no errors, with the same MAME (not the official) emu and the same dat ofcourse I have these problems:

Sorry I wrote Beta4 or beta5? I just forgot to login.

This is true what Wanderer wrote:
"there are 2 zips with different name containing files with the same name but different CRCs."

But beta4 hasn't noticed any problem only beta5!
Do we really need this kind of rom names: 266-v1d Copy 1.bin ?
Any idea?

Disable / enable the "copy n" function may solve the problem!


THX

Personally I'd take the view that two ROMs in related games (parent/clone) with the same ROM name but different CRC is a bug in the data file and should be corrected by the data file author. I know that there aren't any such problems in my data files.

With regards the matrimbh problem above, that is a bug in the emulator itself... some kind of MAME hack. They should have renamed the ROMs so as to avoid what I refer to as CRC conflicts.

Logiqx

kispista wrote:But beta4 hasn't noticed any problem only beta5!
Do we really need this kind of rom names: 266-v1d Copy 1.bin ?
Any idea?

Disable / enable the "copy n" function may solve the problem!


THX

Well, the whole idea started in order to solve a problem so we do need this kind of rom names . It seems that it's a little tricky to implement though. Let's wait for Eric to take another look at it and see what happens...

Wanderer, the 'copy n' trick is only needed on roms. Two files with the same name are the same file. The problem raises when two roms have the same name in one zip.

You can't have two roms with the same name on a zip file. You can drop one of them, or rename it to store it. I choose the second solution.
Of course, if you have that second rom, your emulator could not find it because the name doesn't match... Like Logiqx said, the solution is to ask the author to fix the dat, or fix it yourself. These roms problems comes from datafiles, not romcenter.

Neogeo, cps2, cps1 and mame datafile works without problems.

For the matrimelee problem, I don't have that datafile, so I can't test. But you can trust Logiqx on that one.

Note also that you can use the 'split' or 'un-merged' mode to bypass the problem...

Wanderer wrote:Also, file "copy 2" is named "xxx copy1 copy2" instead of "xxx copy2". Can you take a look at i pls?

Which datafile did you use ?

I created the "Comodore Amiga CD32 Games" from TIM. I had a zip file which contained 1 iso, 2 wav and 3 cue files. In the infos column, RC reported that the correct name of the iso was "blah Copy1.cue", the correct name of the 1st wav was "blah copy1 copy2.cue" and one of the cues had as filename "blah copy1 copy2 copy3.cue". If you wish i can email you the dat file and a png with what i see (can't upload them anywhere at the moment).

RomCenter wrote:Wanderer, the 'copy n' trick is only needed on roms. Two files with the same name are the same file. The problem raises when two roms have the same name in one zip.

Aha. Ok, now i can understand how you handle things.

RomCenter wrote:Of course, if you have that second rom, your emulator could not find it because the name doesn't match... Like Logiqx said, the solution is to ask the author to fix the dat, or fix it yourself. These roms problems comes from datafiles, not romcenter.

I understand all these. At the moment I just wish to check what i have so the "copy n" solution in order to be able to use the datafile properly is acceptable. I don't worry about the emulator for now.

RomCenter wrote:Note also that you can use the 'split' or 'un-merged' mode to bypass the problem...

I'll try it...

Logiqx wrote:Personally I'd take the view that two ROMs in related games (parent/clone) with the same ROM name but different CRC is a bug in the data file and should be corrected by the data file author. I know that there aren't any such problems in my data files.

With regards the matrimbh problem above, that is a bug in the emulator itself... some kind of MAME hack. They should have renamed the ROMs so as to avoid what I refer to as CRC conflicts.

Mike

Well, i'm talking about a TOSEC's TIM datafile. I understand things are still under development so i expected the datafile to have some issues (i.e. duplicate entries). Despite that and since other datafiles may have similar problems from time to time (like matrimbh ), it seems like a good opportunity to help Eric find a way to handle them...

Logiqx wrote:I know that there aren't any such problems in my data files.

Well, i have to say, you've been a great help with rom-management issues. Thanks for that.

Wanderer wrote:

RomCenter wrote:Note also that you can use the 'split' or 'un-merged' mode to bypass the problem...

I'll try it...

Yes, if you are in merge mode, you have no clones files, just one big file with all roms for that game and all its clones. If a duplicates rom exists, it will make some trouble.
If you split clones, you have less roms in zip, and less chances to raise such problems.
This is mainly for arcade datafile which have game/clone structure, not much for consoles datafiles...

RomCenter wrote:Yes, if you are in merge mode, you have no clones files, just one big file with all roms for that game and all its clones. If a duplicates rom exists, it will make some trouble.

Unfortunately, i had left the default selection when i used the data file, which is "Unmerged" so this will not work for me...

Do you want me to send you the datafile along with a .png of what i see (~30K attachment)?

PS: if i set the mode to "merged", i get a warning about the datafile having inconsistencies. The message however, ends at "Restart RomCenter in this mode to have more". Perhaps there is a 255 chars limit somewhere?

Yes, you can send me the datafile.
Thanks Wanderer.

RomCenter wrote:

Wanderer wrote:

RomCenter wrote:Note also that you can use the 'split' or 'un-merged' mode to bypass the problem...

I'll try it...

Yes, if you are in merge mode, you have no clones files, just one big file with all roms for that game and all its clones. If a duplicates rom exists, it will make some trouble.
If you split clones, you have less roms in zip, and less chances to raise such problems.
This is mainly for arcade datafile which have game/clone structure, not much for consoles datafiles...

About my problems. The matrimbh is a hack of matrim ofcourse. Both of them have 266-p1.bin and 266-p2.bin with different CRC-s.
Matrimbl and matrimbh have 266-v1d.bin and 266-v2d.bin also with different CRC-s. The datfile was created by the RomCenter.
No help if I use merged, non-merged or split roms.

RomCenter build the datafile from your emulator (a special build of mame or kawaks I presume). This datafile shows that this emulator have bad filename informations.
There is nothing I can do about that. You can't build that romset according to datas from the emulator.
The temporary solution is to rename the duplicated files, and it is what romcenter do.
The real solution is to contact the emulator author and fix the problem.

RomCenter wrote:Yes, you can send me the datafile.
Thanks Wanderer.

I got it, and fix the problem.
As this is not a critical error, I will wait for more fix (if any) to release a new beta, or the final version.

RomCenter wrote:

RomCenter wrote:Yes, you can send me the datafile.
Thanks Wanderer.

I got it, and fix the problem.
As this is not a critical error, I will wait for more fix (if any) to release a new beta, or the final version.

Ok Eric. Thanx.

hi! any time I try to load the dat file from kawaks 1.54 I get a violation error
I have a pic of my desktop but cannot attach it. if someone could help!
thanks,
almacorse[/img]

Hi, just for another idea :

possibility to declare a (one or more) folder as "Reference Folder"

Meaning if a set is ok in the reference folder, it will be mark as useless files in another folder.

And just need again a Recurse subfolders or something to add many folders at a time.

Thanks

Do Not know where write so write here.
Games database:
Garou: Mark of the Wolves (prototype) - (garoup)
263-p1p.bin c72f0c16 1.0Mb
At blow героем overhand leg occur malfunction to emulations.
Solves a problem:
263-p1p.bin 0b23e2cb 1.0Mb

Excuse please the my english pronunciation.


Michael_k russian.

RomCenter wrote:As this is not a critical error, I will wait for more fix (if any) to release a new beta, or the final version.

Hmmm, it seems it is a critical error for me. I'm currently trying to fix some files i have using datafiles with those problems but RCb5 messes up things. Are you planning to release an updated beta or a final version soon?

Due to the number of bugs, I will post again a beta 6.

It will look for following bugs:
- Multi 'copy n' bug (fixed)
- Drag and drop explorer lock (not yet fixed)
- Path overflow in ini (fixed)
- Mamezip direct renaming (not yet fixed)
- Datafile Web interface not working (fixed)
- [DISKS] section support in datafiles (fixed) (It does not mean chd support...)

Tell me if I forgot some...

Mamezip problem is not easy. I use a function I didn't write myself, and the bug is located in this function. I mailed the author about that and I hope I will get a solution...

Logiqx, disks section in datafile is handled, but the chd is processed like a standart rom in romcenter. It means that rc will try to put it inside the zip...
I don't know if it's worth to spend time on that, knowing that I will include this support in the major rewrite of version 3.0.

RomCenter wrote:Mamezip problem is not easy.
<SNIP>
I don't know if it's worth to spend time on that, knowing that I will include this support in the major rewrite of version 3.0.

Hmmm, a rewrite... I assume it will give you the chance to make improvements to RC more easily than now. It will probably take quite some time though. Do you think you'll be able to implement a few small and quick wishes before you start the rewrite? It would be great if we had them...

viewtopic.php?t=1121
viewtopic.php?t=1224
<any other small&quick wishes>

Thanx.

Yes, ok, I will also add these improvments.

mamezip renaming fixed.