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

Pages: [1] 2
1
clrmame Discussion / Re: Quick questions
« on: 27 February 2023, 22:41 »
Thanks, Roman.  As much as I'd love that feature I understand your position.  Perhaps your new project will eventually incorporate it, or even render the need obsolete.

Speaking of which, quite interesting reading about Rebuilder and its cool benefits like full -listsoftware scanning!  Very nice to hear about the potential for open source too, I hope that may give rise to a native Linux version someday. :)

2
clrmame Discussion / Re: Quick questions
« on: 26 February 2023, 21:14 »
Thanks again, Roman.

> There is no log or report if you turn off the parsing messages....in the past decade I don't think there was anything really bad though ;-)

I guess you're saying that it's safe to turn off the parsing messages as they aren't going to indicate any real issues with the sets I'm scanning?  In that case I wonder if you might consider removing the parsing message feature in future cmpro releases, or at least moving the messages to a less intrusive post-scan report?  Even if that's something you could do I wouldn't expect anything soon given RL and other priorities as you mentioned. :)

The new rebuilder tool sounds interesting!

3
clrmame Discussion / Re: Quick questions
« on: 26 February 2023, 05:13 »
Thanks as always, Roman.  My main concern is that if I ignore messages with Misc_DisplayLIErrors = 0, I'll miss something important and not know that my sets have issues that should be fixed.  So again I'm curious if there's any way to know of any "can't merge set" and other major or minor issues that are encountered during the scan, such as a report that displays when the scan concludes.  Is there such a thing?

You mentioned "Adv_WindowToFront = on" as an option earlier, but as I mentioned, it didn't really do anything.  It might be a WINE issue then, I'm not sure.  I was just wondering if you had any other suggestions beyond that.  If I could ignore errors though, then I just could scan sets when I'm not around, and then this wouldn't really be much of an issue anyway. :)

4
clrmame Discussion / Re: Quick questions
« on: 24 February 2023, 21:24 »
Hi Roman, just following up with you on this.

1. If I set Misc_DisplayLIErrors = 0, can I still see these "can't merge set" issues in a report presented when scanning completes?  Also, I'll note that I have per-profile merge options on in the batch mode, though I'd prefer non-merged sets anyway, so the issue itself should not be relevant to me as I understand it.

2. Any other ideas on inhibiting cmpro windows from hitting foreground while scanning?

Thanks.

5
clrmame Discussion / Re: Quick questions
« on: 04 July 2022, 20:57 »
Thanks, Roman.

1. I do need to be aware of error messages in general, so an "all-or-nothing" solution wouldn't really work - unless there's a way to present them in a report? If you do have spare cycles to implement something at some point though, I'd be happy to help you test it.

2. I wasn't aware of this setting but I tested it and you're right, it doesn't seem to inhibit pop-ups in the foreground when transitioning from set to set.  Again though, happy to test anything you may have time to come up with.  There may also be a more global Linux/WINE setting as well, though I couldn't find anything after a bit of research.  Perhaps others may know of a way though.

6
clrmame Discussion / Quick questions
« on: 01 July 2022, 19:24 »
Hi Roman,

A few (hopefully quick) questions for you regarding bulk-scanning software sets:

1. Pop-up messages appear for specific sets such as "Can't merge set due to equal names for different hashes.  Clone files will be name differently if full merge mode is used." The "OK to all" option works for that set but the same message will appear for other sets that may exhibit the same issue.  Is there a way to accept these kinds of messages automatically before scanning, and have such issues appear in a summary report when the bulk operation completes?

2. In Linux/WINE, the CMpro scanning window runs in the foreground, so when scanning for a new set begins, the window appears above any other applications that may be running at that time.  How can you configure it to only run in the background so this can be avoided?

Thanks!

7
clrmame Discussion / Re: Scanning software under Linux/Wine
« on: 04 February 2020, 22:32 »
Actually, the issue turned out to be related to the datfiles I had cached in the profiler.  I deleted them and loaded them again with the "create rom path for new dat" setting and it seems to be working now.  Thanks for your help though!

8
clrmame Discussion / Re: Scanning software under Linux/Wine
« on: 04 February 2020, 19:42 »
Thanks again.  I refreshed the list, then loaded one of the not scanned profiles as normal and checked "ROM-Paths" under Settings but nothing was listed.  Assuming the path should show up there, what am I missing?

9
clrmame Discussion / Re: Scanning software under Linux/Wine
« on: 04 February 2020, 19:11 »
Thanks, Roman.  You are right, that's what I meant - I was just using "base scan paths" for lack of a better term.

So I checked "create rompath for new dat" and browser for the root software folder (which contains software subfolders e.g. a2600).  However, when I attempt a scan it immediately returns "not scanned" in the profiler window.  What am I missing?  I know it can find the root folder because I can browse for it.


10
clrmame Discussion / Scanning software under Linux/Wine
« on: 04 February 2020, 17:13 »
Trying to scan software by batch-importing MAME software list dats.  I can't find where I need to specify the base scan path so that each software list item is scanned under its corresponding set name.  I looked for documentation on scanning software under Linux/Wine but couldn't find any.  Can someone help?

Note: this was working fine until the cmpro config became misconfigured somehow, and now I can't recall how it was originally set up.

11
Ah yes, that makes sense.  As a procedure I think I'll just use chdman commandline from my default install.  A linux-native version of Cmpro would help but at least there's a way if people wanted to try it. Thanks, Roman.

