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

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

1

clrmame Discussion / Re: Questions...

« on: Today at 07:34 »

1) chd version mismatch check will come soon in clrmame. SHA1 check won't solve the problem

2) Hmm..no, actually it detects the old ones as unneeded and sees them as fill ins for the "new" megacd. They get 'moved' to the new place. However, maybe you did not do a clean install of your MAME hash folder and still got the old hash files in their. clrmameui first takes all from -listsoftware and then scans the hash folder for additional ones which are not listed in the xml output (there are a couple which aren't included for whatever reason). So if you don't clean MAME's hash folder before unpacking the new version over it, you still get the old ones in there and clrmame will read them in as additional sl.

3) ? weird one. Unless the samples folder isn't listed as backup folder somewhere. You could check the settings.xml file for this....but the screenshot doesn't correspond to that. Is there a repeatable small scenario for it? I can try to build one based on that screenshot....

2

clrmame Discussion / Re: Impropper Handling of "wrong merged" Moves

« on: 01 April 2025, 11:23 »

What do you mean in detail?

If you get a "wrong merged ROM set" message it means that you use full merged sets and have a clone set somewhere which shouldn't be there since in full merge mode, all clone files need to be placed in the parent set and the clone set itself doesn't exist. The parent set isn't moved.

Maybe you need to give a detailed example....and actually I don't understand your 7z file updates comment...

3

clrmame Discussion / Re: Problem Scanning an SMB Volume

« on: 26 March 2025, 15:04 »

looks good ...check if the rompaths are fine....the input fields are rather small in width but can hold multiple long values which might be hidden

4

clrmame Discussion / Re: Problem Scanning an SMB Volume

« on: 26 March 2025, 12:43 »

You can't mix -listsoftware and -listxml collections when it comes to rompaths.

So assuming you start with a -listxml (standard) mame export, you have rompath(s) and somewhere in it, there is the ngp.7z archive. Fine so far, since the -listxml output lists a machine name="ngp" sourcefile="snk/ngp.cpp" entry with a ngp_bios.ngp rom file in it.

When it comes to software lists, "ngp" specifies a softwarelist which contains all kind of NeoGeo Pocket machines.
So here your rompath should point to a folder which has ngp as a subfolder (and of course others like a2600, c64_cart, etc) representing this software list...and inside that ngp subfolder you have the software list entries for that software list.

So actually you should double check your rompath setup (as described above they should point to different paths).
If you like you can also send me your settings.xml and copy/paste the log output.

You can actually check where your ngp.7z is stored.
The softwarelist "vgmplay" does have a npg machine in it...so in a vgmplay subfolder there should be a ngp.7z, nowhere else when it comes to the rompath (and subpaths) connected to the -listsoftware output.

When talking about -listxml: you should have 1 npg.7z in one of your assigned rompaths.
When talking about -listsoftware: your rompath should have a subfolder named ngp but a ngp.7z should only be in a subfolder vgmplay since it's a part of that software list. Maybe you have some copies floating around elsewhere which cause the problem.

5

clrmame Discussion / Re: Problem Scanning an SMB Volume

« on: 25 March 2025, 20:40 »

This sounds a bit like you have compressed all ngp software files into a ngp.7z.
You need a folderstructure like: your_drive:\your_rompath\ngp\ and in that ngp folder you've got the single ngp software list machine, so e.g.
bstars.7z, kof_mlon.7z, etc...(or zip or decompressed).

so for example:
f:\mame\roms\softwarelist (as your one and only rompath which is the
root of the single software list subfolders)
f:\mame\roms\softwarelist\a2600  with
f:\mame\roms\softwarelist\a2600\2pakblac.zip,
f:\mame\roms\softwarelist\a2600\2pakblaca.zip and so on
f:\mame\roms\softwarelist\c64_cart with
f:\mame\roms\softwarelist\c64_cart\4thsarc.zip and so on...

6

clrmame Discussion / Re: CLRMamePro changing *.dat file attributes to hidden?

« on: 21 March 2025, 06:30 »

