1
clrmame Discussion / Re: 4.048d deleting backups
« on: 05 August 2024, 20:44 »
Glad to help, thanks for the fix
- 19 February 2026, 10:17
- Welcome, Guest
News:
The new forum is online, hope you enjoy it!
Show Posts
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.
Pages: [1]
2
clrmame Discussion / Re: 4.048d deleting backups
« on: 30 July 2024, 10:20 »
That is it exactly, and no rush, I'm not planning on doing it again and I'm sure there aren't many others out there who would. 
3
clrmame Discussion / Re: 4.048d deleting backups
« on: 29 July 2024, 21:47 »
Nope on the first, the backup is not in the rompath. The rompath in this case was "E:\Microsoft\XBox\Redump (Discs)" which is a SMB share on a TrueNAS NAS. The backup is locate at "D:\Emu\Tools\clrmamepro\backup" which is an internal hard drive on my local computer and is the same for all DATs. I do have remove source files selected, as well as use backup.
So, I had a window open (XYplorer instead of explorer) in the Xbox subdirectory of the backup directory, and I'm 95% sure inside the _unknown folder. I had a batch running of 200 no-intro DATs. It was on the Xbox DAT when I noticed it was backing up a lot of files that I didn't need, specifically in that set. I used another open XYplorer window to delete the unwanted files from the ROM directory that were left, except for the one it was currently processing. After it finished copying that one file to backup, it presented an error (sorry, didn't capture it) that said something to the effect of no files will be changed (?). It then wrote the remaining files to the output log indicating it was not processing them. At that point it moved on to the next DAT, while at the same time I saw all the files disappear from the Xbox backup directory in the window I had open. There were at least a dozen files, probably more, that it had backed up before my foolish deletion.
That's essentially it. Hopefully that's a little more clear.
So, I had a window open (XYplorer instead of explorer) in the Xbox subdirectory of the backup directory, and I'm 95% sure inside the _unknown folder. I had a batch running of 200 no-intro DATs. It was on the Xbox DAT when I noticed it was backing up a lot of files that I didn't need, specifically in that set. I used another open XYplorer window to delete the unwanted files from the ROM directory that were left, except for the one it was currently processing. After it finished copying that one file to backup, it presented an error (sorry, didn't capture it) that said something to the effect of no files will be changed (?). It then wrote the remaining files to the output log indicating it was not processing them. At that point it moved on to the next DAT, while at the same time I saw all the files disappear from the Xbox backup directory in the window I had open. There were at least a dozen files, probably more, that it had backed up before my foolish deletion.
That's essentially it. Hopefully that's a little more clear.
4
clrmame Discussion / 4.048d deleting backups
« on: 29 July 2024, 01:56 »
So, before I describe the problem, I'm fully aware that it's something I shouldn't do, and I had never done it before.
I had a batch running of new Redump DATs, and when it got to the Xbox DAT I realized it was unwantedly (but correctly) backing up all the magazines from my NAS to my local slow backup disc. I was in the backup folder at the time, when instead of correctly canceling the run I instead deleted the remaining files from the ROM directory directly. I expected an error, which I got. However, it then deleted all the files in the backup directory as I watched. Like I hinted, it's an unwanted consequence of a stupid maneuver, but I thought worth reporting because of the data loss.
Thanks!
I had a batch running of new Redump DATs, and when it got to the Xbox DAT I realized it was unwantedly (but correctly) backing up all the magazines from my NAS to my local slow backup disc. I was in the backup folder at the time, when instead of correctly canceling the run I instead deleted the remaining files from the ROM directory directly. I expected an error, which I got. However, it then deleted all the files in the backup directory as I watched. Like I hinted, it's an unwanted consequence of a stupid maneuver, but I thought worth reporting because of the data loss.
Thanks!
5
clrmame Discussion / Re: rebuilder 0.07 released
« on: 14 December 2023, 01:47 »
Looking amazing, and somehow easier to understand I think than old clrmamepro. The only thing I would like to see added is the ability to set a backup directory (-b or in settings) rather than having it put in the output folder. In this respect, I prefer the old cmp's method.
6
clrmame Discussion / Re: Some new scanner wip
« on: 14 December 2023, 00:42 »Since people asked for some "benchmarks"...(e.g. .260, no softwarelists, but roms/disks/samples)
generally, you need to differ between 2 things: no diskcache (that's a full scan after a just started PC)
and diskcache (that's a full scan after a scan already took place where your PC hopefully uses the cached data)
old scanner: 8 min 45 seconds (no diskcache)
old scanner: 1 min 5 seconds (diskcache)
new scanner: 5 min 49 seconds (no diskcache)
new scanner: 0 min 5 seconds (diskcache)
Scanning a not existing MAME 260 collection (so everything is missing)
old scanner: 1 min 31 seconds (no diskcache)
old scanner: 1 min 28 seconds (diskcache)
new scanner: 0 min 1 second (no diskcache) however it takes 26 seconds to render the tree :-)
new scanner: 0 min 0 seconds (diskcache) however it takes 26 seconds to render the tree :-)
Or some progretto snaps (Snapshots with software list datfile, unpacked pngs on the disk)
old scanner: 7 min 21 seconds (no diskcache)
old scanner: 1 min 59 seconds (diskcache)
new scanner: 4 min 7 seconds (no diskcache)
new scanner: 0 min 6 seconds (diskcache)
The tester's system: i7-8700K, 16GB RAM, Seagate IronWolf HD
Those are some impressive gains, and the new GUI is a much-appreciated update. Just want to say I'm glad you've found a renewed interest in these tools, as it looked like you were understandably experiencing a bit of burnout. I think I can safely speak for others when I say we all appreciate it more than you know!
7
clrmame Discussion / Re: 7zip rn option
« on: 04 November 2022, 18:29 »
That's interesting, plumbing the depths of these apps I'll continue to leave to the experts! It's a little odd how it stores the structure, no? That seems to be the default result from a command line add operation in 7z. Regardless, thank you for the answer!
8
clrmame Discussion / Re: 7zip rn option
« on: 29 October 2022, 23:10 »
But that's exactly the problem, the DAT won't say "bla/game name.iso", it will say "game name.iso" only. In this case the source of the 7zip is external, so I don't control how it's created. So when it encounters the 7z with "bla/bla.iso", it doesn't appear to rename "bla/bla.iso" to "game name.iso", which would have the effect of leaving a 7z with "game name.iso" in the root and an empty "bla" folder. Instead, what I'm (purely) guessing is it's attempting to rename "bla.iso" to "game name.iso", failing, and then deciding it needs to extract the whole thing.
It's simple to demonstrate with the test sample 7z I sent. You can try the two rename operations above directly with 7zip's rn command to see the effects.
I could be completely wrong and it's just the time cost of doing the two (rename and delete empty folder) operations, but the length of time it takes sure seems like it's doing a complete rebuild every time.
Thanks so much for looking into this!
It's simple to demonstrate with the test sample 7z I sent. You can try the two rename operations above directly with 7zip's rn command to see the effects.
I could be completely wrong and it's just the time cost of doing the two (rename and delete empty folder) operations, but the length of time it takes sure seems like it's doing a complete rebuild every time.
Thanks so much for looking into this!
9
clrmame Discussion / Re: 7zip rn option
« on: 29 October 2022, 08:03 »
It would be the latter. The DAT file is fine, with the correct name. The "problem" lies in large 7zip files with incorrectly named ROMs within subfolders that would benefit from a simple rename rather than a complete rebuild. Admittedly these files are poo, but handling them would increase clrmame's speed when confronted with them.
I've attached a trivial example that I hope illustrates it better.
I've attached a trivial example that I hope illustrates it better.
10
clrmame Discussion / Re: 7zip rn option
« on: 28 October 2022, 18:20 »
That's what I initially thought, until I started playing around on the command line and found using 7zip correctly (i.e. the way -they- want you to) it was exponentially faster than what occurs with clrmame. I'll try to prep one for you, but in the meantime maybe a clearer illustration:
File:
Game.7z
Contains:
Game/
Game/Game.iso
If you attempt to use the rn option to change "Game.iso" to "Game2.iso" (assuming that's the correct name), it will fail with file not found. You must use "Game/Game.iso" to "Game2.iso", which will result in the following structure:
Game/
Game2.iso
...after which I assume it's trivial to do a delete on the empty/unneeded "Game/" folder.
Does that make more sense?
File:
Game.7z
Contains:
Game/
Game/Game.iso
If you attempt to use the rn option to change "Game.iso" to "Game2.iso" (assuming that's the correct name), it will fail with file not found. You must use "Game/Game.iso" to "Game2.iso", which will result in the following structure:
Game/
Game2.iso
...after which I assume it's trivial to do a delete on the empty/unneeded "Game/" folder.
Does that make more sense?
11
clrmame Discussion / 7zip rn option
« on: 27 October 2022, 23:23 »
So, I have a bunch of archives with the roms in subfolders within the 7zip. I enabled the rename function under the compressor settings, but it still seems to be rebuilding the entire archive. I believe the problem is related to the fact that unless you specify the FULL path within the archive to the file you wish to rename, it will fail as file not found. It also does not accept wildcards. It does, however, allow for a "move" operation to be done with the rename.
Bottom line what I'm asking, is there any way to have clrmame essentially make up the functionality lost in the 7zip implementation by having clrmame pass the full path to the %2 parameter of the rn? It would tremendously speed up processing of 7zip files that require only a name change.
Thanks!
Bottom line what I'm asking, is there any way to have clrmame essentially make up the functionality lost in the 7zip implementation by having clrmame pass the full path to the %2 parameter of the rn? It would tremendously speed up processing of 7zip files that require only a name change.
Thanks!
12
clrmame Discussion / Re: Question on filtering sets
« on: 21 July 2022, 16:19 »
Yup, figured my example wouldn't do it 
- I've recently (partially) converted from a hoarder to a collector/user as I've gotten heavily back into retro. So, the hoarder in me wants to keep TOSEC sets, but the reformed me wants to eliminate most of the "bad" (e.g. bad, under dumps, over dumps, etc.) ROMs AND ROMs that exist in No-Intro sets. I also want this to persist between DAT updates, so that it continues to ignore my bad sets.
Now that I'm writing this, I realize I think that I'll have to redo my method anyway anytime there's a DAT update. Perhaps pre-filtering the DATs prior to importing into clrmamepro might be the easiest way. Sigh, any suggestions from anyone for a tool similar to what Retool https://github.com/unexpectedpanda/retool/ does for No-Intro/Redump sets?
I haven't completely given up on TOSEC yet, but the sheer amount of garbage in there has me seeing the project headed down the GoodSets path. My method works, but it's disgustingly inefficient and that's why I was hoping for an alternate/better way.
- I've recently (partially) converted from a hoarder to a collector/user as I've gotten heavily back into retro. So, the hoarder in me wants to keep TOSEC sets, but the reformed me wants to eliminate most of the "bad" (e.g. bad, under dumps, over dumps, etc.) ROMs AND ROMs that exist in No-Intro sets. I also want this to persist between DAT updates, so that it continues to ignore my bad sets.Now that I'm writing this, I realize I think that I'll have to redo my method anyway anytime there's a DAT update. Perhaps pre-filtering the DATs prior to importing into clrmamepro might be the easiest way. Sigh, any suggestions from anyone for a tool similar to what Retool https://github.com/unexpectedpanda/retool/ does for No-Intro/Redump sets?
I haven't completely given up on TOSEC yet, but the sheer amount of garbage in there has me seeing the project headed down the GoodSets path. My method works, but it's disgustingly inefficient and that's why I was hoping for an alternate/better way.
13
clrmame Discussion / Re: Question on filtering sets
« on: 21 July 2022, 04:43 »
Just for further clarification, and to demonstrate my use case here, I figured out a workaround. I first choose all available sets, copy enabled sets to the clipboard, then paste into a text file. I then apply a filter (*[[]b*[]]*;*[[]h*[]]*;*[[]a*[]]*;*[[[t*[]]*), and copy enabled sets to the clipboard again, pasting into the same text file. I then sort (unnecessary) and remove duplicate lines (necessary?). I then "From File" this text file, invert the selection (I don't trust myself with initial invert), then copy enabled sets to the clipboard again to get my ultimate list of desired ROMs. Hopefully you could follow this garbage 😕
14
clrmame Discussion / Question on filtering sets
« on: 21 July 2022, 04:20 »
My question, and hopefully it's not something painfully apparent that I've overlooked, is is there a way to select "All Available Sets" from the set information window, and then subsequently apply a filter that would add to the list. I understand the answer is probably "no" based on the complexity of combining multiple runs of filters, but maybe a "%" variable that would allow one to check the available status from within the filter search window?
15
clrmame Discussion / Re: Rebuilder 0.01 released
« on: 17 July 2022, 02:05 »
Interesting, looking forward to trying it as I myself have been getting back into CLI lately. Only 25 years between projects, can't wait to see what you come up with in 2050!
16
clrmame Discussion / Re: RVZ Support?
« on: 01 July 2022, 05:55 »
...and just to make my case/belabor the point a bit further, I grabbed a GC ROM ("18 Wheeler - American Pro Trucker (USA)") to run a quick informal test. All settings were default, except for the zip which I set to Ultra for the hell of it. All in KB.
Not bad for a lossless format! Clearly results on other games will vary, but overall I think it's close to a 40% compression ratio.
| Original: | 1,425,760 |
| RAR: | 1,284,808 |
| chdman: | 1,308,705 |
| ZIP: | 1,303,626 |
| RVZ: | 159,917 |
Not bad for a lossless format! Clearly results on other games will vary, but overall I think it's close to a 40% compression ratio.
17
clrmame Discussion / Re: RVZ Support?
« on: 30 June 2022, 17:41 »
Here's a link to a new open source CLI tool that may be of interest. It simply verifies an RVZ file(s) against a redump dat. It's limited in its scope and a poor substitute for integration in clrmamepro, but for now it appears one of the only options.
https://github.com/j68k/verifydump
https://github.com/j68k/verifydump
18
clrmame Discussion / Re: 1G1R Priority
« on: 30 June 2022, 05:28 »
Is there a forum rule against referencing other tools? There exists a much better implementation of 1G1R sets from No-Intro and Redump, but it definitely requires (slightly) more effort in your workflow.
19
clrmame Discussion / Re: RVZ Support?
« on: 29 June 2022, 22:43 »
While I in general agree that any new format introduced needs to be carefully weighed against the upheaval it causes, it appears the RVZ format has gained much traction and continues to grow. I'm no programmer, but I do understand you have to balance the time cost/benefit of adding something like this. In this case, if it's not too in-depth beyond adding the compression profile, I think it would be invaluable. Here's a quote I found from someone scratching the surface of the problems with CHD:
"MAME is sometimes so disappointing, they create the only cd image format that has delta encoding, then they do absolutely nothing to make it easy to use with the current state of the world (which for romhacks in particular is xdelta patches on the binary track). They're even considering 'reworking' chd to a 'more accurate' format - to be clear, this probably would require redumps of absolutely everything, and i can think of no finer way to kill the format."
..and finally, a hearty thanks for the years of effort on this software. It is greatly appreciated!
"MAME is sometimes so disappointing, they create the only cd image format that has delta encoding, then they do absolutely nothing to make it easy to use with the current state of the world (which for romhacks in particular is xdelta patches on the binary track). They're even considering 'reworking' chd to a 'more accurate' format - to be clear, this probably would require redumps of absolutely everything, and i can think of no finer way to kill the format."
..and finally, a hearty thanks for the years of effort on this software. It is greatly appreciated!
Pages: [1]