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.

1

clrmame Discussion / Re: ClrMAME 64 bit crashes under Wine

« on: 07 September 2019, 12:20 »

I am using clrmamepro 64 bit under wine on linux and while it's not 100% flawless, it's definitely functional. I'm using wine 4.14 at this time because 4.15 introduced some glitches in other programs I use, but clrmamepro was working ok under 4.15. My suggestion would be to open up winecfg and add cmpro64.exe to the Applications tab, and then kick the settings around and see if you can make any difference. My emulated windows version is 10, and I use "Emulate a virtual desktop" on the Graphics tab. I hope you can get it fixed.

2

clrmame Discussion / Re: clrmamepro 4.025 released

« on: 18 October 2015, 14:18 »

No problems thus far with that build, so I think you fixed it. Thanks!

3

clrmame Discussion / Re: clrmamepro 4.025 released

« on: 15 October 2015, 15:19 »

I did some experimenting loading a problematic dat in a totally fresh install of clrmamepro (4.025 x64 on Windows 8.1). The program crashes when loading it about 70% of the time. It's always during 'Generating Set Hashes', but the % complete when it happens jumps around. So you're on the money when you say it should crash more or less randomly, but a totally fresh install can't be affected by old cache and hash files.

Here's the dat I'm working with.

4

clrmame Discussion / Re: clrmamepro 4.025 released

« on: 14 October 2015, 19:12 »

Hey Roman, I'm having some trouble with this version. The program will crash when I'm trying to load updated versions of certain dat files for the first time. It just started after I updated to 4.025. Clearing the cache first seemed to make it work yesterday, so my feeling is the program is trying to use an old cache with a new dat. This didn't work for me today, however. It's kind of hard to pin down, so I don't have a reproducible test case to send you yet, but I just wanted to give you a heads up. In the next few days I should have some time to try to reproduce what I'm getting on a fresh install and I'll follow up once I do.

5

clrmame Discussion / Re: clrmamepro 4.014a released

« on: 27 March 2014, 14:37 »

Looks good. Thanks!

6

clrmame Discussion / Re: clrmamepro 4.014 released

« on: 26 March 2014, 19:01 »

I think the "case fix for rar/7z without using their rename operations removes file and leads to crash" issue is occurring again in 4.014. 4.012b and cmp20140313 work fine. I didn't grab cmp20140314 so I can't test that build. Actually there may be two problems because cmpro doesn't seem to be using the exe rename when it should.

Using a process monitor, I can watch cmp20140313 make the call to '7z.exe rn' to do the rename, and it works fine. 4.014 calls '7z.exe d' instead and then does something with a .cmp_dummy file and promptly thereafter crashes, and the file is deleted.

Let me know if you want me to send you some test files.

7

clrmame Discussion / Re: 7z blockwise memory decompress

« on: 14 March 2014, 17:17 »

Starshadow please,
Some feedback if you will, for the massive over 4Gb archives, even with the 32Bit CMP if possible.

>4GB 7z archives have no unique problems in cmp20140313 both 32 and 64 bit. Testing, hash checking, and extracting for rebuild all seem to be working fine for them. The hash checking could be faster for large files if it used multi-threading and multiple buffering, but that's a discussion for another day . Thanks for your hard work Roman!

8

clrmame Discussion / Re: 7z blockwise memory decompress

« on: 13 March 2014, 12:00 »

cmp20140312 64-bit solved the issue I reported when running a scan with the 'Test Archives' option turned on, but as oxyandy alluded to, now when running a New Scan with the 'Decompress ROM & Check...' options enabled, I get 'error while unpacking 7z file:' and 'Archive Header CRC32 doesn't match CRC32 of decompressed data for file:' for every archive. Rebuilding to/from 7z seems to be ok to me though, he'll have to provide more info on what he's seeing there.

9

clrmame Discussion / Re: 7z blockwise memory decompress

« on: 12 March 2014, 16:27 »

Starshadow, what about without -  'Test archive (decompress to memory) (Scanner only)' ticked ?
(or in Scanner - 'Hash & CHD' - "Decompress Rom & CRC/SHA Check" checked.)
Just a regular 'New Scan' ?

New Scan without either option checked works just fine. The "Decompress Rom & Check..." options appear to work fine as well.

10

clrmame Discussion / Re: 7z blockwise memory decompress

« on: 12 March 2014, 13:07 »

CMP actually does completely extract and check each file & the test passes !
So the 'get nothing' is a little extreme.
It seems CMP is falsely reporting the error in the warning window, but completing the task successfully anyway.

I tested on some very large >4GB 7z files first. They failed with the aforementioned warning before enough time had passed to simply read the entire archive from disk let alone test it. When I tested smaller files, I got the exact same behavior. I didn't see any indication that any of them successfully tested.

