EMULAB Forum

Please login or register.

Login with username, password and session length
Advanced search  

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.

Messages - Roman

Pages: [1] 2 3 4 5 6 ... 174
1
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.

2
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.

3
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

4
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)

6
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'.

7
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.

8
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

9
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

11
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.

12
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!

13
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...

14
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?

15
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.

16
clrmame Discussion / Re: Duplicates that don't even exist
« on: 31 January 2025, 14:13 »
interesting....can you show me your used settings?

17
clrmame Discussion / Re: Scan deleted my softwarelist.xml
« on: 25 January 2025, 19:45 »
Well it simply assumed that the xml file comes from a mame.exe -listsoftware and so it removed the xml file….under the assumption that it recreates it…..but your case is a xml file which was created outside of clrmame

19
clrmame Discussion / Re: Scan deleted my softwarelist.xml
« on: 24 January 2025, 19:05 »
I will have a look at it over the weekend or early next week....real life takes over at the moment....

20
clrmame Discussion / Re: Scan deleted my softwarelist.xml
« on: 24 January 2025, 18:11 »
Your log says:

2025-01-23 13:10:02   info   hash folder change detected, reloading data

That's happening when it detects a change in the hashfolder.
For detecting a change it builds up a hash from the *.xml files in the specified hashfolder (or MAME's exe hashfolder but I know you're using the settings.xml setting if I'm not mistaken) and it's last written timestamp. If that differs, old export file is removed and gets reimported.

So.....the XML (export) file and MAME's hash files (and your specified hash folder) shouldn't be the same

Pages: [1] 2 3 4 5 6 ... 174

Page created in 0.103 seconds with 20 queries.