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

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.

1

clrmame Discussion / Scanner leaves behind empty folders.

« on: 13 August 2015, 15:33 »

This question is about how the scanner treats empty folders.

There is an option on the scanner that allows the user to check for unused files and fix (remove) them.  I have found that the scanner only checks for unused files and does not check for unused or empty folders.  This came up when re-scanning a set that formerly had a hash name collision, but was changed by a MAMEdev to have unique names.  clrmamepro moved the file to the new name in the root of the .7z file, but the folder it formerly occupied (now empty), was left in the .7z file.  I found I could add any number of empty folders to a .7z file, let clrmamepro scan it, with the "fix unused" checkbox set, and clrmamepro leaves them in the .7z file.  I suppose this behavior could be an artifact of the communication with the 7-zip.exe file as specified in the compressor properties dialog, but I thought I would ask about it in case it was something that is being overlooked.  I'm using 7-Zip [64] 9.38 beta.
 
The file I found that this happened to is "fm7_cass\gbank.7z" in the MAME Software Lists.
 
Of course the rebuilder does not have this issue, it only rebuilds what is necessary and never adds the empty folders.  Certainly a valid work-around is to rebuild everything each time MAME is updated.  But that's going to take a long time, as the .7z file handling takes so much longer than the .zip file handling.

Thanks for entertaining my questions.  I realize these points are minor, and I understand if they are low priority to address, or not even worth addressing.

2

clrmame Discussion / nodump tabulations

« on: 13 August 2015, 15:28 »

Hi, I'm a long-time clrmamepro user, but just recently joined the forum.

This question is about the way nodump ROMs are tabulated and created.

Is it intentional for clrmamepro to not tabulate status="nodump" files when there is a size="0" tag included?  I have found in the MAME Software List hash files folder that there is an xml file that declares a nodump on the same line as setting the size to zero.  The result is a zero length file included in the .zip file that is created for the set.  The .xml file I am talking about is "amiga_a3000.xml", the set is "amix11", the zero-length file is "cass".  Since the size is zero, the fact that the "cass" file is a nodump is apparently ignored (and not counted) for the summary seen at the end of the scan.
 
There are two other files where the same thing happens, apparently due to a MAMEdev specifying a size="0" on a status="nodump" line: "jupace_cass\m_valkyr.zip" and "jupace_cass\triplep.zip"
 
In other MAME Software Lists hash folder files, when status="nodump" is declared, and there is not a size specified, the nodump is tabulated on the scan in the normal way.  And of course, a zero-length file is not created.
 
Perhaps this is intentional because developers need to declare zero-length files as placeholders for parent/child sets, or something?  Or is it just an oversight?  A possible work-around would be to ask the MAMEdevs to not place such conflicting tags in their .xml files.  Or to remove the size="0" tags on nodump lines by hand.  But this issue may come up again on future MAME relases.

I have another question, but I will make a separate post for it.