12
Hello Roman,

While Cmpro generally runs quite well in WINE, I've found that checking the "Decompress CHD & check SHA1/MD5" box, the following exception is thrown to the results window:

"Can't run chdman ! Please check Settings/Compressor settings"

Is there a way to work around this problem?  I'm wondering if it's simply a path issue.  One thing I did notice is that Cmpro wants to use "chdman.exe" by default, so I changed that to "chdman" (the name of the linux executable"' but it made no difference to the above.  It would be nice to have this working as it's a pretty useful feature.

Thanks as always for any help/advice.

13
clrmame Discussion / Re: cmpro 4.06 released
« on: 04 July 2012, 23:47 »
Nice, thank you.  :)  Is that worth a minor rev bump for others to see?

14
clrmame Discussion / Re: cmpro 4.06 released
« on: 04 July 2012, 18:48 »
I will check it...

Thanks, Roman.  Hopefully this wouldn't be too difficult to implement and I'm sure it would be very helpful.

15
clrmame Discussion / Re: cmpro 4.06 released
« on: 18 June 2012, 02:11 »
Congrats on another release, Roman. 

Out of curiosity, is there any way you could work in Arbee's suggestion regarding the CHD check? 

Thanks.

16
clrmame Discussion / Re: Software lists
« on: 03 June 2012, 17:29 »
Thanks, Roman.  Responses:

1) I see.. so I guess these extra SysDef paths are there in case someone wanted to keep e.g. Devices in a separate location from other BIOS files?  I think that by default the device files are kept with the BIOS files if I'm not mistaken.

2) Gotcha.  Still not sure exactly why it's done that way but from what you're saying I guess that's a MAME/MESS internal thing.

3) I see.  To use my example, I noticed that the 3do_m2 list has its software commented out for now because MESS doesn't yet use it, but it's still included for documentation purposes.  In that case I guess that would be missed in scanning under the "single profile" mode - though in "multiple profile" mode, chances are the user would just import ALL software lists and catch that one - so the latter option is more inclusive and therefore arguably better.  By the way, how does ClrMAME get the actual list names for its "-listsoftware name_of_the_list" operation?  Does it derive the names from the xml files or from some other MESS-internal command?

4) I see now - that makes sense.  When "auto-assign" was run it came up with about a 5% success rate for software paths with existing sets in them; i.e. about 95% of the time it thought software was in the bios path for some reason.  I guess the only recourse would be to do as you suggest and manually assign them.  I'm sure most of the "hell" would only have to be experienced once, though it would also have to be done each time new software lists are introduced (or existing names change, as they have in the recent past).

Anyway, in light of the above I'm going to keep using the "multi-profile" batch mode as I've done in the past. 

Thanks!


17
clrmame Discussion / Software lists
« on: 03 June 2012, 16:27 »
Hi Roman, I wanted to ask a few questions about running ClrMAME against MESS under the "single profile":

1) Under SysDef paths, what are "[STANDARD]" and "[DEVICE]" and how do they relate to scanning?

2) Why are only three bios sets recognized - 3do, cd32, and cd-i?  I would imagine either all bios sets would be listed there or none would; there doesn't appear to be anything special about these particular sets unless I'm missing something, so it's a bit confusing this way.

3) Why are some software lists missing, such as 3do_m2?  How does the SysDef feature obtain the software lists for display there?

4) Can you add a way to easily assign a single SysDef path to multiple lists (outside of external file manipulation).  I noticed the user a few posts down had some issues with this; I was just curious if you could add a feature to address it within ClrMAME itself.

Thanks!

18
Thanks for the explanation.  Just to keep you up to speed: I ran a test against the C2D system to check for differences but got similar results. :/

I hate to return to this, but what about the hash algorithms?  If the CMP option is to "Decompress CHD and check SHA1/MD5", whereas chdman simply says "SHA1 verified successfully" after it's done, then at least at the surface it looks like CMP is doing a bit more; i.e. also performing a calc of MD5.   This would at least explain things, however my logic is probably flawed.

Also, perhaps there's something going on during the download.  Both tools have to download the chd from the network share, but maybe chdman streams it differently?  I tend to doubt the 802.11n network is the bottleneck with CMP but maybe it is?

Also, I suppose if you have time to create a build with GCC, that would at least eliminate item #4 from your list.  Just a thought.

19
Thanks, Roman.  So I plunked your single-threaded cmpro64.exe in the install directory and ran it.. but the results are about the same: area51.chd took over 10 mins to scan.  For shiggles I tried the 32-bit CMP you included but got basically the same results as expected.  Likewise, I tried the same scan with CMP 3.138a - similar results.

I ran chdman again and it just blazes through the verify (relatively speaking of course).  Not sure what else would help explain the difference between cmpro and chdman though.  Realizing they both share the same code, are you sure chdman -verify actually decompresses and checks against both hash types as CMP does?  Maybe it's only checking one of them (after all, it reports "SHA1 verification successful" when it's done).  And maybe there's something about the way it decompresses?  Also, I used the chdman from MESS .143 to compare, in case it matters.

20
Yeah, I was a little surprised myself about that.  It does seem a tad snappier than the C2D, though not as much as was hoping.

Pages: [1] 2

Page created in 0.131 seconds with 20 queries.

anything
anything