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.

21

clrmame Discussion / Re: FastScan and Log Files change on update DATfiles

« on: 26 April 2017, 18:21 »

Curiouser and curiouser! ....

Still not good, but I now know what got me into this predicament. I actually added the TOSEC (CORE/ROM) set completely manually, but TOSEC-ISO and TOSEC-PIX in bulk, which needs the workaround to set the ROMPath correctly (and in turn choses weird names for the Log/Fastscan files, which will become not unique once you reorganize the datfiles)

Okay, I think I have the logical explanation of what is happening.
a) When you move a datfile around using the profiler it keeps the filename, but the directory changes. That is what "Update Logfile/Fastscan Names" is meant to do, I guess.
b) When I update the existing datfile, it honors the setting for Default Name, which will change the filename according to the current setting.

So that kind of works as intended (although, I don't think b) it was intended to change an existing setting on update, only on new files that don't have a setting). And, if you actually fix it, that the default name will not be touched when it is already set, then there might not even be an easy way out of the situation anymore. Unless you also fix the node doubling issue

So, without the node doubling fixed, there are 3 options:
1) Don't use BatchMode to import the whole set and set the ROMPath manually for each DAT:
  - Doubleclick entry, <ALT>-S, <ALT>-A, TAB, TAB, down, ENTER, ENTER, <ALT>-P, reach for mouse, repeat 
Which might be actually a bit faster that

2) Import complete set in BatchMode, go through each dat, copy internal name to clipboard, go to Scanner, Open Log File, edit the Log and Fastscan filenames ...

3) Import the set in BatchMode, and create fake update set by bulk renaming all the filenames, import the fake set using BatchMode with the correct fastscan defaults...

I still have to test that, but it does seem a viable option

Update: Tested, it works!!!   

22

clrmame Discussion / Re: FastScan and Log Files change on update DATfiles

« on: 25 April 2017, 20:31 »

Sorry the information is dribbling in, but I was working on fixing what went wrong

As for new DATfiles I guess it was my own mistake. Again in "Misc Profiler Settings" check "DatFile Name Tag" in "For Default Naming Use" seems to do the trick for new DATs.

So, that still would leave the issue about having the Log/Fastscan files to change when you update an existing DAT inplace open.
My guess is, as long as I keep the "Default Naming" checked I can turn on the "Update" feature again and it would behave like I expected it. But the Log/Fastscan shouldn't change, regardless the options I set for the Default Naming. And it does not change, if I move the DAT to another location in the tree. In that case only the directory part of the Log/Fastscan file changes and that regardless of the setting for the Default Name.

Thanks,
  -- ArconEmu --

23

clrmame Discussion / Re: FastScan and Log Files change on update DATfiles

« on: 25 April 2017, 19:51 »

As a workaround when updating existing DATs: Turning off "Update Log/Fastscan Names" in Misc Profiler Options

24

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 

25

clrmame Discussion / Re: Flyers, screenshots, documentation help

« on: 14 April 2017, 18:08 »

And to add them to MAME, take UI-MAME, any other build of choice or a Frontend like Emu Loader and put those files into the respective directory. They are automatically used then. You can do this either as single files or all zipped up into a ZIP file named like the directory.

So all flyers go into <MAME base>\flyers\flyers.zip

That's all there is to do.

Have fun,
  - ArconEmu -

26

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

27

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

« on: 06 April 2017, 19:44 »

Oh great. I have missed that when searching the forum before I started ranting. I guess I should put on my glasses first. Sorry for that

As for the path separator, yes, just using the '-' is tricky .. it is also used in manufacturer names like "Hewlett-Packard" and in system names like "PC-Engine". But that's why I suggested ' - ' (<blank><dash><blank>) that seems to be the unique at least in the TOSEC name tags to separate sections.

For the renaming, that was another issue of me being blind. I was looking at the .cmp files and wondered where the path info was stored, because (me using vim on Windows...) the last stats line is so long without linebrakes, that vi doesn't show it until you scrolled far enough for the linefeed to be recognized... so I somehow assumed, it stopped after "Dir_ScannerSaveHaveFolder =". Again, sorry. I think I can whip up a perl script that can do that for me

But I think, using an option to reset the first rompath in the batch options, that would remove the entry before processing the datfile and then refill it from the settings for rompath creation might be the simpler way. Just my .02€

EDIT: Ah, I see. That part really seems to only be called, when it is really a new datfile. I just tried to remove the rompath and run the file through the batch processor again. No new rompath was set. So it really might be tricky.

