Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

I've been fighting this for like the last year, trying to figure out if it was my fault, the roms fault, etc...  but I'm certain I know what's going on now - so this is my attempt to explain it..

There is a game for the fm-towns and pc-98 called 'Pro Student G' - on the FM-TOWNS system, it had a secondary re-release with a slightly different disc.   
On the PC-98, *ONLY* the re-release was ever made available...

Mame relates the original release as the 'parent' and the re-release as the 'child' on FM-TOWNS....
However, since there is no original release on PC-98, the re-release is the 'parent'.   

clrMame seems to have a huge problem with this, considering they're both the same SHA/CRC.   So it SEEMS to be looking for a parent that doesn't exist, and gives errors about how the file is not right over and over.   Sometimes I can copy files around until it fools the system into going 'oh yeah', found it....  other times not.   

But my guess on what is going on here - the engine builds from the file up, and with the crc having different 'parents', it gets confused and looks for phantom files.   

Not sure if I can suggest a good fix...   I have considered writing a rom handler as well, but I was considering going 'top down' and building a list of needed files first, and then adding the file hashes to that list, and then building the zips that way.   It would reduce the number of times it scans a zip to once (which would be nice for when there are multiple sets in a single zip), but it probably would require a sqllite database or something to hold the relationships, as it may be such a large ram requirement, most people couldn't use it.  Not sure.   You've created one, so you would know better than I.    

Anyway, am willing to provide logs or whatever if needed. 

Rodimus

Hi, I don't find the rom of this game (sspeedr.zip zipped name).
Always rom with missing file.
Can someone send me the link with the working version?
Thanks.

I have the same error as you. I don't know how to handle it?

>No other things I can try?

Well you can try what I've told you, unfortunately you did not give too much details on your tests, so here again:

Try the 3 cases.
Start with an empty rompath, add one set with 1 wrongly named rom file.

1st test case: keep the set as folder/file
2nd test case: use a zipped set
3rd test case: use a 7z set

The scan should find the wrongly named rom (inside the folder / inside the archives) and if fix options are enabled, it tries to fix it. According to your post, modifying causes the exit. So try all 3 cases. Which one fails?
Instead of having one wrongly named file inside the archive/folder, you can also add a random file to it, which should appear as unneeded and fixing them would also cause a modification step. Let's see if that works.
You can post screenshots of the scanner windows where it lists (when fixing is off) your test case result, so I can have a look if that setup is ok already.


>Is there a way you can make a Mac version?

As the readme states, new scanner/rebuilder will get open source if they are done.
So you can try to get it compiled on a Mac.

Use RomVault.

No other things I can try? I would like to use both tools because they offer a different experience/features.

Is there a way you can make a Mac version?

https://mamedev.emulab.it/clrmamepro/binaries/rebuilder_v007.zip
https://mamedev.emulab.it/clrmamepro/binaries/readme.html


- fix software list rom sizes determination (wasn't limited to loadflag value)
- fix software list merging (SL/SL collections don't use merge attributes, so lookup by hash in a parent/clone relationship)
- don't use # in default pattern (rompath) names since such names would be cut off when used in mame.ini due to comment handling
- pattern names can't end with '.' (Windows doesn't like this), replaced cases with "_"
- minor changes to the stats count output
- updated 3rd party libs (spdlog, bit7z, pugixml)

4.048d
fixed: softwarelists can lack some possible mergings
fixed: possible assertion during delta checks

Is there a next version yet?

Use RomVault.

I never use compression since I have an expandable ThunderBay Flex which can store up to 172 TB (Currently 18 TB installed only). It's connected using Thunderbolt 3 (5000MB/s) so the speed should not be any problem too.

I logged in as root and no difference. The same for rebuilder.
All files are accessable as far as I know.

So what can I do?

Sounds like an access rights problem.
But it's more interesting to know which files you're touching. zip? 7z? decompressed files/folders?
Since all 3 use different methods:

7z -> 7z.dll  (3rd party component)
zip -> ziparchive class (3rd party component)
decompressed files/folders -> std::filesystem / win api (depending if you're talking about the new rebuilder or cmpro)

So, simply test all cases, take a rompath with just 1 machine set, make it a 7z archive, a zip archive or use it decompressed.
...and check general access rights to that rompath. Are there differences between the new rebuilder and old cmpro?