1
clrmame Discussion / Re: Wrong 'wrong case' errors with UNC paths?
« on: 05 July 2021, 17:23 »
Oh dear. Windows, as always, being incompatible with itself 
- 09 November 2024, 01:13
- 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.
Pages: [1] 2
2
clrmame Discussion / Re: Wrong 'wrong case' errors with UNC paths?
« on: 05 July 2021, 12:24 »
Okay PM with the files is out.
3
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:
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]
4
clrmame Discussion / Re: Filename trailing dots cut-off
« on: 10 October 2020, 00:35 »
I think the correct character in this case would be 'Horizontal Ellipsis' = '…', see: https://www.fileformat.info/info/unicode/char/2026/index.htm
But I'm not sure if that is supported by MAME.
But naturally that depends whether your OS supports it or not.
But I'm not sure if that is supported by MAME.
But naturally that depends whether your OS supports it or not.
6
clrmame Discussion / Re: being bored .... ?
« on: 08 May 2017, 22:25 »
Looks good so far. I have found no new undocumented features, yet 
And when you turn on "No scan when no files are rebuild" a run with "No Rebuild" will still trigger a scan run! Great! Although you might want change the label to "Scan run only" on the Rebuild tab. Seems clearer to me.
And when you turn on "No scan when no files are rebuild" a run with "No Rebuild" will still trigger a scan run! Great! Although you might want change the label to "Scan run only" on the Rebuild tab. Seems clearer to me.
7
clrmame Discussion / Re: being bored .... ?
« on: 08 May 2017, 00:27 »
Yes, looks like that one is clean now! 
8
clrmame Discussion / Re: being bored .... ?
« on: 06 May 2017, 07:55 »
Nailed it!
It looks like it should now. Great job!
Thank you,
- ArconEmu -
It looks like it should now. Great job!
Thank you,
- ArconEmu -
9
clrmame Discussion / Re: being bored .... ?
« on: 05 May 2017, 16:53 »Well, the new behaviour is to show empty folders. Period.And I have been saying: Yes, it shows empty folders, unless they are leaves in the tree. All the leaf-nodes are gone in the tree, when you move the datfiles in them upwards. The exception is, leaf-nodes are shown, when there are other nodes in the directory tree at the same level, which have their leaves at a deeper level.
Folders only get hidden if they do contain profiles and you use the "hide red|green|grey profiles" option and the folder fully consists of such hidden profiles
See screenshots.
As for the hide options, I didn't use them. But they do work perfectly consistent with the profiletree.
Screenshot description:
Profiler vs Filesystem 0: shows the original state the datfile is in a leaf directory, the whole path is shown
Profiler vs Filesystem 0a: some, but not all datfiles have been moved up one level, the leafnodes are still shown, because some of them still contain files
Profiler vs Filesystem 0b: all datfiles moved up into the Applications directory, all leafnodes have vanished from the tree.
Profiler vs Filesystem 2: all datfiles are in the Compilations directory, Applications, Demos and Educational directories are shown, because they are on the same level as Games which is not a leaf-node.
10
clrmame Discussion / Re: being bored .... ?
« on: 04 May 2017, 23:21 »
Sorry I didn't test right away, but I was busy actually finishing getting the full TOSEC together in like 12 years 
Anyway ... the behaviour of the profile tree was consistent before, meaning it always hides the empty folders. With the new version, this has become inconsistent and in a way I cannot exactly determine why/when it does what. Also, I guess I don't have worked all possible folder/sub folder move combinations, yet. Let me try and describe.
a) There were 5 subdirectories in a profile, with 1 datfile in each. I move them all up under the system using drag-n-drop (DnD). All subdirectories vanish from view.
As a variaton of this: As long as a dat stays in a subfolder (e.g. because it's the one you selected and cannot be moved, or on purpose), all folders stay in view until you move the last dat seperately ... then they vanish.
Positive: While you can see the empty subfolders, they show the normal folder icon and not one of the complete/incomplete icons
b) When there are further directory levels and you chose to move datfiles up 2 levels only the 2nd before last level is shown and without the (+) open button in front of them. Also somtimes the last level directory will be shown, when there is a deeper directory on the same level
Example:
<datroot>\TOSEC\Commodore\Amiga\Applications\[ADF]
<datroot>\TOSEC\Commodore\Amiga\Applications\Public Domain\[ADF]
<datroot>\TOSEC\Commodore\Amiga\Applications\Public Domain\[EXE]
Shown in Tree:
\TOSEC\Commodore\Amiga\Applications\[ADF]
\TOSEC\Commodore\Amiga\Applications\Public Domain
c) When I start deleting visible but empty tree nodes/directories, the last one also vanishes, when I remove the 2nd to last one.
d) I can only create visible new directories on the level that is visible.
e) Dats that I put in the directories but have not yet configured ([NEW PROFILES] node), the empty nodes are shown in the [Profiles] tree, but without the last node (like described in b) ) until I import them, then the full tree is shown.
So in general, directories still disappear from the tree.
... on hindsight, since I'm testing while I'm writing this, you might be hit by a severe case of fencepost (off by 1) error and the behaviour is totally deterministic
Anyway ... the behaviour of the profile tree was consistent before, meaning it always hides the empty folders. With the new version, this has become inconsistent and in a way I cannot exactly determine why/when it does what. Also, I guess I don't have worked all possible folder/sub folder move combinations, yet. Let me try and describe.
a) There were 5 subdirectories in a profile, with 1 datfile in each. I move them all up under the system using drag-n-drop (DnD). All subdirectories vanish from view.
As a variaton of this: As long as a dat stays in a subfolder (e.g. because it's the one you selected and cannot be moved, or on purpose), all folders stay in view until you move the last dat seperately ... then they vanish.
Positive: While you can see the empty subfolders, they show the normal folder icon and not one of the complete/incomplete icons
b) When there are further directory levels and you chose to move datfiles up 2 levels only the 2nd before last level is shown and without the (+) open button in front of them. Also somtimes the last level directory will be shown, when there is a deeper directory on the same level
Example:
<datroot>\TOSEC\Commodore\Amiga\Applications\[ADF]
<datroot>\TOSEC\Commodore\Amiga\Applications\Public Domain\[ADF]
<datroot>\TOSEC\Commodore\Amiga\Applications\Public Domain\[EXE]
Shown in Tree:
\TOSEC\Commodore\Amiga\Applications\[ADF]
\TOSEC\Commodore\Amiga\Applications\Public Domain
c) When I start deleting visible but empty tree nodes/directories, the last one also vanishes, when I remove the 2nd to last one.
d) I can only create visible new directories on the level that is visible.
e) Dats that I put in the directories but have not yet configured ([NEW PROFILES] node), the empty nodes are shown in the [Profiles] tree, but without the last node (like described in b) ) until I import them, then the full tree is shown.
So in general, directories still disappear from the tree.
... on hindsight, since I'm testing while I'm writing this, you might be hit by a severe case of fencepost (off by 1) error and the behaviour is totally deterministic
11
clrmame Discussion / Re: being bored .... ?
« on: 02 May 2017, 12:44 »
I do really like the new feature that hides empty folders in the [Profiles] tree. Makes things look really tidy
When I create a new folder, it get's created on the filesystem. But I cannot use it to move datfiles into it using the mouse, since ... well ... it is not shown. It still can be moved downward again using the "Move Profile" context menu option.
I usually clean up the folder structure once I imported the dats with the complex and deep structure necessary to find the correct rompaths, so later I move them up at least one level or even stick them right under the system, if there are only a handful of dats for that system. When you eliminate more than one directory level that way, the (+) to open the folder still stays in place (see pictures), but does not do anything (visual).
So, what happens to these folders? Will the garbage collection remove them, when you call it?
If not, you should add an option to the context menu to toggle "Show all folders" or "Show empty folders", so you can go and delete them. Or an "Autodelete folder if empty" like for the fixdats. Otherwise you have to do it all manually with Explorer for datfiles, fastscans, fixdats, logs, scans, and settings
NOTE: I'm not in the habit of updating 1000s of dats or reinstall ClrMAMEPro on a daily basis. So this just sticks out while playing around with it.
Have Fun,
-- ArconEmu --
When I create a new folder, it get's created on the filesystem. But I cannot use it to move datfiles into it using the mouse, since ... well ... it is not shown. It still can be moved downward again using the "Move Profile" context menu option.
I usually clean up the folder structure once I imported the dats with the complex and deep structure necessary to find the correct rompaths, so later I move them up at least one level or even stick them right under the system, if there are only a handful of dats for that system. When you eliminate more than one directory level that way, the (+) to open the folder still stays in place (see pictures), but does not do anything (visual).
So, what happens to these folders? Will the garbage collection remove them, when you call it?
If not, you should add an option to the context menu to toggle "Show all folders" or "Show empty folders", so you can go and delete them. Or an "Autodelete folder if empty" like for the fixdats. Otherwise you have to do it all manually with Explorer for datfiles, fastscans, fixdats, logs, scans, and settings
NOTE: I'm not in the habit of updating 1000s of dats or reinstall ClrMAMEPro on a daily basis. So this just sticks out while playing around with it.
Have Fun,
-- ArconEmu --
12
clrmame Discussion / Re: being bored .... ?
« on: 01 May 2017, 21:37 »
Oh, okay ...
I meant the auto rompath setting in the batchsettings. I wanted to create some fixes from a bunch of fixdats, so I created a directory "Fixes" for the datfiles, put them there and set the batcher's auto rompath setting to "Datfile Name Tag". I imported them and wondered why they all came into the same directory: <ROMroot>\Fixes.
So I deleted them and started to test all 3 settings for the auto rompath. In all cases the result was the same, it used <ROMroot>\<datfile dir>
I tested all 9 combinations in the batch processor:
This only happens when loading new dats from the [New Profiles] section, when they don't have any settings. Using that feature on existing configs has no effect, as desired.
I hope that describes it better.
I meant the auto rompath setting in the batchsettings. I wanted to create some fixes from a bunch of fixdats, so I created a directory "Fixes" for the datfiles, put them there and set the batcher's auto rompath setting to "Datfile Name Tag". I imported them and wondered why they all came into the same directory: <ROMroot>\Fixes.
So I deleted them and started to test all 3 settings for the auto rompath. In all cases the result was the same, it used <ROMroot>\<datfile dir>
I tested all 9 combinations in the batch processor:
Code: [Select]
fsc=DatFile Name Tag : rompath=DatFile Name Tag
fsc=DatFile Name Tag : rompath=DatFile Path
fsc=DatFile Name Tag : rompath=DatFile File
fsc=DatFile Path : rompath=DatFile Name Tag
fsc=DatFile Path : rompath=DatFile Path
fsc=DatFile Path : rompath=DatFile File
fsc=DatFile File : rompath=DatFile Name Tag
fsc=DatFile File : rompath=DatFile Path
fsc=DatFile File : rompath=DatFile File
The Log/Fastscan default names were always correct to the option I set, as they had been in 4.031c. But the rompath always (9 times out of 9) came out as <ROMroot>\<Datfile dir> and not like, e.g. <ROMRoot>\fix_Commodore C64 - Public Domain - [D64] (TOSEC-v2016-09-25_CM), as it should be by using DatFile Name Tag or DatFile File. This only happens when loading new dats from the [New Profiles] section, when they don't have any settings. Using that feature on existing configs has no effect, as desired.
I hope that describes it better.
13
clrmame Discussion / Re: being bored .... ?
« on: 01 May 2017, 09:14 »
Oh dear .... 
I guess I should have tested whether all possible combinations for log/fastscan name and first rompath are working correctly. Because with the 20170429 test release the options for 1st rompath are ALL producing the same result, the first rompath is set based on the directory of the datfile.
Log/Fastscan names work as they should, though.
I guess I should have tested whether all possible combinations for log/fastscan name and first rompath are working correctly. Because with the 20170429 test release the options for 1st rompath are ALL producing the same result, the first rompath is set based on the directory of the datfile.
Log/Fastscan names work as they should, though.
14
clrmame Discussion / Re: being bored .... ?
« on: 30 April 2017, 02:10 »
If I can interest you in one other new feature, though:
Run Rebuild before Scan should have an option to only run the scanner when the rebuilder actually did some rebuilding and not always.
If rebuild hasn't created or updated a set, there is no need to run a new scan afterwards. Unless you checked 'No Rebuild run' to only do a Scan run ...
Run Rebuild before Scan should have an option to only run the scanner when the rebuilder actually did some rebuilding and not always.
If rebuild hasn't created or updated a set, there is no need to run a new scan afterwards. Unless you checked 'No Rebuild run' to only do a Scan run ...
15
clrmame Discussion / Re: Clrmamepro 4.031c shows false missing ROMs
« on: 30 April 2017, 01:52 »
Wait!! Does that mean I have to put all my CHDs into the parent CHD folder again?
16
clrmame Discussion / Re: being bored .... ?
« on: 30 April 2017, 01:50 »
YES!!!
Now it works! And now I wonder, if you actually should fix the log/fastscan stuff, since it does provide a method to quickly change the layout there
You definitely should uncouple the BatchProcessor setting from the main "Misc Profiler Options", because that triggered the issue for me in the first place.
Who goes and checks, if the main settings are correct every time? And if you have to do some workaround you would not expect the global configuration to be fragged and bite your back when you least expect it.
I'm just trying to estimate the fallout.... do you have some info in the fastscan files to match them to the dats? Because that was how I found out. On some dats it always did a full scan, regardless how often I scanned the same group (i.e. Commodore Amiga - Games or Commodore C64 - Games) before. Which can be quite annoying since my C64 - Games - [ADF] still misses more sets than any other set has in total
And probably I only noticed, because the machine that is handling my downloads and sorting them is a 10 years old Q9550 2.83GHz with 4GB RAM and SATA1 disks
So, IMHO, you should release a version with the fixed ROMpath now and keep fixing the fastscan/log issue for the next release and hardly anyone will notice. Otherwise you would have to tell them to re-import all their datfiles and fully rescan all of them... not that ocasionally doing that to prevent bit rot from having you, but I am paranoid
Just my 2 EURcents
Now it works! And now I wonder, if you actually should fix the log/fastscan stuff, since it does provide a method to quickly change the layout there
You definitely should uncouple the BatchProcessor setting from the main "Misc Profiler Options", because that triggered the issue for me in the first place.
Who goes and checks, if the main settings are correct every time? And if you have to do some workaround you would not expect the global configuration to be fragged and bite your back when you least expect it.
I'm just trying to estimate the fallout.... do you have some info in the fastscan files to match them to the dats? Because that was how I found out. On some dats it always did a full scan, regardless how often I scanned the same group (i.e. Commodore Amiga - Games or Commodore C64 - Games) before. Which can be quite annoying since my C64 - Games - [ADF] still misses more sets than any other set has in total
And probably I only noticed, because the machine that is handling my downloads and sorting them is a 10 years old Q9550 2.83GHz with 4GB RAM and SATA1 disks
So, IMHO, you should release a version with the fixed ROMpath now and keep fixing the fastscan/log issue for the next release and hardly anyone will notice. Otherwise you would have to tell them to re-import all their datfiles and fully rescan all of them... not that ocasionally doing that to prevent bit rot from having you, but I am paranoid
Just my 2 EURcents
17
clrmame Discussion / Re: being bored .... ?
« on: 28 April 2017, 12:12 »Nearly May and no new cmpro version...well...yes...life's better when you don't sit in front of your PC... ;-)Works as advertised! I wonder what was the reason to handle it that way in the first place?
but if anyone's interested....
https://mamedev.emulab.it/clrmamepro/binaries/cmpro20170427.rar
fixed: dir2dat creates subfolders for found filenames with `. Now it translates it to ' (as the parser does anyway)
Quote
fixed: unique softwarelist folder check can fail and only show an empty list instead of detailsNot tested.
Quote
fixed: batcher's "for rompath naming use "dafilefolder" created double foldernames when using dats with subfoldersWell .... this looks completely broken to me now. Yes, the double foldernames are gone, but so is the whole subfolder structure for the rompath.
It looks like it just tacks the last folder of the datfile path to the root you set in the misc batch options. (see Example below)
And if you use the default naming option for the Log and Fastscan files, set to also use the datfile folder, together with it you do not get any path at all. All rompaths will be set to the root you specified.
Log and Fastscan filenames and locations are still set correctly according to the option you set, so that didn't break
Quote
misc: show red/green dot profiler tree folder icons when profiles contain at least one red or only green itemsLooks good.
Quote
misc: updated to zip archive: 4.6.4I don't see anything wrong with it.
Example:
Datfiles - Directories
Acorn BBC - Applications - [ADL] (TOSEC-v2013-10-16) - datfiles\TOSEC\Acorn\BBC\Applications\[ADL]
Acorn BBC - Compilations - [ADL] (TOSEC-v2013-10-16) - datfiles\TOSEC\Acorn\BBC\Compilations\[ADL]
Acorn BBC - Educational - [ADL] (TOSEC-v2013-10-22) - datfiles\TOSEC\Acorn\BBC\Educational\[ADL]
Acorn BBC - Games - [ADL] (TOSEC-v2013-10-22) - datfiles\TOSEC\Acorn\BBC\Games\[ADL]
They all end up having <root>\[ADL] as rompath
I guess you need to revisit that.
Thank you,
- ArconEmu -
18
clrmame Discussion / Re: FastScan and Log Files change on update DATfiles
« on: 28 April 2017, 01:15 »
*lol* I know I should have rephrased my bug report yesterday
The point is,
a) when I change the setting for the 'For default naming use' in the Misc options for BatchMode, this will be also change the global "Misc Profiler Options" and vice versa. And I would not expect that, the same as I would not expect the BatchMode settings would overwrite the default settings (or the settings I made) for and individual dat file.
b) when I update a dat file with a new version, it will NOT just take the old .cmp configuration as is, it will update the filename with what ever settings are in the "Misc Profile Options", even though the variable had a value and was not empty before, because it is an update.
So when you take the file from yesterday "Commodore C64 - Demos - [SDA] (TOSEC-v2015-07-25_CM).dat" ... I have added it manually before, with the settings in the Profiler set to "DatFile Name Tag" into the folder "<root>\datfiles\Commodore\C64\Demos" ... so far so good, the Fastscan is "<root>\fastscans\Commodore\C64\Demos\Commodore C64 - Demos - [SDA].fsc"
Then along comes a new TOSEC update ... it also has quite a bunch of new datfiles, so I put them all in the correct folders, so the Batchprocessor can guess the right name for the ROMpath and change the setting 'For default naming use' to "DatFile folder" to keep the new files from getting the doubling of the ROMpath location (Example: Commodore C64 - Demos - [XXX], put in datfiles\Commodore\C64\Demos\[XXX] would get <ROMroot>\Commodore\C64\Demos\[XXX]\[XXX]\ without using this option, but the Fastscan would also be called fastscans\Commodore\C64\Demos\[XXX]\[XXX].fsc).
But all old files in Commodore\C64\Demos which get an update will have their fastscan changed all to fastscans\Commodore\C64\Demos.fsc since either the Batchprocessor or the Global settings do not honour that the variable already in the existing for the old datfile that gets updated does have a valid value. Not to mention that all the new datfiles that get imported have weird fastscan and lognames.
So, to repeat the Bug, you'd have to have the file originally imported with "DatFile Name Tag" settings and then run the BatchUpdate for the update like you would to have new files get their individual ROMpaths with "DatFile Folder" ... and it will change the values for the already existing dat.cmp for the old dat.
... I think I need to record a video of this to make it clearer, words don't seem to describe it well enough
I'll give the update a spin tomorrow.
The point is,
a) when I change the setting for the 'For default naming use' in the Misc options for BatchMode, this will be also change the global "Misc Profiler Options" and vice versa. And I would not expect that, the same as I would not expect the BatchMode settings would overwrite the default settings (or the settings I made) for and individual dat file.
b) when I update a dat file with a new version, it will NOT just take the old .cmp configuration as is, it will update the filename with what ever settings are in the "Misc Profile Options", even though the variable had a value and was not empty before, because it is an update.
So when you take the file from yesterday "Commodore C64 - Demos - [SDA] (TOSEC-v2015-07-25_CM).dat" ... I have added it manually before, with the settings in the Profiler set to "DatFile Name Tag" into the folder "<root>\datfiles\Commodore\C64\Demos" ... so far so good, the Fastscan is "<root>\fastscans\Commodore\C64\Demos\Commodore C64 - Demos - [SDA].fsc"
Then along comes a new TOSEC update ... it also has quite a bunch of new datfiles, so I put them all in the correct folders, so the Batchprocessor can guess the right name for the ROMpath and change the setting 'For default naming use' to "DatFile folder" to keep the new files from getting the doubling of the ROMpath location (Example: Commodore C64 - Demos - [XXX], put in datfiles\Commodore\C64\Demos\[XXX] would get <ROMroot>\Commodore\C64\Demos\[XXX]\[XXX]\ without using this option, but the Fastscan would also be called fastscans\Commodore\C64\Demos\[XXX]\[XXX].fsc).
But all old files in Commodore\C64\Demos which get an update will have their fastscan changed all to fastscans\Commodore\C64\Demos.fsc since either the Batchprocessor or the Global settings do not honour that the variable already in the existing for the old datfile that gets updated does have a valid value. Not to mention that all the new datfiles that get imported have weird fastscan and lognames.
So, to repeat the Bug, you'd have to have the file originally imported with "DatFile Name Tag" settings and then run the BatchUpdate for the update like you would to have new files get their individual ROMpaths with "DatFile Folder" ... and it will change the values for the already existing dat.cmp for the old dat.
... I think I need to record a video of this to make it clearer, words don't seem to describe it well enough
I'll give the update a spin tomorrow.
19
clrmame Discussion / Re: Something for hints & tricks section and usability suggestions
« on: 28 April 2017, 00:39 »
Nice! Not exactly like I thought, but it hits the spot.
Just what I was looking for.
Great Job!
Just what I was looking for.
Great Job!
20
clrmame Discussion / Re: FastScan and Log Files change on update DATfiles
« on: 26 April 2017, 21:11 »
Here you are. There are actually 2 cases in the ZIP. One regular update (Commodore C64 - Demos - [SDA]) and one which was new in the latest release and does not have a predecessor yet (Commodore C64 - Animations - [PRG]). It's already in the directory structure I would use to get it to find the correct ROMpath.
Update: One other thing I noticed, when you change 'For default naming use:' in the BatchRun settings, it also changes in the general Misc Profile Options on the Profiler. And that it works on either new dats or updates to existing dats. So the bug actually provides it's own fix
I used the method I described above to batchload all 2444 datfiles currently in the TOSEC collection into a fresh ClrMAMEPro install, with the options set to
provide the correct ROMPath (that is: default name: datfile folder and rompath: datfile folder). I then copied the datfiles and renamed them from FILENAME.dat to FILENAME_.dat and used a BatchRun again to import the new files with "auto update" on and "Default Name: DatFile Name Tag"
Update: One other thing I noticed, when you change 'For default naming use:' in the BatchRun settings, it also changes in the general Misc Profile Options on the Profiler. And that it works on either new dats or updates to existing dats. So the bug actually provides it's own fix
I used the method I described above to batchload all 2444 datfiles currently in the TOSEC collection into a fresh ClrMAMEPro install, with the options set to
provide the correct ROMPath (that is: default name: datfile folder and rompath: datfile folder). I then copied the datfiles and renamed them from FILENAME.dat to FILENAME_.dat and used a BatchRun again to import the new files with "auto update" on and "Default Name: DatFile Name Tag"
Pages: [1] 2