Print

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

[jurgen]

When trying to run clrmame or the rebuilder using crossover on mac (M3 Pro MAX), both programs terminate when they are changing files. The scanning is working but not fixing or changing files.

Any idea what I can try or czn you provide a new test version here?

Ps: I can run romvault with success on same Mac, on same roms...

[Roman]

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?

[jurgen]

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?

[Roman]

Use RomVault.

[jurgen]

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?

[Roman]

>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.

[Dixius99]

I've been occasionally trying clrmame in Crossover for the last several releases, and I've been getting a crash when completing a scan. For me, the issue does not appear to be related to if the file is unzipped or zipped.

The crash does appear to be related to specific files though. To test, I tried a few files at a time, both zipped and not zipped), and it seemed to be okay for the one or two that I tested. I tried adding more files to my ROMs folder, and got a crash.

Trying to narrow it down, I tried 100 files, which caused a crash. I then tried deleting the last 50 files in that folder, and testing only the first 50, and got a crash again. HOWEVER, I then tried deleting the first 50 files, and scanning the second 50 files, and the scan completed fine.

So to me, that would indicate there is something wrong with one of those first 50 files. Not sure what that would  be though, and not sure I can narrow down which of those 50 files is giving me the issue.

EDIT: just adding: I took the 100 zips I was testing, and unzipped them, and tried a scan, and that also did not crash! I then checked permissions on all of the files, and noticed most had read/write/execute permissions for user/group/public, but not all. I changed the permissions so they were read/write/execute for all individual files, and then rezipped, and again: no crash.

[Roman]

Well, 0.5 is around the corner which fixes some thread safety issues here and there....which could cause crashes...but rarely (however who knows when it is running in a crossover environment). But such errors would be more random.

Your information about the rezipped archives is interesting, however, the file flags inside an archive should not play a role at all since a normal scan only reads the file header structures inside the zip. But maybe the archives had general structural issues. This doesn't mean that the stored data is corrupt. In most cases you can unzip them perfectly fine. It means that zip related structures (local file headers, central directoy entries) are not ok. Rezipping fixes such things. Corrupt structures might have an impact on the used zip libraries. So it would be interesting to see such archives, maybe you can repeat your crash problem with 'some' and send me some examples.

[Dixius99]

I'll continue trying to narrow down which files are causing the issues, and I'll also see what happens when 0.5 comes out 

[Dixius99]

I just want to add that after spending a few hours testing, I'm having a harder time tracking down any specific, repeatable issues. A lot of that has to do with my testing methods, and even my testing environment.

• Shortly after posting last, I noticed I was running clrmame 0.31. Updating to 0.4 appeared to stabilize things already.
• I was able to test the whole 100-set test group with no issues.
• I was also able to increase the sample size up to several hundred before I got a crash again.
• Changing the number of threads (down from auto to 4) also appeared to have a positive impact on the crashes I was seeing.

Now, I'm completing a scan for my ~1,300-set collection in Crossover with no crashes. As an aside, it is also really fast, around 4 seconds for this scan.

I think from my testing, it is just too soon to troubleshoot this any further. And if users see a crash, it's probably best to just drop the number of threads and see if that helps.

[Roman]

If it's thread related, it might be fixed in 0.5 already since there were some potential reallocation/dangling pointer issues....so maybe you can do some retesting later...

[Dixius99]

For those using clrmame and Crossover, 0.5 is looking good. Crashes that I regularly saw on 0.31, and more seldom saw on 0.4 have not shown themselves yet. And I have set the cores back to Auto; still not a crash.

I'm using a 2022 MacBook Air, with an M2 processor.

I've tried the Scanner on my collection of about 1,300 games, and it completes the scan in around 5 seconds.

I've tried the Rebuilder too, and it takes 1 minute 44 seconds to rebuild the same 1,300 zips into 2,300 new zips (which includes the partial sets it can create; still trying to figure out if there is a way to rebuild so the outcome is only complete sets).

I'll be using it as I go forward. If I run into any snags, I'll report back.

[Roman]

thanks for testing, nice to hear that it works flawlessly.....

[jurgen]

Would it be possible to choose a cross platform UI like QT or GTK and compile it for macOS too?
I want to get rid of Crossover and have a native ARM version.

[Roman]

It is planned to release the source when the main parts are done (eg Profiler)
Maybe I release the core (comparable to commandline level) earlier. I dont have the time to switch to Qt.

[jurgen]

I would be very interested in a command line version compiled for Apple Silicon, since I'm not a developer and can't compile anything.