Print

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

[stargeizer]

Fair warning: English is not my native language, expect lots of grammatical errors!!

- Let's consider the last MAME version. I know that clrmamepro doesn't rebuild or handle CHD the same way it does for roms. but i noticed the following -> The last mame version 206 has a change of contents in a chd folder. In concrete the vs4e folder has a file (gdt-0014.chd) in the 205 version. the 206 version moves this to vs4oe and vs4e gets another file inside. The problem is that clrmamepro deletes this folder and after the rebuild and scan, it leaves an incomplete romset. It took me a while to discover that the chd are in the backup folder, but with the old name. Trying to rebuild from the backup folder doesn't work either, since is a CHD. It has to be done manually. Is possible to fix this, or at least get a warning when moving/deleting chd's?? i think many of the "clrmamepro deletes my files" comes from this limitation.

- Speaking of MAME, or more specifically, SOFTLISTS: You mentioned that file names has limits in the OS, and you also give a workaround (//?/). Problem is that compressed files that already have very long names doesn't get rebuild. Example:  cpc_flop/amsteram.7z. The file inside the compressed have this "nice" name:

"amster & amthello & bombas & bombardero & dibujar es facil & carnival shootout & esgrima elaictrico & space base & guante blanco & poseide & presupuesto & rebotes & tenis & test & space trucker & tumba & tune(2) (nongoodcpc).dsk"

And that alone is  229 characters length. By default clrmamepro will warn that this cannot be unpacked. Can at least be workarounded another way??.

- Speaking about softlists, last update also moved files between folders. Shouldn't be a problem: one just do a rebuild, then a scan, then rebuild from the backup folder and be done with it... in batch mode of course, since i believe the "official way" to mess with the softlists is using the xml files provided by mame. The last mame update broke this: for some reason, certain files weren't moved to the backup folder and i have to rebuild quite some folders from another backup i had handy, but it took quite the ammount of time. Is there another way to deal with softlists?? I don't think this will be a frecuent thing, but something seems wrong.

Thanks for your work on clrmamepro!!! and sorry about my english!

[Roman]

Wow..lots of text...so here we go:

- move of files to backup. Normal and expected behaviour. The scanner only looks at the current set definition and checks if folder xyz holds files for this set. If not, they are marked as unneeded and moved to backup. It also checks if the file is maybe just wrongly placed but it only looks at parent/clone relationships here...and lists them as wrongly placed then and moves them to their correct place. There are exceptions though and I have to check what this vs4 chd falls under. Readding chds is easy by the way, simply move the chd to a rompath root, no matter which one or whatever name it has. cmpro will move it to the correct subfolder and fixes the name.

- long filenames. Good point, While rom/sample etc paths can be setup by the user with //?/ prefix, the cmpro temporary (and backup folders) most likely did not get the prefix. The temporary folder e.g. is used during unpack/pack operations. So I guess you have to add the prefix there, too. But I will give that a test at home.

- moved between folders? You mean files from one software list were moved to a different one? Or just from one set to another within one and the same software list? Then again, the first remark fits here. It's normal that the scanner moves files to the backup folder in such cases. But either a rebuild from backup folder or fix-missing deep options should automatically bring them back. Would be interesting to have some examples here.

[stargeizer]

Well.. spanish to english = wall of text guaranteed!!!

Anyways i'm going to test a 205 set to 206 set softlist so to see if i can reproduce the bugs with the nighty build, the last official versions has problems fixing some softlist sets (x68k_flop.xml and neogeo.xml), but they are fixed ok in the nighty builds.

[Roman]

ok...latest nightly handles the vs4e to vs4eo rename correctly
I checked various scenarios with your long filename example but I cannot repeat a problem with it. By the way, the prestring is \\?\ (not //?/). Can you please use the correct prestring and retest? If you find a problem, please let me know an exact example (e.g. soucrefile (archive) names, destination, which compression settings..)

[stargeizer]

Ok. Indeed the new version fixes the mame chd problem. The temp file location defined in the ini modified with the \\?\ prefix fix the problem with the long names files processing. And as a bonus, the neogeo softlist doesn't get rebuilt every time a scan is done.

In the softlists section, there's still the annoyance of modified softlists. (e.g. ekara was removed and recatalogued as 10 different folders in the dat, probably others, since i had another drive, i just rebuilt everything from 205 to 206 from scratch, but it was quite time consuming). Since it's not a bug not much can be done on this front. Only one question: Is still not possible to have softlists systems aware management from the mame emulator directly (when clrmampro ask if is needed to import softlists)?? (what i do is to use the dats in the hash folder, do a batch rescan and rebuild from a diff set, rescan to check if everything is ok, then manually fix what didn't get merged).

Thanks for your time!!!

PS: since i use mostly the batch operations i attach the settings as displayed in clrmamepro, don't know if can be usefull, but better safe than sorry

[Roman]

I will have a look at the software list "ekara" thing. So you say that from 205 to 206 due to regrouping of the sets, some files went to backup and did not come back automatically?
Then this could be related to the already described fact, that if a file is marked as unneeded it's placed in the backup folder and fix missing only picks it up if it's placed there by a clone or parent. So maybe they've changed parent/clone relationships in 206, too. (Scanner fix missing advance would pick it up, however this is really slow).

Or do you say after the 205 to 206 update some of these changed software list items aren't put in backup and are gone?

Regarding the \\?\  prefix, do you have problems when you do NOT add it to the temp folder? So only rebuilder sourve/destination and rompaths have the \\?\.

The mame/software list combined mode...well...actually I'd recommend to use it your way, single hash files, one profiler per software list. The combined mode is a pain to setup with all its separated paths and it's pretty memory intensive.....I'd go with the single ones. Easier to manage...and only some software lists get updated with a MAME version, so no need to run through all sets.

[stargeizer]

I will have a look at the software list "ekara" thing. So you say that from 205 to 206 due to regrouping of the sets, some files went to backup and did not come back automatically?

Then this could be related to the already described fact, that if a file is marked as unneeded it's placed in the backup folder and fix missing only picks it up if it's placed there by a clone or parent. So maybe they've changed parent/clone relationships in 206, too. (Scanner fix missing advance would pick it up, however this is really slow).

Or do you say after the 205 to 206 update some of these changed software list items aren't put in backup and are gone?

No. In the softlists, the Ekara folder never dissapears from the updated folder, neither its contents go to the backup. This happens because clrmamepro doesn't know that this folder has roms. The 205 ekara.xml file was removed in 206 (and splitted into 10 files with different names), so when one updates the roms from 205 to 206 (in my case, i remove the older dats, then load the new set in the profiler) it will have missing files after rebuild and rescan (and the missing files will be in the original "ekara" folder, happily ignored by the scanner). The 2 ways to fix are moving the original folder (ekara) outside the base rom folder and then rebuild the incomplete dats from this folder, or the ballistic one, just rebuild everything to another drive/base folder. Savy people probably won't have much problem to do this, but took me quite a while to guess this behavior. Probably won't happen that frecuently, but knowing mamedev... who knows.

Regarding the \\?\  prefix, do you have problems when you do NOT add it to the temp folder? So only rebuilder sourve/destination and rompaths have the \\?\.

Yes. I've problems when the temp has no "\\?\" header. I usually put clrmamepro in the desktop so when files are decompressed when roms are updated, the temp folder+decompressed names exceed 260 characters (windows 10 limit for filenames including route). Installing clrmamepro in the root of a hard drive and using only "clrmamepro" as the folder name will work too. (longest decompressed file lenght fits the os limit).

The mame/software list combined mode...well...actually I'd recommend to use it your way, single hash files, one profiler per software list. The combined mode is a pain to setup with all its separated paths and it's pretty memory intensive.....I'd go with the single ones. Easier to manage...and only some software lists get updated with a MAME version, so no need to run through all sets.

Ok, fair enough.

Thanks!!

[Roman]

thanks for the feedback, I will do some investigation on the "ekara" case when I find a little time and I will definetly add the \\?\ to the temporary path internally, so nobody needs to update the ini file. I will also have a look if the 32k path support can be enabled completely internally, so the user won't need to add the prefix everywhere