Print

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

[ArconEmu]

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 

[Roman]

I will have a look at it.....

[ArconEmu]

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

[ArconEmu]

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 --

[ArconEmu]

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!!!   

[Roman]

Do you have two datfiles (one plus its update) available so I can play around with the problem?

[ArconEmu]

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"

[Roman]

Thanks for the files...sorry to ask again..what exactly is the problem?

So let's say I have the Commodore C64 - Demos - [SDA] (TOSEC-v2015-07-25_CM).dat file, I create a profile for it....I run a scan...and it will create a fastscan file (by default it's named: "Commodore C64 - Demos - [SDA].fsc" (which is taken from the datfile header name element). Now when I add the Commodore C64 - Demos - [SDA] (TOSEC-v2016-12-24_CM).dat file and load it (in a batchrun), it sees that the dat is an update to the other one. Fine....But the fastscan filename stays the same.. (no wonder, since the name element is the same in the new dat)

So....where is the difference to your setup?

[ArconEmu]

*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.