Ah....the datfile in the zip file seems to have some uncommon file attributes set (most likely it was built on an unix machine) which seem to generate a +h on Windows systems (at least when zipclass library extracts it, the internal Windows unzip seems to use some standard attributes then).

So...I blame the file in the zip

7

clrmame Discussion / Re: Problem Scanning an SMB Volume

« on: 21 March 2025, 06:30 »

With "I can't even reconnect in Explorer" you mean Windows, not clrmame, right?

Maybe you can also try to use the UNC path of the share directly instead of a mapped drive (e.g. \\fileserver2\roms) ... but before that it should work in the explorer though (e.g. when it needs authorization...)

8

clrmame Discussion / Re: Problem Scanning an SMB Volume

« on: 20 March 2025, 18:13 »

damn....I thought that long path prefix would be the solution.....thanks for testing

9

clrmame Discussion / Re: CLRMamePro changing *.dat file attributes to hidden?

« on: 20 March 2025, 12:56 »

clrmamepro doesn't alter filter attributes to hidden anywhere.
There might be cases during a scan where rom/sample files/archives or files inside such archives get their file attributes altered. But only +a, -r.
Datfiles or settings files' file attributes aren't touched at all.

10

clrmame Discussion / Re: Problem Scanning an SMB Volume

« on: 17 March 2025, 07:56 »

ok, here is a custom version (just the exe file) where long path name support is disabled:

https://mamedev.emulab.it/clrmamepro/binaries/shortPathOnly_clrmameUI.zip

would be interesting to know if that is the reason for failing on your SMB client setup

11

clrmame Discussion / Re: Problem Scanning an SMB Volume

« on: 16 March 2025, 19:06 »

Actually I found some information in the internet that the long path name support could be the reason why it fails on SMB client drives.
clrmame automatically adds \\?\ prefixes to paths so that 32k full path length is supported. Asking chatGPT about possible problems comes back with:

"Yes, there are known issues when using std::filesystem with SMB (Server Message Block) client drives, especially when working with long paths and the \\?\ prefix for long path support in Windows.
Here are some key points that could help clarify the situation:
The \\?\ Prefix: The \\?\ prefix is used to enable long path support on Windows, and it is required when working with file paths longer than 260 characters (which was previously the maximum path length in Windows). This prefix is often used for paths that exceed the traditional MAX_PATH limit, and it bypasses some of the legacy file system API restrictions.
SMB and \\?\: The \\?\ prefix is not always well-supported with network shares, especially when using SMB. Some APIs that work with local paths may not work seamlessly with network paths, particularly when the path includes the \\?\ prefix. SMB file systems may have limitations that prevent proper handling of long paths or the special \\?\ format."


So what I can do is that I compile you a version where no prefix is added....and if that's the reason I could add an automated test for it....so I guess I come back to you in the next days.

12

clrmame Discussion / Re: Problem Scanning an SMB Volume

« on: 16 March 2025, 15:39 »

"can't parse Z:\MAME\PC\mame.exe"

hmm..interesting....because this means it can't even access a mame binary on your shared drive or run an export for it.
This time no directory_iterator is involved....
So...I'd say.....access rights....I know this doesn't help at the moment. Are you familar with c++? Or got Visual Studio available...then running a small program which simply does some std::filesystem calls on your given path may give some insight on this....

13

clrmame Discussion / Re: Problem Scanning an SMB Volume

« on: 16 March 2025, 11:11 »

Yeah the spam bot is annoying...
Well...what I see from the rebuilder log is that you get the same problem with the rebuilder on the files without using the "." but a full path:
Analyzing rebuilder source Y:\MAME\ROMs failed due to recursive_directory_iterator::recursive_directory_iterator: Invalid Signature.: "Y:\MAME\ROMs"
.....and it shows that also recursive_directory_iterator and not only directory_iterator calls have the problem. So it's a general accessing problem, not a "." specific one.

I've attached a 2 textfiles what chatGPT returned on this topic......so it sounds more or less like access rights problems....