Thanks very much for the help.

28

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

« on: 06 April 2017, 18:09 »

Blimey!
 ... I did some more testing. Using the TOSEC supplied script to create the directory structure, move the files into the appropriate directories and copy to the CMP datfile folder of a fresh CMP v4.031c installation produced the following results:

a) Datfile: 3DO 3DO Interactive Multiplayer - Applications (TOSEC-v2012-07-05)
Datfile name tag: <name>3DO 3DO Interactive Multiplayer - Applications</name>
Datfile path: <cmproot>\datfiles\TOSEC-ISO\3DO\3DO Interactive Multiplayer\Applications

Using rompath naming "DatFile Name Tag" the rompath became:
<rompath root>\TOSEC-ISO\3DO\3DO Interactive Multiplayer\Applications\3DO 3DO Interactive Multiplayer - Applications

Er... what? Oh yeah, user error, I didn't want to use the 'datfile name tag' option, let's try again with the next file 

b) Datfile: 3DO 3DO Interactive Multiplayer - Bonus Discs (TOSEC-v2012-07-05)
Datfile name tag: <name>3DO 3DO Interactive Multiplayer - Bonus Discs</name>
Datfile path: <cmproot>\datfiles\TOSEC-ISO\3DO\3DO Interactive Multiplayer\Bonus Discs

Using "DatFile Folder" option, the rompath became:
<rompath root>\TOSEC-ISO\3DO\3DO Interactive Multiplayer\Bonus Discs\Bonus Discs

Looks goo... WAIT!?! What? Why did the end element of the path double? 
*sigh* Does that mean I actually may be able to move the actual datfiles up one level in the datfiles folder?
Try again moving the rest of the datfiles in the datfiles directory up one level ..

c) Datfile: 3DO 3DO Interactive Multiplayer - Educational (TOSEC-v2012-07-05_CM).dat
Datfile name tag: <name>3DO 3DO Interactive Multiplayer - Educational</name>
Datfile path: <cmproot>\datfiles\TOSEC-ISO\3DO\3DO Interactive Multiplayer\

Using "DatFile Folder" option, the rompath became:
<rompath root>\TOSEC-ISO\3DO\3DO Interactive Multiplayer\3DO Interactive Multiplayer

Ooookay ... from the previous try I kinda expected that. Use the datfile path and double the last element 

d) Datfile: 3DO 3DO Interactive Multiplayer - Firmware (TOSEC-v2012-07-05_CM).dat
Datfile name tag: <name>3DO 3DO Interactive Multiplayer - Firmware</name>
Datfile path: <cmproot>\datfiles\TOSEC-ISO\3DO\3DO Interactive Multiplayer\

Using "DatFile Name Tag" option, the rompath became:
<rompath root>\TOSEC-ISO\3DO\3DO Interactive Multiplayer\3DO 3DO Interactive Multiplayer - Firmware

Kinda what I expected from a) but still not what I was looking for 

So... am I doing something wrong, or is it the naming function? I was expecting was to get somehow to:
<rompath root>\TOSEC-ISO\3DO\3DO Interactive Multiplayer\Applications
<rompath root>\TOSEC-ISO\3DO\3DO Interactive Multiplayer\Bonus Discs
<rompath root>\TOSEC-ISO\3DO\3DO Interactive Multiplayer\Educational
<rompath root>\TOSEC-ISO\3DO\3DO Interactive Multiplayer\Firmware

And the associated DatFiles located at:
<cmproot>\datfiles\TOSEC-ISO\3DO\3DO Interactive Multiplayer

Note: The directories where the roms should go were also already in place before I loaded the dat files.
Any idea?

29

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.

30

clrmame Discussion / Re: CHD problem

« on: 08 August 2012, 07:27 »

Oh dear, how could I overlook the first one (in v4.06) and it's even mentioned in the "what's new" section 
I'll try the 20120704 version. Thanks again for your help.

31

clrmame Discussion / Re: CHD problem

« on: 07 August 2012, 22:52 »

I had the exact same issue. Thanks for pointing out what I needed to change. The interesting bit was, that it only moved to a few CHDs into the ROM path, not all.
A suggestion, though. Can you please add the check for the right CHD version to the 'Check - Fix' section in the scanner? Or add a filter to the Scan Results so you can show/hide them? That would really be quite helpful. 

Thanks,
ArconEmu