Print

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

[Bad A. Billy]

Couple of quick questions for you Roman... (these are all done on the latest versions of all programs btw, 1 on WIN11 & 1 on WIN10)

     1st the easy one:
With the new v5 chd's, CMP tells me they need to be upgraded but CMUI doesn't mention it. If I turn on "Check SHA1" will that solve the problem or is it something just not added yet? Sorry, I didn't think about trying that until earlier.)

     2 - Software Lists - MegaCD list - Supposedly megacd, megacdj & segacd were all combined into 1 megacd SL. CMP does this correctly and got rid of the megacdj & segacd folders by combining them into the correct folder. But, CMUI wants all of them in the megacd folder but then also wants the megacdj files in that folder & the segacd files in their folder too. I really don't want 2 copies of all 1.23g just to make my list clean. Any idea if it's something I'm doing wrong, CMUI, or MAME itself?

     3 - This is the strange one.
When I scan with CMUI, not fixing just scanning, I end up with 12 random SL files in my samples folder. I don't have SL on this computer anymore but it's pulling them out of the back up folder. And then when I rescan with remove uneeded file, it won't touch them. Just keeps reporting them as uneeded. I can't even make up a reason as to why this would happen but this is the 3rd version that it's done it. Theories? Next month I'm going to empty out the backup folder and see what happens is my next step unless you or someone else has an idea...

Thanks again for all your hard work!

[Roman]

1) chd version mismatch check will come soon in clrmame. SHA1 check won't solve the problem

2) Hmm..no, actually it detects the old ones as unneeded and sees them as fill ins for the "new" megacd. They get 'moved' to the new place. However, maybe you did not do a clean install of your MAME hash folder and still got the old hash files in their. clrmameui first takes all from -listsoftware and then scans the hash folder for additional ones which are not listed in the xml output (there are a couple which aren't included for whatever reason). So if you don't clean MAME's hash folder before unpacking the new version over it, you still get the old ones in there and clrmame will read them in as additional sl.

3) ? weird one. Unless the samples folder isn't listed as backup folder somewhere. You could check the settings.xml file for this....but the screenshot doesn't correspond to that. Is there a repeatable small scenario for it? I can try to build one based on that screenshot....

[Bad A. Billy]

1 - That's what I figured.
2 - Dead on. I did overwrite the old hash files with the new ones so I'll guarentee those old ones are still in there.
3 - It only does that on my 1 computer on the 1st scan with a new version of MAME. If I get time I'll see if I can repro it before the next release or I'll just wait until then and I will be certain to pay more attention to see what goes on. Then I'll get back to you if need be. I'll bet that it's something on my end in that old set-up.

Thanks for the quick answers and definetly for all your time spent doing this!
Have a good one!

[Roman]

1) actually I've added it yesterday, so it will be in the next release
2) ;-) Overwriting won't help if file A+B was replaced with C which includes A and B......you ended up with A,B and C...and so you have the files mulitplied...
3) very very strange one indeed....there are 3 very very unlikely possibilites:

- You did a rebuild and had your samples folder as destination folder
- You had your samplefolder specified as backup folder (but that would mean that the chd files were somehow marked as unneeded)
- The algorithm which decides where to put a wrong placed files somehow picked the samples folder, however chds/roms and samples are strictly separated...but I will have a look at it....But that would also mean that the chds were somehow wrongly placed in the first scan....

[Roman]

Since you're using a mameui.exe, can you send me that?

[Bad A. Billy]

Roman,
   Here's a link to that mameui... https:  //limewire.com/d/3kKrE#6bc3TaqDtT   <- This was my own compile and not inline with the 276 source.

That got me thinking & wondering... I completly forgot that since MAME updated to the new CPU with x86-64-v2 processor instructions set requierment, on this older PC I've had to use my compiles to be able to pull the xml with CM. With the V2 requirement and official MAME.exe CM gives all kinds of errors trying, and sometimes it did complete the pull but def didn't scan correctly.
I can't remember if 274 and the new requirement was the 1st issues I had with this but I'm willing to bet it was/is. Next release I will use the baseline 277 source to compile and see what happens. Or I can just pull the xml off of 1 of my newer PCs and use it on this old one to scan. (Right? The xml file should be the same for scanning.)

      Big Thanks! - Again!

-Had to add a couple of spaces to the link, Spambot didn't like it!

[Roman]

Well I asked for your binary because I wanted to check how the -listxml output differs from the official one :-)
I know from other forums that mameUI sometimes is some commits ahead of the official mame release...
I don't expect something really obvious in that output for the "chds from backup -> sample path" move but who knows....

Update: Well, the -listxml output does differ from the official one but nothing really which gives a reason why chds from backup gets copied to your samples folder....this really does not make any sense. Files from backup are only copied back to a rompath (!!) when it matches a missing file (crc32+size, optionally sha1 match).
What you can double check is, open settings.xml in a texteditor and search for your samplepath if it's somewhere listed where it shouldn't be listed...