Hey there, Roman :)

I found an issue with the scanner.
When a set exists as both a zip archive and a set folder, the scanner checks only the zipped roms and doesn't pick the uncompressed ones located in the set folder.It reports the uncompressed roms as missing if they don't exist in the zip-file.
The rebuilder properly detects all roms and skips them (if the "skip existing roms" option is checked).

> I found an issue with the scanner.
> When a set exists as both a zip archive and a set folder, the scanner checks
> only the zipped roms and doesn't pick the uncompressed ones located in the set
> folder.It reports the uncompressed roms as missing if they don't exist in the
> zip-file.
> The rebuilder properly detects all roms and skips them (if the "skip existing
> roms" option is checked).
>

It's not an issue, it's intended. That's why you got dupe checks for. The scanner tells you then that there is a set and a folder in your rompath(s).


Roman Scherzer

> It's not an issue, it's intended. That's why you got dupe checks for. The
> scanner tells you then that there is a set and a folder in your rompath(s).

The dupe check is fine, but why doesn't it look for missing roms in both locations ?

In this case i wanted to preserve the original zip sets, that's why i put the updated romfiles in subfolders. But the scanner keeps ignoring them and says that these roms are missing :(

> updated romfiles in subfolders. But the scanner keeps ignoring them and says
> that these roms are missing :(

Put them in a different rompath and it should at least scan them (although it will complain about the multiple set/folder).
It doesn't scan the folder because it already detected a zipfile for that set (and zip files are prefered). Well...since you shouldn't have a zipfile+setfolder in a rompath, it's not really necessary to continue scanning the folder as well.
What it clrmamepro supports is that you can have a set spread over multiple rompaths (still this is rather a dumb storing method 8)) but you will see another complain about it.


Roman Scherzer

> Put them in a different rompath and it should at least scan them (although it
> will complain about the multiple set/folder).
> It doesn't scan the folder because it already detected a zipfile for that set
> (and zip files are prefered). Well...since you shouldn't have a
> zipfile+setfolder in a rompath, it's not really necessary to continue scanning
> the folder as well.

Unless there're missing roms.

> What it clrmamepro supports is that you can have a set spread over multiple
> rompaths (still this is rather a dumb storing method 8)) but you will see
> another complain about it.

Could you enable scanning of set folders when the zipfile misses some roms, please?

> Unless there're missing roms.

No. Either the zipfile already contains all valid files (so you won't see any issue listed) or the zipfile is incomplete. Then you see the issues listed. If you got a complete zip and an additional folder, cmpro listed a 'set and folder found' issue. I doubt I enable a double-scanning since it's a) not needed and b) waste of additional scanning time.



Roman Scherzer

> No. Either the zipfile already contains all valid files (so you won't see any
> issue listed) or the zipfile is incomplete. Then you see the issues listed. If
> you got a complete zip and an additional folder, cmpro listed a 'set and folder
> found' issue. I doubt I enable a double-scanning since it's a) not needed and b)
> waste of additional scanning time.

Well then, you decide :P
Thanks for your replies.

I still think it's needed in some cases though. And it wouldn't waste time if the scan is only performed for roms missing from the specific set zipfile, not all missing roms from all sets.

P.S. isn't it the same for sets with CHD files ? The roms are in a zipfile, and the CHD itself is in a subfolder.
Besides, what happens if you have zipped sets, but rebuild the missing roms with "compress files" disabled? Doesn't this produce the same thing (i haven't tried yet)?

> I still think it's needed in some cases though. And it wouldn't waste time if
> the scan is only performed for roms missing from the specific set zipfile, not
> all missing roms from all sets.

Well....the scan doesn't work that way. Either it will scan the full zipfile and the full folder (if available) or not.


> P.S. isn't it the same for sets with CHD files ? The roms are in a zipfile, and
> the CHD itself is in a subfolder.

Theoretically yes but since it's a complete different check (roms ain't chds 8)) it's slightly different. Of course enabling the additional set check isn't that big change (in fact it's just a change in an if-then-else statement)....I will think about it.


> Besides, what happens if you have zipped sets, but rebuild the missing roms with
> "compress files" disabled?

It simply means that the file isn't decompressed to ram/disk and recompressed to its destination. The rebuilder will copy the compressed datablock from the zip and reconstructs the belonging structures.


Roman Scherzer

> It simply means that the file isn't decompressed to ram/disk and recompressed to
> its destination. The rebuilder will copy the compressed datablock from the zip
> and reconstructs the belonging structures.

No, not "Recompress files" option. I was talking about the "Compress files" option in the rebuilder. When it's disabled, the rebuilder output isn't compressed, but put in subfolders, right :)

> No, not "Recompress files" option. I was talking about the "Compress files"
> option in the rebuilder. When it's disabled, the rebuilder output isn't
> compressed, but put in subfolders, right :)


oopsi my fault. If you don't enable the compress option, the rebuilder will create sets uncompressed...meaning destinationpath\setname\rom 1 ... rom n


Roman Scherzer