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 / Wrong 'wrong case' errors with UNC paths?

« on: 05 July 2021, 10:48 »

CMP Version: 4.041

Hi,

I'm having an issue that the Scanner reports 'wrong case' errors with overly long named roms/chds.

Example:

Code: [Select]

Sega Ages - I Love Mickey Mouse - Fushigi no Oshiro Daibouken & I Love Donald Duck - Georgia Ou no Hihou (Japan) [T-En by TrekkiesUnite118 v0.90] [i] [folder: Sega Ages - I Love Mickey Mouse - Fushigi no Oshiro Daibouken & I Love Donald Duck - Georgia Ou no Hihou (Japan) [T-En by TrekkiesUnite118 v0.90] [i] - size: 0]
wrong case: Sega Ages - I Love Mickey Mouse - Fushigi no Oshiro Daibouken & I Love Donald Duck - Georgia Ou no Hihou (Japan) [T-En by TrekkiesUnite118 v0.90] [i].chd [wrong: ] [right: Sega Ages - I Love Mickey Mouse - Fushigi no Oshiro Daibouken & I Love Donald Duck - Georgia Ou no Hihou (Japan) [T-En by TrekkiesUnite118 v0.90] [i].chd]

Shining Force III - Scenario 1 - The Titan of Aspia (USA) [T-En by Shining Force III Translation Project v22] [n] [folder: Shining Force III - Scenario 1 - The Titan of Aspia (USA) [T-En by Shining Force III Translation Project v22] [n] - size: 0]
wrong case: Shining Force III - Scenario 1 - The Titan of Aspia (USA) [T-En by Shining Force III Translation Project v22] [n].chd [wrong: ] [right: Shining Force III - Scenario 1 - The Titan of Aspia (USA) [T-En by Shining Force III Translation Project v22] [n].chd]

Shining Force III - Scenario 2 - Target - Child of God (Japan) [T-En by Shining Force III Translation Project v22] [n] [folder: Shining Force III - Scenario 2 - Target - Child of God (Japan) [T-En by Shining Force III Translation Project v22] [n] - size: 0]
wrong case: Shining Force III - Scenario 2 - Target - Child of God (Japan) [T-En by Shining Force III Translation Project v22] [n].chd [wrong: ] [right: Shining Force III - Scenario 2 - Target - Child of God (Japan) [T-En by Shining Force III Translation Project v22] [n].chd]

Shining Force III - Scenario 3 - Bulzome Rising (Japan) [T-En by Shining Force III Translation Project v22] [n] [folder: Shining Force III - Scenario 3 - Bulzome Rising (Japan) [T-En by Shining Force III Translation Project v22] [n] - size: 0]
wrong case: Shining Force III - Scenario 3 - Bulzome Rising (Japan) [T-En by Shining Force III Translation Project v22] [n].chd [wrong: ] [right: Shining Force III - Scenario 3 - Bulzome Rising (Japan) [T-En by Shining Force III Translation Project v22] [n].chd]

Shoujo Kakumei Utena - Itsuka Kakumei Sareru Monogatari (Japan) [T-En by In the Rose Garden v1.04] [folder: Shoujo Kakumei Utena - Itsuka Kakumei Sareru Monogatari (Japan) [T-En by In the Rose Garden v1.04] - size: 0]
wrong case: Shoujo Kakumei Utena - Itsuka Kakumei Sareru Monogatari (Japan) (Disc 1) [T-En by In the Rose Garden v1.04].chd [wrong: ] [right: Shoujo Kakumei Utena - Itsuka Kakumei Sareru Monogatari (Japan) (Disc 1) [T-En by In the Rose Garden v1.04].chd]
wrong case: Shoujo Kakumei Utena - Itsuka Kakumei Sareru Monogatari (Japan) (Disc 2) [T-En by In the Rose Garden v1.04].chd [wrong: ] [right: Shoujo Kakumei Utena - Itsuka Kakumei Sareru Monogatari (Japan) (Disc 2) [T-En by In the Rose Garden v1.04].chd]


2

clrmame Discussion / FastScan and Log Files change on update DATfiles

« on: 25 April 2017, 17:21 »

Hi,

I don't know if I broke something in my setup or if this is a bug.

When I add a new DATfile as an update to an existing DAT (E.g. Commodore Amiga - Demos - Music (TOSEC-v2016-12-25_CM).dat updates Commodore Amiga - Demos - Music (TOSEC-v2014-10-30_CM).dat) the following happens to the FastScan and Log files:

 It was: <ROOT>\fastscans\TOSEC\Commodore\Amiga\Demos\Commodore Amiga - Demos - Music.fsc
 To: <ROOT>\fastscans\TOSEC\Commodore\Amiga\Demos.fsc

When you update more than one DAT in the same section, they all now point to the same .fsc and .dat file.

