EMULAB Forum
clrmamepro [English] => clrmame Discussion => Topic started by: Roman on 20 February 2018, 20:03
-
4.034
fixed: due to a cache flag error, in non-merged mode, cmpro took merge attribute information for names into account which is wrong
fixed: setinfo, falsely hide empty parent set and its clones in tree when parent is empty but clones got content
fixed: scanner, falsely list empty parents set in full merged mode as wrong named when parent is empty
fixed: scanner, falsely list empty parent set in full merged, multi-software list mode as missing when set exists in various software lists
fixed: miss list generator falsely lists sampleonly sets when they only reference parent samples
fixed: scanner, falsely show wrong case set messages when missing option is turned off
misc: allow romclones to be sampleparents
misc: switched to visual studio 2017 (also for updater)
misc: updated zipArchive lib to 4.6.5, 7z sdk to 18.01
if you have problems with the update process in 4.033, you can download an updated update.dll here: https://mamedev.emulab.it/clrmamepro/binaries/update.rar
-
I tried using the update.dll you linked but it didn't work.
So, I updated downloading the zip and extracting on top of the installed files.
Now, after it's updated and working, if I check if there are new versions available within clrmamepro itself, I get "Can't receive version information!".
Using 64-bit on Windows 7.
-
Hmm...no issues here with the new dll from 3 different machines in 3 different networks....The old dll does cause issues though.
-
How can I help you check this problem? Perhaps sending you somehow all files of clrmamepro's folder?
-
No xp support ?
https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2017-compatibility-vs
Windows XP Yes
Managed development requires using Visual Studio .NET multi-targeting. Remote debugging and profiling tools are not available.
-
coccola: you actually can't help. The server seems to send a HTTP error code 400 from time to time (bad request) which seems to be caused server sided (since the cmpro request does not change). Since it's not my server I cannot do anything (however I informed the server owners, but no reply). Lately I was able to 'fix' this behaviour by changing some http headers here and there and as mentioned, it works flawlessly on any machine/network I've tested so far (while the old code still fails). So it is somehow network/server related...my DNS cache...maybe just a random thing on the server....
zitz: No xp support ? NO, no XP support. XP is dead. Microsoft's end of support was 2014. Upgrade!
To be honest, I usually compile a limited version which still runs on XP from time to time. So...you might see one download link sooner or later.
Update: XP Users please test this.... https://mamedev.emulab.it/clrmamepro/binaries/cmproXP..rar
-
Failed to load 7Zip Library: 7z_32.dll
-
you've extracted the file into your installed cmpro folder( and replaced the existing exe) haven't you?
-
@Roman
OK, thank you for your reply. It looks like I'll have to update manually from now on.
-
you've extracted the file into your installed cmpro folder( and replaced the existing exe) haven't you?
Were you referring to me ? no, it was run standalone in its own folder
-
zitz: yes...of course the rar archive only holds the exe which (should) run under XP. you need a 4.034 installation first, then replace the exe.
I just saw that the executable in the rar file is not named cmpro.exe but ClrMamePro.exe, so after unpacking it, you need to run that one (in your cmpro folder with all the other files from the normal installation)
-
Good afternoon,
I just upgraded to 4.034 this morning and noticed that after I dragged all the xml files from the MAME 0.195 hash folder then attempted to sort the resulting list by clicking on the Profile column, the software lists names were not ordered alphabetically as in previous versions. The Profile column displays the description attribute of the softwarelist element but the new sorting behavior appears to be using the name attribute or filename as its sort field. From what I can see, version 4.033 sorting was based on the description attribute which is what's visible to the user. Is this the intended behavior?
Thank you for your help
-
erm...nothing has changed regarding profiler sort or profile naming of software lists for ages....
I've just dropped all of MAME's hash files into the profiler and created profiles for them and they appear as usual, listed by description...and sorting works fine...see attached picture..
so.....all I can say....It works fine here....
-
Good afternoon Roman,
Thank you for your reply. I think I know what's happening here.
Your screenshot shows loaded and scanned profiles which is a step passed what I was observing or reporting. Sorry for the confusion!
Right after you drag and drop the xml files from the hash folder then click on the "[NEW DATAFILES]" folder in cmpro, the list of profiles will initially be sorted on the filename or "name" attribute of the "softwarelist" elements of those hash file.
This is where I was trying to sort the profile list so that I could remove the "VTech V.Reader - Storio cartridges" profile from before performing a scan in batch mode.
I just repeated this steps this morning to confirm that the problem was still present.
Once the profiles have been scanned, sorting on the Profile column will work as expected.
I'm attaching a screenshot which should depict the problem.
(http://Untitled.png)
Again, thank you so much for this awesome tool! :)
-
Yes, when they are in "new datfiles", cmpro additionally shows the path...but still the name is the description (e.g. 3do_m2.xml versus 3DO M2 CD-ROMs).
-
I understand and agree with your response but in my screenshot "path\Sega 32x cartriges" comes before "path\3DO M2 CD-ROMs".
Shouldn't it be the other way around?
You'll also see other profile names in that screenshot that are out of order.
-
ehehe...good point ;-) Yes you're right and I actually found the belonging source code for it. It uses the description BUT NOT if it's a new profile...there it uses the filename as sort criteria... ;-)
I have no idea why though...pretty damn old code part.....but by looking at the code I can say...back then....it was made intentionally
-
yes...I was definitely mistaken when I said earlier that this was working in previous version. :-[
In any case, I'm happy to see we're both on the same page. :)
-
you might want to give this a try....
https://mamedev.emulab.it/clrmamepro/binaries/cmpro20180302.rar
-
yesss...Looking perfect! :)
I also re-scanned all software lists in batch mode to make sure everything was still green.
Did you find out or remember why the old code was intentionally using the filename as sort criteria? Just curious.
I'm guessing this new code will be merged into the main branch for the next official release.
Thanks a million Roman. This is very appreciated!
-
yes it will be part of the next release....regarding the old code...well...I guess originally for new datfiles it showed the pathname + datfile filename....and the sort was correct....and then I most likely changed the filename part to description but kept the path part before it and forgot to update the sorting, too...or something like this....
-
Hi Roman, just to let you know...I am still getting the "Can't receive version information!" even after replacing the update.dll you link to.
-
cmnpro stops to respond and crash itself upon todays win 10 system update any solution?
-
solution: provide any useful information...like what did you do, what files were involved etc etc etc...
-
I am using clrmamepro in WINE... when I press the Alt-Key while clrmamepro scans or rebuild it pauses completely. It starts working again when I click on the window.
Is this "normal"?
-
Hehe..cool ain't it ;-)
With the ALT key in windows programs you turn on the key shortcuts for options....when you press it (e.g. in the scanner window) you will see characters underlined...pressing the key belonging to the character will toggle the option...
so windows simply waits for another keystroke then.....
-
I see... I noticed this when I press "Alt+Tab" to switch to another window. It pauses then for me. Maybe WINE handles this wrong...
-
it's nothing I can change....
-
The latest build is crashing during rebuilding the roms. I'm on Windows 10 x64. Also, the main clrmamepro site's 403'd. Both needs to be fixed.
-
as you can read here in the forum, the downtime of the main page is intended....
and there is no crashing.....you are the first who reported this.....so you may want to give more details on your setup, the used files etc.....maybe you got somewhere a corrupt archive or faulty hardware etc etc tc....without detail, e.g. a rebuilder log, Incannot help you.
-
Hi Roman,
Any way to fix this error I get all the time (Currently using latest Nightly but happens with earlier versions too)...
-
No, actually I cannot fix it since it's not related to cmpro but to the https network connection......the server's response says rejected...for whatever reason.....
You can try to press the button multiple times but for some users it seems not to work and the network somehow blocks them....
Actually a lot of users tested it (myself from 3 different networks) and don't get the problem with 4.034 onwards at all....(Windows 10 pro, April 2018 release, 64bit)...
But don't worry...if there's a new version out, you will find it here (or at least the information for it) in the forum
-
Ok thanks, is there a way to stop it popping up all the time?
-
what do you mean with all the time????? It only happens when you check for an update....which happens when you either clicked "Check Now" in the about update -> dialog...or you've set the selection to check it daily/weekly/monthly......so go there and switch to "never"
-
If I have the update check to weekly, every time I open "Settings" (Or any other window) I get the above prompt.
-
most likely because it does not save the last time since the connection failed....so simply put it on "NONE"....there is no new version planned anytime soon....
-
Well Roman, clrmamepro is working, but only in Safe mode on Windows 10. I can't give you an error report if the application keeps crashing in Normal mode when rebuilding ROMs or scanning for ROMs. Hopefully, the next build can correct the problem.
-
The rebuilder is the module which is used so often by so many people in their daily work and noone reported a problem yet.....so I guess it is really your problem...so we need to find out what is wrong. As mentioned, it can be anything.....a bad archive file which is processed by 7z/rar/zip dlls.....even cpu overheating or bad ram can be the issue....or bas usb drivers when working with external drives......also virusscanners are known to interfear...and if you are saying it only works in Win10 safe mode it only hardens the idea that something is wrong with your system....
so...the only thing you can do at the moment is, use the latest nighly build, try to minimize the files you are rebuilding...turn on rebuilder logging to see which files are processed or at which point it fails. try to have a minimum set of files where you can repeat thej problem, archive them together with your cmpor installation and let me look at them.