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: 32k Path Length Issue

« on: Yesterday at 19:17 »

well...fine...great...found out that if you want to recursively create a directory with a long path (e:\long\verylong\evenlonger\.........etc), then you need to add the \\?\ prefix right from the beginning and not only if the recursion sees that the filename gets too long. Totally weird behaviour..but that works for now.

But of course, I found the next win32 api call which might have a problem under some circumstances when path+filename gets too big....*sigh*

But on the other hand, I guess I somehow fooled Windows10 a bit...I've created folders in folders and used very long names. Until Windows complained that it gets too long. Then I reduced it a bit, put the dat inside it, stepped up some parent folders and increased their length again. I wasn't able to move any file to the deepest folder anymore and aren't able to rename the folder anymore......and the win32 api calls also fail.
So I more assume it's a Windows bug

2

clrmame Discussion / Re: 32k Path Length Issue

« on: Yesterday at 09:59 »

well, while it was relatively easy and obvious why it didn't work, fixing that one brings up a new problem. It now shows up in the profiler but when cmpro tries to create profile-based backup folders it fails. For whatever reason a CreateDirectory call fails for long values (even though it should support 32k since it's a unicode variant and got the well known prefix in its path). Grr.....will dig deeper into win32 function calls now.....stay tuned

3

clrmame Discussion / Re: 32k Path Length Issue

« on: 21 September 2020, 11:46 »

ok...I can repeat it and I know the problem.....and I'm working on it

4

clrmame Discussion / Re: 32k Path Length Issue

« on: 21 September 2020, 10:52 »

ah..manually copied over is bad The profiler data is cached. It won't recognize your manual changes. Either use "add" or hit "refresh list". So maybe it's not related to long paths at all

5

clrmame Discussion / Re: 32k Path Length Issue

« on: 21 September 2020, 09:50 »

So..what is actually the issue? Yes, all file operations are wrapped so they detect too long paths and automatically add a prefix when needed, so the question is really where exactly (during which operation) it fails for you. I assume in the profiler when adding the datfile? (can you send it please). Or during a datfile update? during a batch run? Drag'n drop a datfiles? So..where exactly?

6

clrmame Discussion / Re: Many "misplaced romset: (move to a rompath)" on latest nightly 20200904

« on: 10 September 2020, 05:54 »

I bet these were the ones related to the parent/clone merge bug which was fixed. In combined mode it did detect parent/clone relationships between sets though but the actual parent files in the clone sets weren't marked as belonging to the parent...so you had the dupes in there which now got removed.

7

clrmame Discussion / Re: Many "misplaced romset: (move to a rompath)" on latest nightly 20200904

« on: 09 September 2020, 19:31 »

https://mamedev.emulab.it/clrmamepro/binaries/cmpro20200909.7z

That should detect things like triple1 etc plus there was a problem with parent/clonerelationships in software list roms/chds in combined mode.
I wasn't able to repeat your pippin messages. Let me know if you still experience them.

....and I will try to make the "(move to a rompath)" more informative or fixable as soon as I find a little time

8

clrmame Discussion / Re: Many "misplaced romset: (move to a rompath)" on latest nightly 20200904

« on: 09 September 2020, 08:23 »

yes, I'm aware of that (thanks anyway) and working on it

9

clrmame Discussion / Re: Many "misplaced romset: (move to a rompath)" on latest nightly 20200904

« on: 08 September 2020, 18:49 »

Yeah and in that mode earlier cmpro versions did oversee some misplaced sets which is now fixed.
Guess I need to improve the failure message a bit.

10

clrmame Discussion / Re: Many "misplaced romset: (move to a rompath)" on latest nightly 20200904

« on: 08 September 2020, 13:43 »

But as you can check by looking at MAME's hash folder, the electron_cass does not have such sets listed. They belonge to "electron_flop" (and others)

So...they don't belong there and cmpro is right

and I think your "full software list mode" is my "combined mode", i.e. you have only one profile for MAME and all/subset of its software lists and not one profile per softwarelist, am I right?

11

clrmame Discussion / Re: Many "misplaced romset: (move to a rompath)" on latest nightly 20200904

« on: 08 September 2020, 11:31 »

Like? Some more details please.
What are you scanning? What are the exact messages...Did you use a previous nightly and you had no problems?
There is only one possibly related change in the nightly (and that's in the nightly since over a month already) and that's

fixed: some sets don't get marked as unneeded or weird renames are proposed in mame/software list combined mode only

...which may list some files which was not visible before..


So....more details please ;-)

I bet you're using the combined software list mode and the reported ones are actually the ones which were overseen before....so would be interesting to see the datails. and yes...the message "move to a rompath" might be a bit misleading...will change that as soon as I got some time

12

clrmame Discussion / Re: Help with scans fixing ROMs and compression executables.

« on: 06 September 2020, 14:30 »

Regarding rar/7z support:
You need to have rar / 7z installed and either you put the paths to their executables in your Windows environment %PATH% variable or you have to specify the full path to their exe files in cmpro's settings->compressor settings.

Regarding fixing: 10 yard...well..there are a couple of sets holding that name. A parent and several clones, plus it uses device roms. So question is what cmpro complains about in detail and I'm pretty sure cmpro is correctly reporting the problems. ;-)

Generally working with cmpro:

- first of all, you should know your collection. Is it fully or split merged, is it more or less up2date to the datfile/mame exe you're using to scan with (e.g. don't wonder if you get lots of issues reported if you scan a .150 MAME collection with a .223 executable).

