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.

41

clrmame Discussion / Re: v02 clrmame - how i can hide the "missing disk" related to CHD from result ?

« on: 25 February 2025, 14:02 »

I've added it some time ago already since you requested it some time ago, didn't you :-)
No workaround at the moment
Next version with the next MAME version I guess.....

42

clrmame Discussion / Re: v02 clrmame - how i can hide the "missing disk" related to CHD from result ?

« on: 25 February 2025, 13:56 »

The next version will have context menu options to show/hide roms/disks/samples.

43

clrmame Discussion / Re: Old samples dat needed

« on: 24 February 2025, 10:23 »

That won't work for sample since MAME's XML does not hold any size/crc32/sha1 information for the samples. The created fix dat won't list them with hashes, just with their names.

You can use dir2dat on an existing folder...but then you need to be sure that the folder contains correct files.

44

clrmame Discussion / Re: ClrMAMEPro / MAME 0.274 Issue

« on: 20 February 2025, 06:49 »

clrmame uses the temp folder only when it needs to decompress data temporarily.

This is done when
a) an archive is in an archive
b) adding files to an archive to another where the archive types differ (e.g. 7z to zip, rar to 7z) or when copying data from 7z to 7z archives. A direct zip to zip operation does not require a decompress (unless you don't force it in rebuilder->recopress), so that's one of the main reasons why people should think about using zip...in 2025 multi terabyte hds are cheap, so getting some gb extra by using soldid 7z is  -in my opinion- pretty obsolete. The wasted time is more expensive

By default the system's temporary folder is used (%TEMP%, which usually points to "C:\Users\your_user_name\AppData\Local\Temp").

To quote the readme file: "You can alter the temporary folder by modifying the "TempFolder" entry in settings.xml". So open the settings.xml file with an editor and look out for <TempFolder></TempFolder> and insert your prefered one.


....and all created temporary files will be removed on exit

45

clrmame Discussion / forum posting problems

« on: 14 February 2025, 11:36 »

This forum uses some spam protection for some time which can cause problems when you try to post.
Since I'm not the operator of the forum, I can't do anything about it, but here are some hints which might help you:

When you see a "session timed out while posting" message, you can simply hit the post button again which usually refreshes the session and pushes your message.

When seeing a "CleanTalk: *** Forbidden. Please enable JavaScript. Browser seems to be spambot. Anti-Spam by CleanTalk. ***" message, you can either try to change your text or copy your written text, logout, clean cookies and relogin and add your text again. Usually your post is accepted then.

46

clrmame Discussion / Re: Site Problems

« on: 14 February 2025, 07:10 »

If you get a session timeout you can simply hit post again....it usually accepts it then.

47

clrmame Discussion / Re: ClrMAMEPro / MAME 0.274 Issue

« on: 14 February 2025, 07:09 »

hmm..interesting...but if you say a mame.exe -listxml doesn't work on your system, well, there is your answer.
It shouldn't be a problem to find such redirected outputs in the internet which then can be used as datfiles in clrmame/clrmamepro

48

clrmame Discussion / Re: Site Problems

« on: 13 February 2025, 12:28 »

logout, relogin and try again.....and what error do you get....and Edge works fine (just using it at the moment)

49

clrmame Discussion / Re: new scanner and MAME .269

« on: 13 February 2025, 08:58 »

https://www.emulab.it/forum/index.php?topic=9860.0

50

clrmame Discussion / Re: ClrMAMEPro / MAME 0.274 Issue

« on: 12 February 2025, 08:05 »

Well, the screenshots actually describe what is happening. Your MAME executable file produces a bad or no XML output when it is called. clrmamepro calls it either with -listxml or -listsoftware and redirect its output to a temporary folder.
You can check what was exported by looking at the mentioned temporary place if the file is there or cut off. You can try to delete it if it's there and try again. Check access rights etc. Are you using the official MAME binary or a 3rd party built one? You can test the output yourself by running mame.exe -listxml > test.xml and check it.
And of course you can use such an exported xml file as input for clrmamepro, too.

This does not happen with the official mame binary on a let's call it 'standard PC'.

51

clrmame Discussion / Re: wip

« on: 06 February 2025, 07:14 »

Ok...little update regarding zstd...

Official 7z (or winrar) does not support zstd 'compression'. Reading, renaming, removing files in zstd compressed format works but not adding (or creating new files). There are forks of 7z which does and surely there are tools out there which support zstd write mode (e.g. Winzip, PeaZip,...).

Since I don't want to add calling external exe tools (like clrmamepro does for 7z or rar writing), you need to wait till it gets supported by 7z (then bit7z will support it) or ZipArchive.

Till then I can only offer to add support of reading (removing, renaming) zstd compressed files in zip files.

52

clrmame Discussion / wip

« on: 05 February 2025, 11:57 »

Ok, before really starting on the profiler....I'm bringing up some user feedback here....

- when does "auto" thread selection becomes a problem? There seems to be cases where an auto selection picks the highest available thread number available on the system (which is intended on compressed files), however on a NAS this seems to cause seeking and transfering slowdowns....While on a local drive 28 threads seem to work fine with compressed sets I wonder if auto should also have some kind of max value...maybe 28...maybe less. Surely you can select a fixed value anyhow. Maybe users already played around a bit and have an idea...

- zstd, well, a topic which is not that new. Current situation: I'm using ZipArchive as 3rd party library for zip files. Why? Because it has a nice feature, the direct copy of compressed data without the need of recompressing it. This is a reason why rebuilding is fast when working with zipfiles. For 7z (reading/writing) and rar (reading) I use bit7z which is a lib on top of 7z.dll. It of course also supports zip. Even zip where files are compressed with zstd compression mode.
So to support zstd, we could wait till ZipArchive added it. I've asked the author over a year ago already.....but he seems busy with real life which is good. Now bit7z does support reading and writing of zstd. So why not switching to it? Well, because of the upper mentioned direct copy option.
So what is possible: I could add an option that you can switch completely to bit7z, supporting zstd. The direct copy option is then not possible and you most likely see a speed drop when it comes to adding files. The direct question then is: What happens when the rebuilder creates a new file? What will be the compression method then? Will it be zstd by default? And what if the rebuilder adds a file to an existing non zstd zip archive? Will you end up with an archive with mixed compression modes.
Another possibility would be that when reading a zip file I check if it uses at least one zstd file and switch internally to bit7z....so the change happens invisble to the user.....but still you get the same questions as above
I will think a bit about it.

Little update already: Currently I don't see an option to specify zstd for adding files in bit7z....asking the author now....


ah yeah...by the way...there were some changes lately so here's the latest wip:

UI:
- fixed: remove datasource XML file when hash folder changed (should only happen when XML file was internally created from an exe export)

Core:
- added: "available:" filter which limits the machine selection to files you have. You might notice a count difference in total vs filtered even when you got all files. This is based on the fact that a) empty sets are excluded and b) there are clones which   are totally included in their parent, so -in split mode- you don't have a standalone file/folder for it. So don't worry about the count.
- misc:  "file:" filter, in case you work with softwarelist collections, you'd need to prefix single entries with sl-name#pacman (e.g. a2600#pacman) to specify which set you're refering to. Not needed for single sl files or standard dats though.
- misc:  dupe output now shows all found paths belonging to a machine
- misc:  some earlier cancel returns in fix wrong named disk/sample/rom/machine
- fixed: dupes can be listed multiple times