You can try to use the old clrmamepro to see if this gives some results on the path, however it doesn't use plain stl::filesystem calls but win32 api calls which (see chatgpt2.txt) might have different additional features regarding network drives). You can also try to run clrmame with admin rights, or -if you're familiar with c++, you can write a very small program which simply uses a std::filesystem::directory_iterator call on your mapped path.....
Generally mapped network drives don't cause problems...but I can't rebuild your specific setup here....maybe some other forum visitor has an idea.

14

clrmame Discussion / Re: Problem Scanning an SMB Volume

« on: 15 March 2025, 18:53 »

When scanning, clrmame changes to the romfolder and if this succeeds, it uses a directory iterator on the "." (current path).
Maybe you (or clrmame) don't have access rights?
Guess that can be tested when you simply use the rebuilder from that folder to elsewhere. The rebuilder accesses file files via full names since it does a (recursive) directory iterator on the full input path name. That would give an idea if access rights or full path names might be an issue....

15

clrmame Discussion / Re: clrmame 0.3 released

« on: 14 March 2025, 12:55 »

That would be great. Actually, when fixing is still at 0% it's still in the "fix missing rom" phase so when files are added to a rompath from either backup, addpaths or from a different set....
The fix order is like:

- per machine
  - fix missing roms, fix missing disks
  - fix wrong named roms/samples/disks
- fix wrong named machines
- fix unneeded

so if fixing was at 0% for you I'd assume it was still in the fix missing part...(e.g. that also happens when a sl like the amiga 1000/3000 is renamed, the folders themselves are unneeded but the files are used for fixing/adding them at the correct place.

16

clrmame Discussion / Re: Problem Scanning an SMB Volume

« on: 14 March 2025, 08:09 »

Seems that a std::filesystem::directory_iterator (c++ stl function to run access all files within a folder) throws an exception for "." (the current folder) for whatever reason. I will have a look why it creates that error (since it works on a 'standard' Windows drive :-)). I will check if using "." can be changed or check why it could fail with your setup.

17

clrmame Discussion / Re: clrmame 0.3 released

« on: 13 March 2025, 08:35 »

Hmm...ran some tests with the amiga 274-275 changes but currently I wasn't able to reproduce the problem (or even hit a crash once).

I will double check the backup fixes which came in from .2 to .3 if they can have a sideeffect. The problem back then was that when backuping it created endless subfolders, e.g. if a software list A was unneeded and contained A1 to A100 archives, it created a backup folder A\A1 then A\A1\A2 then A\A1\A2\A3 and so on.....instead of having the files simply stored in A....the fix is like 2 lines of code....and should end in a crash....but again...I will do further checks.

If you are able (or even have time) to reproduce the problem with a small setup, let me know....

18

clrmame Discussion / Re: clrmame 0.3 released

« on: 12 March 2025, 19:36 »

If I remember correctly there were some amiga sl lists which were renamed/merged to a new list in last MAME release....so the original folders became unneeded and should be moved to the backup folder....before they should form the new folder though....I will have a look if I see something obvious when replaying that scenario.
There is a change in .3 which affects building the backups (which was wrong before ;-)) ...maybe that hit something weird....

Thanks for the feedback.

19

clrmame Discussion / Re: clrmame 0.3 released

« on: 12 March 2025, 16:28 »

Hmm..sounds indeed like a crash. However there weren't that many changes from .2 to 3(1) which fall into that time window of starting fixing...

Could be a corrupt archive or something. Do a scan (without fix option enabled) and check the output which machines require fixing. So you may get an idea which files are affected. Maybe only a few are listed so testing would be not so time intensive...

When fixing is enabled, you can also try to enable log level "trace"...but if it simply shuts down it will be hard to see the log...so maybe you can use Windows' Snipping Tool to record a short movie ;-) So you might get an idea where it crashes.

By the way: there is no difference in roms or software lists internally.

Would be really interesting to find out which file is causing the problem. So would be great if you can somehow minimize the problem and contact me / send me the file in question.

20

clrmame Discussion / Re: clrmame 0.3 released

« on: 03 March 2025, 18:03 »

Looks like I broke the showing of empty and complete items in clrmameUI 0.3 ...get a fixed one here: https://mamedev.emulab.it/clrmamepro/binaries/clrmame_v031.zip