Something similar happens when I add completely new DATfiles with internal default settings:
E.g:
<ROOT>\datfiles\TOSEC\Altos Computer Systems\Series 5\Altos Computer Systems Series 5 - Applications - [IMD] (TOSEC-v2017-04-12_CM).dat
<ROOT>\datfiles\TOSEC\Altos Computer Systems\Series 5\Altos Computer Systems Series 5 - Applications - [TD0] (TOSEC-v2017-03-18_CM).dat
<ROOT>\datfiles\TOSEC\Altos Computer Systems\Series 5\Altos Computer Systems Series 5 - Firmware (TOSEC-v2017-04-12_CM).dat
<ROOT>\datfiles\TOSEC\Altos Computer Systems\Series 5\Altos Computer Systems Series 5 - Operating Systems - [IMD] (TOSEC-v2017-04-12_CM).dat
<ROOT>\datfiles\TOSEC\Altos Computer Systems\Series 5\Altos Computer Systems Series 5 - Operating Systems - [TD0] (TOSEC-v2017-03-18_CM).dat

All 5 get the same:
<ROOT>\fastscans\TOSEC\Altos Computer Systems\Series 5.fsc
<ROOT>\logs\TOSEC\Altos Computer Systems\Series 5.log

Any idea what could be the issue? I'm just happy I noticed that before I updated ALL the TOSEC dats from the new update. It definitely slows down the update process since it will ALWAYS run full new scans now, which is not fun on bigger sets like Amiga or C64 games 

3

clrmame Discussion / Something for hints & tricks section and usability suggestions

« on: 06 April 2017, 23:47 »

Something for the hints and tricks section: When you use the "Profile List Includes All Subfolder Entries" option on the Profiles tree it has some welcome sideeffects. When you move the files from subfolders a level up or delete those subfolders afterwards, the tree will open up at the last loaded dat file again ... until you do another batch run, which will reset this ''feature".

Instead of closing all down to PROFILES root and you have to open it up again. I just stumbled over it by accident when trying out this feature to move more than one datfile at a time as the TOSEC directory setup was making me do by putting each dat into it's own directory. As usability enhancement I'd suggest that should be the default behaviour. The PROFILES tree should always reopen at the last loaded profile on filesystem actions like moving a DatFile or deleting a directory ... having to maually reopen the tree at the last location is kinda taking a bit ... which is about as fast (for me at least) to close CMP completely and restart it ... which also brings me to the last loaded DatFile

Another usability suggestion is: How hard would it be to make the directory icons in the PROFILES pane change colour according to the contained subdirectories and datfiles?
Meaning, if all DatFiles in a directory are green, it would be nice to have the directory also in green. So we know, hey we don't need to look at this for now.
Same when none of the Dats are good. Make it red.
For the directory .. if some are red and some are green ... keep the yellow

4

clrmame Discussion / Automatic ROMPath creation, TOSEC dats and my carpal tunnel syndrome :)

« on: 06 April 2017, 16:38 »

First of all I have been using CMP for some 15+ years now, since somewhere around the 2.xx version. Unfortunately not so much in the latter half of the time, so I missed out on actually exploring some of the current features. I practically only used it for MAME, which works perfectly.Since I only was doing that like every half a year, I also missed out on some bugs that happened. So the perfect user experience

So, when I had some time on my hands I also tried to try and update my TOSEC collection, which is where the problem starts. I picked up the latest TOSEC dats from Nov 2016 and was overwhelmed by the 2300+ dats they have nowadays (I remember something like 300 or so ... but I gave up sometime shortly after they introduced ISOs). Luckily they also give you the option to create the directories, which I used to create the tree for my ROMs. And also a script to move the datafiles appropriately, which for TOSEC seems to be one DAT for each format directory.

Example:
Datfile: Commodore C64 - Compilations - Games - [D64] (TOSEC-v2016-09-24)
ROMPath: <romroot>TOSEC\Commodore\C64\Compilations\Games\[D64]
DatPath: would be <cmproot>\TOSEC\Commodore\C64\Compilations\Games\[D64] containing Commodore C64 - Compilations - Games - [D64] (TOSEC-v2016-09-24_CM).dat

I guess if I just use the scripts provided and just move the directories into the CMP datfile folder, it will all work perfectly well using the automatic rompath creation for new dats in directory mode.

Unfortunately, my personal prefecence is to group the datfiles together and I started working without actually looking at all the options I have. Meaning, I didn't even register there was an option to automatically create the first ROMpath in batch mode. So I started manually setting all the rompaths and grouping the datfiles into folders without the actual format tags in it. So all "Commodore C64 - Compilations - Games - *.dat" went into "<cmppath>\datfiles\TOSEC\Commodore\C64\Compilations\Games".

So my question is: Can you update the function to create the rompath from the datfile name tag to recognize " - " as a path separator? Not sure if there is an easy solution for the "<manufaturer> <system>" information since it's just a space and there are quite some manufacturers that have names including spaces. Or maybe check the existing filesystem structure for existing path components.

Luckily, you only have to set the rompath once. When you update later, CMP recognizes which file to update pretty good. But that leads me to my second question.

Is there an easy (read "not annoying") way to move whole sections of my tree to another drive? Doing bulk changes to the rompaths over a bunch of datfiles?
As a possible solution having a flag to overwrite the first rompath in batch mode for existing datfiles using the same rules as for new dats comes to mind.

Thanks for listening.