53

clrmame Discussion / Re: clrmamepro - ignore file types during scan

« on: 02 February 2025, 15:55 »

That's what the unneeded masks are for

so in new clrmame you'd specify a regular expression like ^.*\.jpg$
...and since you've mentioned the old clrmamepro, there you can specify an unneeded mask in settings like *.jpg

54

clrmame Discussion / clrmame documentation

« on: 02 February 2025, 13:19 »

https://mamedev.emulab.it/clrmamepro/binaries/readme.html

55

clrmame Discussion / Re: Duplicates that don't even exist

« on: 01 February 2025, 12:48 »

lol...ok...I simply forgot to clean the dupes list when you do a scan....so the double entries come from detecting the same dupe event in a second scan....
Actually it always prints out only one location of a dupe file and does not list all occurencies....will think about it...maybe it's better to actually list the multiple paths.

56

clrmame Discussion / Re: Duplicates that don't even exist

« on: 01 February 2025, 11:59 »

I created a scenario where I can repeat it ... so assume it gets fixed. The more interesting question would be, how was the zip file placed in your 'chd' rompath folder in the first place. A part of the source code checks the paths and tries to use the best fitting one. Wonder why it picked the chd one .....

Thanks for reporting!

57

clrmame Discussion / Re: Duplicates that don't even exist

« on: 01 February 2025, 08:49 »

hehe, no problem...I will play around with the scenario of chd rompath subfolder and the actual zip.....I'm pretty sure it simply puts out the archive path instead of the chd folder in one case so that you end up with the same information twice...

58

clrmame Discussion / Re: Duplicates that don't even exist

« on: 31 January 2025, 16:24 »

can you tell me how the buggy scenario looked like so I can repeat it?

59

clrmame Discussion / Re: Duplicates that don't even exist

« on: 31 January 2025, 15:18 »

I can imagine that the output of the paths can be wrong and it prints out the path with the roms twice instead of the chd directory and the zip......

Maybe you have a subfolder where a chd is in (e.g. \\Mac\MAME\ROMs\\quizardi_17) and the zipfile is containing the roms...and maybe something changed in the 274 cycle so that the machine doesn't use a chd anymore....and a folder quizardi_17 and a zipfile quizardi_17(.zip) is a dupe....similar for the _12 set.

I will have a look later today...real life first


ok update:

A first test doesn't show any of such problems.....and I don't get your error......maybe you should double check which files and folders you have for quizardi_17 and quizardi_12 (folder and zipfiles...)
Maybe you can build a small scenario with just these files (can even be dummy files just named correctly) to see if this is repeatable.

60

clrmame Discussion / Re: Duplicates that don't even exist

« on: 31 January 2025, 14:13 »

interesting....can you show me your used settings?