1
clrmame Discussion / Re: Problem Scanning an SMB Volume
« on: Yesterday at 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
- 27 March 2025, 06:23
- Welcome, Guest
News:
The new forum is online, hope you enjoy it!
Show Posts
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.
2
clrmame Discussion / Re: Problem Scanning an SMB Volume
« on: Yesterday at 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.
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.
3
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...
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...
4
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
So...I blame the file in the zip
5
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...)
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...)
6
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
7
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.
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.
8
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
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
9
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.
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.
10
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....
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....
11
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.
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.
12
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....
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....
13
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.
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.
14
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.
15
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....
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....
16
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.
There is a change in .3 which affects building the backups (which was wrong before ;-)) ...maybe that hit something weird....
Thanks for the feedback.
17
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.
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.
18
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
19
clrmame Discussion / Re: clrmame 0.3 released
« on: 28 February 2025, 08:51 »
Again: For software lists, you don't need 700+ profiles/xml files.
You can simply run a mame -listsoftware based scan. Specify just one folder as rompath. This folder is the parent of the sl folders (a2600,....)
You can simply run a mame -listsoftware based scan. Specify just one folder as rompath. This folder is the parent of the sl folders (a2600,....)
20
clrmame Discussion / Re: clrmame 0.3 released
« on: 27 February 2025, 07:19 »
Hmm..don't know if I understand your questions correctly...
A batcher is planned for the (far away) future but surely you can write and run a shell script for the commandline version which runs over multiple xml files.
Unique xml files for softwarelist? Either you use a -listsoftware MAME export for all sl data in one file or you simply use the single XML files in MAME's hash folder.
chdlist? What should that be? A standalone datfile for chd files? For what? But most likely such things are floating around in the internet.
A batcher is planned for the (far away) future but surely you can write and run a shell script for the commandline version which runs over multiple xml files.
Unique xml files for softwarelist? Either you use a -listsoftware MAME export for all sl data in one file or you simply use the single XML files in MAME's hash folder.
chdlist? What should that be? A standalone datfile for chd files? For what? But most likely such things are floating around in the internet.