11

clrmame Discussion / Re: 7z blockwise memory decompress

« on: 12 March 2014, 00:21 »

Ready for bugs? Using the 20140311 64-bit build, running a scan with the 'Test archive' option enabled, I get nothing but 'error while unpacking 7z file' in the Warnings window. The archives test fine in 7zip. Archive size or algorithm doesn't seem to matter.

12

clrmame Discussion / Re: [BUG] RAR volume open lockup

« on: 21 December 2013, 20:30 »

http://mamedev.emulab.it/clrmamepro/binaries/cmp20131221.rar

Rar deletion is working fine again in this build. Thanks!

13

clrmame Discussion / Re: Disabling 'Recompress Files' when rebuilding to 7z files

« on: 21 December 2013, 16:40 »

Fair enough. Thanks for considering it. I'm thinking about a workaround. I can just move all of the source 7z files into the rom path and let clrmamepro rename the ones that are sets and backup the ones that aren't.

14

clrmame Discussion / Re: [BUG] RAR volume open lockup

« on: 21 December 2013, 02:21 »

ok...changed the way to get the volume names (also via callback)....
http://mamedev.emulab.it/clrmamepro/binaries/cmp20131220.rar

Sorry, but the only difference I see running this build is that part 2 and 3 of file4's rar get deleted, but not part 1. Everything else is the same.

modifying multi-part-rar files seems to fail though...but this is a general limitation (if I run it from a commandline I get the same error)....hmm...don't know if that was different in the past.

Modifying multi-part rar files has always failed. You're right, it is a WinRAR limitation. However in clrmamepro 4.011a, if all the files in the archive were going to be deleted, the archive files themselves were deleted without an attempt to modify them. That doesn't seem to be working anymore.

15

clrmame Discussion / Disabling 'Recompress Files' when rebuilding to 7z files

« on: 20 December 2013, 22:23 »

I know this has been discussed before, and I know that the reason 'Recompress Files' is permanently enabled when rebuilding to 7z files is because there is no code in the 7z SDK to deal with compressed files without decompressing them. But hear me out.

If clrmamepro could determine that a source 7z file already contains a complete set, and that set is currently missing entirely from the rom path, then that 7z file could just be moved or copied straight to the rom path, avoiding comparatively lengthy compression jobs. If the name of the 7z file or the roms is wrong, that could be fixed with rename operations instead of recompression.

Is there something I'm missing that would make this not possible or not make sense? If not, then I'd like to request it as a feature to be enabled by unchecking the 'Recompress Files' checkbox in the rebuilder when 'Compress Files' is set to '.7z'. I've got some rather large 7z files that meet the above criteria and I'm finding myself cancelling the rebuilder on them and moving and renaming them by hand, and it would just be nice, as always, for clrmamepro to do the work for me.

Cheers!

16

clrmame Discussion / Re: [BUG] RAR volume open lockup

« on: 20 December 2013, 18:22 »

I've also noticed that with latest winrar clrmamepro does not wan't to remove files inside rar files but packing works good.

I'm encountering this as well, with WinRAR 5.01 x64 and clrmamepro 4.012 x64. It does not occur in clrmamepro 4.011a with WinRAR unchanged.

I've built a test dat and then rarred the files in various ways. (Dat attached, rar files Here.) Extract the rar files from the zip to a folder and then rebuild the dat with that folder as the source and "Remove Matched Sourcefiles" checked.

Rebuilding under clrmamepro 4.011a, everything behaves as expected. file5 is deleted from the rar file but the rar file itself is not deleted because it contained other files. file6's rar file is untouched because it is a multi-part rar file that contained other files. All other rar files are deleted.

Under clrmamepro 4.012 however, the results are different. file1 is deleted from the rar file, but the rar file itself is not deleted leaving a rar file containing only an empty folder. file2, file3, file4 and file6 are not deleted at all (Produces warning message: "can't remove file(s) from..."). file5 is the only one that is deleted in the same way as under 4.011a.

17

clrmame Discussion / Re: EXE Renaming for fixing case

« on: 11 August 2013, 15:05 »

Fix case is very quick now. Thanks!

18

clrmame Discussion / Re: EXE Renaming for fixing case

« on: 06 August 2013, 20:23 »

Ah, fair enough. Thanks for the fix.

19

clrmame Discussion / Re: EXE Renaming for fixing case

« on: 06 August 2013, 11:24 »

Thanks. It's using the exe now, but why are you doing the _cmpren step? Both 7z and WinRAR seem to be able to change case from command line in a single step in my testing.

20

clrmame Discussion / EXE Renaming for fixing case

« on: 04 August 2013, 10:26 »

It seems that EXE renaming is not utilized for fixing case. Can it be? Thanks.