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.

Topics - Starshadow

Pages: [1]
1
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!

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

3
I very much appreciate all the recent improvements that have been made in regards to cmpro's handling of 7zip archives. It's far and away the best it's ever been. But there's one thing that's bothering me about the use of the 7zip alpha 'rn' command.

If I'm correct, before calling 7z.exe 'rn' to rename a file inside an archive, it looks like cmpro calls 7z.exe 'd' to delete any file that already has the new name. Now, this is as much 7zip's fault as cmpro's, but instead of recognizing when no file exists with the new name to delete and quitting, 7z.exe processes the entire archive anyway. This results in the entire archive being processed once for a usually fruitless delete, and again for the actual rename, making any 7zip file rename operation take exactly 2x longer than it should. When renaming sets of many large archives, this time adds up quickly.

If possible, could you please add a check to see if a delete is actually required before calling 7z.exe 'd'?

Thanks.

4
After renaming an XML dat profile via right-click -> "Rename Profile" in the Profiler window, the XML dat becomes corrupted and the profile will no longer load properly. This image shows the original dat on the left, and the same dat after being renamed on the right. The problem is the duplicated tags and extra </header> tag after the first </header> tag. Manually removing these repairs the dat. Non-XML dats are not affected. I am using clrmamepro 4.08b x64 on Windows 7 x64.

If I could throw in a somewhat related feature request: it would be nice if upon updating a previously renamed profile with a new dat version, the custom profile name was carried over after the update. Currently the profile name is overridden by the new dat, and any custom name must be re-entered.

Thanks!

5
clrmame Discussion / Feature Request: More descriptive warnings
« on: 02 December 2011, 21:01 »
When running the Rebuilder, occasionally messages are logged to the Warnings window like "CRC error" or "Volume Open Error" without specifying which file caused the error. It would be more useful if these messages included the path and name of the offending file like with the "can't remove file(s) from..." messages. Thanks.

6
I would like to request that you investigate the possibility of updating the version of the LZMA SDK used in clrmamepro in order to properly support 7z archives using the LZMA2 compression method. clrmamepro is already able to compress files with LZMA2 by modifying the 7z compress arguments, and it is able to read file names and hashes from 7z archives using LZMA2 like any other 7z archive. However, errors arise when clrmamepro tries to extract an LZMA2 compressed file from a 7z archive (either for renaming or backup). I know the LZMA SDK has a long and storied history of being pretty terrible, but if it's as simple as updating the version, I would really appreciate if you would. My reasoning for wanting this is that I'm encountering files which come out larger after being compressed with LZMA, and this 'feature' has been disabled with LZMA2, so I would like to be able to deploy it across all my sets without the major inconvenience of needing to manually maintain the files. That's what clrmamepro is for, after all. :) Thanks for your attention, and the time you put into clrmamepro.

Pages: [1]

Page created in 0.198 seconds with 18 queries.

anything