Print

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

[Roman]

Nearly May and no new cmpro version...well...yes...life's better when you don't sit in front of your PC... ;-)

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)
fixed: unique softwarelist folder check can fail and only show an empty list instead of details
fixed: batcher's "for rompath naming use "dafilefolder" created double foldernames when using dats with subfolders
misc: show red/green dot profiler tree folder icons when profiles contain at least one red or only green items
misc: updated to zip archive: 4.6.4

I have more on my todo list....

[ArconEmu]

Nearly May and no new cmpro version...well...yes...life's better when you don't sit in front of your PC... ;-)

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)

Works as advertised! I wonder what was the reason to handle it that way in the first place?

fixed: unique softwarelist folder check can fail and only show an empty list instead of details

Not tested.

fixed: batcher's "for rompath naming use "dafilefolder" created double foldernames when using dats with subfolders

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

misc: show red/green dot profiler tree folder icons when profiles contain at least one red or only green items

Looks good.

misc: updated to zip archive: 4.6.4

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

[Roman]

hmmm....you keep me busy for the weekend ;-) I will have a look....that's so damn old code....


"It looks like it just tacks the last folder of the datfile path to the root you set in the misc batch options."

well...yes...but that's what the fly over also says, isn't it ;-) If I remember correctly the rompath generation worked that way....but yes...I have to check that again....as I said...that's like a decade old or something....

[Roman]

https://mamedev.emulab.it/clrmamepro/binaries/cmpro20170428.rar

https://mamedev.emulab.it/clrmamepro/binaries/cmpro20170429.rar

that should fix the rompath generation....
....and now I can look into your log/fastscan stuff

[ArconEmu]

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

[ArconEmu]

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

[ArconEmu]

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.

[Roman]

erm...which setting for 1st rompath? You mean rebuilder destination? Examples please...since I cannot reproduce a problem here....I use the batcher rebuilder 1strompath rebuilder destination setting plus the auto rompath creation mentioned before....and it correctly uses the 1st rompath (and they do differ per profile)

[ArconEmu]

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:

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.

[ArconEmu]

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

[Roman]

no time yet for the logfile/fastscan and 1st rompath thing but that empty folder issue made we wonder...actually it was never a feature that empty folders are hidden...

so...better update:

https://mamedev.emulab.it/clrmamepro/binaries/cmpro20170503.rar

Thanks for your interest by the way

...and by the way, I've just added an option to skip batch scan run when a previous batch rebuild run did not create any files....(that features is not included in cmpro20170503.rar....but in the next it will be)

[ArconEmu]

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

[Roman]

Well, the new behaviour is to show empty folders. Period.
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

[ArconEmu]

Well, the new behaviour is to show empty folders. Period.
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

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

[Roman]

hmm...yeah...very strange....just looking into this...it does append the other folders, too....I can see this during debugging......I currently wonder why they do not appear.....

update....ah there it is ;-)

https://mamedev.emulab.it/clrmamepro/binaries/cmpro20170505.rar

[ArconEmu]

Nailed it!
It looks like it should now. Great job!

Thank you,
  - ArconEmu -

[Roman]

and I guess I've also nailed https://www.emulab.it/forum/index.php?topic=4169.msg16647#msg16647

https://mamedev.emulab.it/clrmamepro/binaries/cmpro20170507.rar

[ArconEmu]

Yes, looks like that one is clean now!

[Roman]

...and I changed the double use of general profiler options for default naming and batcher's corresponding one...so batcher overwrites the global ones but only in the current batch run....does this resolve your fastscan/log file problem?


fixed: dir2dat creates subfolders for found filenames with `. Now it translates it to ' (as the parser does anyway)
fixed: unique softwarelist folder check can fail and only show an empty list instead of details
fixed: batcher's "for rompath naming use "dafilefolder" created double foldernames when using dats with subfolders
fixed: batcher's "for rompath naming use "datfile name tag" or "datfile file" was not working
fixed: batcher's "for default naming use" options does not use the global profiler setting anymore
fixed: don't list existing parent roms in completely missing clones' output
fixed: profiler hides empty folders
added: batcher option to skip scan run when a batch rebuild did not create any files
misc: show red/green dot profiler tree folder icons when profiles contain at least one red or only green items
misc: updated to zip archive: 4.6.4


https://mamedev.emulab.it/clrmamepro/binaries/cmpro20170508.rar

[ArconEmu]

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.