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

Well, it was pretty quiet the last weeks...so before you might think that nothing is happening, here is a little peak.
While I was indeed pretty busy with real life I can say that the scanner is still alive, so let's write a bit about it.

As you might know (https://www.emulab.it/forum/index.php?topic=9199.0), the scanner does already a pretty good job in scanning uncompressed and compressed sets, no matter how you organized them (plain, in multiple rompaths, in pattern styled subpaths (e.g. by year/manufacturer/etc) and scanning MAME -listxml output (or anything which followes this format), -listsoftware collections and single MAME hash files. It can do a 'new scan' or a 'scan' where the latter takes scan results information from a previous scan into account (similar to current cmpro).

And now, it also fixes all found problems.

- It is able to auto detect possible missing but fixable files (roms/chds) in your rompaths and in your backup path and everything in one (1) scan and it tries to find a best place for it (as long as you're using one rompath you wouldn't care...but there are people who use pattern-like storage or split chds and roms, etc....)
- It detects wrong names (machines/roms/chds) and fixes them of course
- It detects unneeded files wherever they are and puts them to the backup path before getting rid of them. It does not automatically zip them as cmpro does (see a thread on this forum about it) but takes over the format from the origin and reproduces the rom path structure inside the backup folder. If a file with the same name but different hash already exist there, the scanner will take care of it.


Attached are some screenshots:
- one showing the context menus which you can use to modify the output or copy data to the clipboard
- one showing an example output of scanning a software list collection (no need for multiple profiles or a complex setup...just scan)
- one showing an example output of scanning multiple rompaths and showing complete and partly missing but not fully missing ones...


So..what's missing for a 0.01 version

- doing some more tests with some different scenarios
- a handful of minor nice to haves (still not wanting to add all kind of requests though)
- I'm not yet fully satisfied with writing the scanresults file and fix dat file..it works fine but I think I can speed it up a bit
- need to write a documentation (yikes)


So what's next then after the scanner runs fine?

- most likely people will complain about everything, find bugs and have tons of ideas/requests...so I will look into it
- next major step then would be to combine rebuilder and scanner and have some kind of profiler

Loaded! Thank you!

Hi dumbolines,
I'm also new member today. Hope we have the best time to enjoy this forum here!

ARMAX MAME DATs 0.264 https://www.mameguide.info/MAME_(20240327).7zweb
no idea if someone here needs it .....

Thank you!

in set information i use invert then i keep all for awbios hikaru naomi2 airlbios naomi f355dlx f355bios naomigd hot2bios segasp

i'm wanting to keep all roms bios & chd files from all those systems listed above am i doing it the right way?

tunnel rush

it keeps removing rom tetgiano & it keeps renaming tetgiant chd to tetgiano

is this wrong ?

It's possible that the tool you're using might be encountering some issues with the specific ROM and CHD files for 'tetgiano.' Have you tried manually checking and organizing the files to see if there's any discrepancy?

Removing can be costy in 7z especially when using solid archives since the removal part alone would require the archive to get recompressed. So it may not even be the backup process but the removal of the original archive.

But again, moving some parts of an archive to backup would require a decompression and recompression in case of 7z, so I highly doubt that will be faster.
A different case would be if the full archive would be obsolete, then of course a simple filesystem based move would be quick.

The new scanner might be a bit more clever in that case (actually the removal of unneeded files is the next part on my to do list...so I will take it into account)

I just waited for some gigabytes to be removed from 7z archives and zipped to backup folder. That is when I started to wonder if zipping could be skipped.

Uncompressed backup folder would be nice option, thank you.

If a file within an archive is unneeded it gets moved to the backup folder and since 7z does not support a direct copy of compressed data, you always have a decompress + compress step, so it doesn't really matter if zip or 7z is used. Actually zip would even be faster since it would support direct copy of compressed data (but currently I don't know if this is used when backing up data...I somehow doubt it).
Generally for backup zip is used. You can't change it.

"waste, because files will often be re-compressed with 7-Zip again"
erm...why? If cmpro moves files to the backup they usually stay there since they are unneeded.

"Too much time"....well, usually (unless you scan a completely wrong path), you only have some unneeded files which get moved to backup...so the time argument is not really that important in my opinion....and as I said, no matter if you use 7z or zip, the files get decompressed and recompressed anyhow just for backup.

Maybe I change this for the new scanner....

Hello, I am using 7-Zip as a compressor, no problem here. But when clrmamepro is backing up files to backup folder, it always zips those files (7z -> zip).

How does one stop that behavior? Uncompressed files are OK when backing up, zipping just takes too much time (and is waste, because files will often be re-compressed with 7-Zip again).

That probably is a problem only when using external packer, internal zipper handles that kind of situation OK.

I've managed to find the problem thanks to your reply: there was a zip and a 7z with the same filename. I was using BatchMode, that's why I couldn't see the warning. Thank you!