The steps are pretty easy:
Profiler -  setup a profile based on the official latest MAME binary
Settings - setup rom and sample paths
Scanner - set your prefered merge mode and do a new scan
The scan results tree window gives you an overview about what is wrong. Turning on all fix options fixes nearly all problems (of course it can't magically generate missing files out of nothing).

To add missing stuff you can also use the rebuilder (rebuilder destination needs to point to your rompath). Then you can simply drag'n drop new files into the scanner window and they get added if they are valid. An automatic scan can be enabled via the options, so your issues tree gets automatically updated.

13

clrmame Discussion / Re: "Error While Adding" error during Rebuilding

« on: 04 September 2020, 05:54 »

Nice that you found the reason and thanks for the 7z parameters guide!

14

clrmame Discussion / Re: "Error While Adding" error during Rebuilding

« on: 03 September 2020, 08:34 »

As mentioned, the error happens when something goes wrong during the actual compression procedure of the mentioned file to the mentioned archive.
It does not depend on any datfile/collection and since you're using 7z (external packer), running that external tool returns an error on that specific file.

Finding the actual reason..hmm...can be difficult without having the files, so let's check the standard things:

- you've put the path of the 7z.exe to your system's environment %PATH% variable? If not, ensure you've listed the full path to the exe in compressor/settings->7z
- you're using a current version of 7z? 19.00 should be also fine (20x is still alpha)
- for temporary file decompression/compression, cmpro's temp folder is used, so the place where cmpro is installed should have enough free space and cmpro shouldn't be installed in an UAC controlled folder
- you're trying to rebuild to an empty destination (i.e. the file does not exist there already)
- Testint the actual 7z file (source or destination). Did you try tro test it with 7z if it's not corrupt?

- if you do a rebuild from a to b, ensure that the file does not exist in b. Maybe cmpro tries to replace the file in there and something fails during deletion.
- did you try to do the compression manually? So run your commandline statements on the files and check if maybe 7z fails with something

- if you can repeat the scenario, you should send me the files in question (used datfile, the 7z source, the 7z destination if existing)


Typical problems with 7z are solid archives. Like you want to add something to a solid archive while not using solid mode commandline parameters.

15

clrmame Discussion / Re: clrmamepro 4.038a released

« on: 11 August 2020, 16:29 »

It's working fine for me....attached 2 example dats.
Maybe you have the option disabled to remove the old one. Profiler->Options->Remove old Datfile after update...that one should be checked.

16

clrmame Discussion / Re: clrmamepro 4.038a released

« on: 09 August 2020, 17:43 »

https://mamedev.emulab.it/clrmamepro/binaries/cmpro20200809.7z

This should solve problems with not found "unneeded" sets like cricket and wrong suggested renames between software lists like dorse93.

Regarding "pro student", well yes, if you have 2 subfolders for the chds, the full merge mode will moan about it and will move the one chd to the parent. You said that "The "r" CHD is still in the prostudg folder,")...and that means the actual move failed. Why? I don't know. Maybe the folder was somehow locked by the system...the rest are sideeffects of the failed move.

"3do_m2", as mentioned, you don't have them in a direct -listsoftware import from MAME...only available in the single hash files

17

clrmame Discussion / Re: clrmamepro 4.038a released

« on: 09 August 2020, 13:07 »

split/full merge mode is only available if the software list support parent/clone relationships. No relationships, no merging


regarding "3do_m2" sets, actually MAME's direct software list import (-listsoftware) does not even include this as a software list.
MAME does filter some of the hash files for whatever reason when using the -listsoftware option.
The direct import only has imsarcng for the PSX software list. That's the reason why you didn't see the 3do ones yet.
If you use the hash files directly, you can access all data.

Regarding the former "unneeded" problem, I rewrote the algorithm in the meantime, making it much more logical and not fuzzylike...
I can't repeat you  pro student problem though....

I will prepare a new build for you soon.

18

clrmame Discussion / Re: clrmamepro 4.038a released

« on: 09 August 2020, 07:48 »

Thanks for testing, yes the old algorithm might mark some unneeded sets as unneeded...As mentioned I will look into that a bit more. To make it clear...this is only for combined mode and only for sets which share the same name.

1) good
2) no, fmtowns_cd has no parent clone relationship for the 2 dorse93 sets, so there is no merging. You can see that in the hash file for fmtowns, so...also ok

3) I will look into this

imsarcng/etc...I will look into this

19

clrmame Discussion / Re: clrmamepro 4.038a released

« on: 08 August 2020, 20:19 »

Hmm..that file belongs to bbc_cass and not electron_cass

If you stored it in electron_cass (do you really have it there?) then it's indeed wrong...but maybe you already have it in bbc_cass, too

I actually wonder how the change of the algorithm should have an impact on this...I will double check that tomorrow

20

clrmame Discussion / Re: clrmamepro 4.038a released

« on: 08 August 2020, 19:55 »

well......usually you simply drag'n drop all the files from MAME's hash holder into the profiler.
The first time when you do that you need to setup rompaths for each profile....the batcher (select more than one datfile at hit load) allows some automatic creation for them in the misc tab.
The next time cmpro should see that the files you've dropped are updates to the existing ones (like it does for other dats, too).

If you already have them due to your current setup, you may need to reassign them one on one....yeah..bit manual work to do.....


But in general the combined mode should work....I'm aware of the algorithm which may cause the problem...let me know if the tweaking helped you...otherwise I need to get rid of it