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

Pages: 1 2 3 [4] 5 6 7 8 9 ... 165
61
clrmame Discussion / clrmamepro 4.047b released
« on: 22 October 2023, 16:58 »
4.047b
fixed: don't mark delta chds as missing
misc:  updated unrar (6.24.0)


 I will think about additional options (like optionally marking found not-delta chds and maybe a conversion tool/update opption) but for this I need more time.

62
clrmame Discussion / Re: Delta CHDs new feature.
« on: 22 October 2023, 12:26 »
ok...attached a quick version so that cmpro works again....can anyone give it a try for delta chds?

Thinking about

a) an optional warning if found clone disks could get replaced by a delta
b) maybe a standalone tool for converting....(guess that can be achieved quicker than adding some conversion thing into old cmpro..)

but don't count on a) and b) in the very near future....

63
clrmame Discussion / Re: Delta CHDs new feature.
« on: 22 October 2023, 07:22 »
Yeah yeah keeping an old man busy....

Thanks for the testing and information....First thing I will do is of course checking why a delta is not recognized when it got the correct name in the correct place...most likely because the chd header changed a bit...

"fixing" or better "auto-create a delta" out of a found non-delta clone....hmm....will see if this is easy to add (well it is...but I have very limited time).

Question is if (or if it makes sense that) each and every clone chd can be converted to a delta compared to its parent. Haven't checked yet but I'm sure that there are sets with multiple chds and maybe a clone of it also has multiple ones...question is how to find the correct parent chd to the clone chd in such a multi-case.   ....most likely if the region entries match...like "region="pci:05.0:ide:0:hdd"" ...


to sum it up: I try my best to update cmpro as quick as possible....

64
clrmame Discussion / Re: Delta CHDs new feature.
« on: 21 October 2023, 20:36 »
Well, I think regarding auditing nothing much will change. I haven't looked at the changes yet, but I assume that

a) the hash / name values of the disk entries in -listxml output doesn't change
b) the chd header will get some additional flag that shows that it is a delta chd

cmpro reads only the chd header and compares the hashes against the hashes in the xml output ...so that will still work....a deep check is done via chdman anywhow...so I think that will also still work since they probably update chdman's test routine...

....so in the end it might be only something like "couldn't cmpro show me that I am able to use a delta chd instead of a full one" request....

but hey...I might be wrong...time will tell....thanks for the headup

65
While testing rebuilder/scanner the following drove me nuts...updating mame.ini with the generated paths from the upper mentioned methods didn't work. "MAME -rompath f:\mame\roms\#default pacman" did work, but adding "f:\mame\roms\#default" to mame.ini failed....so I wondered why...and oh man...feeling stupid......having a "#" as some prefix in a rompath is not a good idea for usage in an ini file. It simply takes the rest of the line as comment :-)

So your rebuilder settings.xml should use either your own values or the following new defaults (without the #)

      <TypeNames>
         <Bios>bios</Bios>
         <Mechanical>mechanical</Mechanical>
         <Default>default</Default>
         <Device>device</Device>
         <BiosSplit>bios_</BiosSplit>
      </TypeNames>


Will be updated for next release.....

66
clrmame Discussion / Re: support empty directories
« on: 12 October 2023, 06:52 »
So not really MAME related ;-)

<rom name="2D/" size="0" crc="00000000" md5="d41d8cd98f00b204e9800998ecf8427e" sha1="da39a3ee5e6b4b0d3255bfef95601890afd80709" />
<rom name="A/" size="0" crc="00000000" md5="d41d8cd98f00b204e9800998ecf8427e" sha1="da39a3ee5e6b4b0d3255bfef95601890afd80709" />
<rom name="audience/" size="0" crc="00000000" md5="d41d8cd98f00b204e9800998ecf8427e" sha1="da39a3ee5e6b4b0d3255bfef95601890afd80709" />

hmm...wonder where md5/sha1 comes from ;-)

Well, easiest would be to auto-add an empty file when it finds a name ending on "/" when it loads the dat
...but then of course you'd have to add the files (can't get rebuilt due to missing hashes)...
will think about it....but don't count on any solution any time soon ;-)

67
clrmame Discussion / Re: Titles setup (non-zipped)
« on: 08 October 2023, 18:47 »
No setting needed. You only have to care about the storing method which I described in the other post. Look at the datfile and which setnames it uses and think again how you store them on your disk and how your rom path needs to be selected...

So for example for the titles datfile which includes also software list titles, you will see setnames like 3do_m2, 32x, a800 .....titles .....xegs.
Your rompath needs to be setup as a folder which contains the mentioned ones...for example:
"F:\MAME\Progetto\progetto-SNAPS - Titles" and then you e.g. have "F:\MAME\Progetto\progetto-SNAPS - Titles\titles" with F:\MAME\Progetto\progetto-SNAPS - Titles\titles\1on1gov.png .... F:\MAME\Progetto\progetto-SNAPS - Titles\titles\zzzap_audio.png in it...

So, "titles" is a setname, "F:\MAME\Progetto\progetto-SNAPS - Titles" is a rompath.

The non software list progetto dat (progetto-SNAPS - Titles NS) only has 1 set: "titles". So your setup rompath needs to be a folder which contains that setfolder and it should not be that folder.

again:

rompath\setname\file 1... file n
rompath\setname.zip (.rar/.7z)

the set, no matter if archive or folder is just a container holding single files for the specific set.....in the progetto snaps world you often only have 1 set containing thousands of files (the pngs)


Also keep in mind that anything which is in a rompath and doesn't belong to the loaded dat becomes unneeded.

So don't think about storing all progetto snaps collections in one rompath....you will need some kind of double folder structure:

F:\MAME\Progetto\progetto-SNAPS - Artwork Preview
F:\MAME\Progetto\progetto-SNAPS - Cabinets
F:\MAME\Progetto\progetto-SNAPS - Control Panels

and so on where the upper ones hold the setfolders...

F:\MAME\Progetto\progetto-SNAPS - Artwork Preview\artpreview
F:\MAME\Progetto\progetto-SNAPS - Cabinets\cabinets
F:\MAME\Progetto\progetto-SNAPS - Control Panels\cpanel

and so on...



68
clrmame Discussion / Re: Titles setup (non-zipped)
« on: 08 October 2023, 08:48 »
clrmamepro supports not compressed sets since 1997 ;-)

In general it follows the storing methods:

rompath/setname/file 1 ... file n for decompressed sets
rompath/setname.zip (.rar/.7z) ... where file 1 .. n is in the archive

So you only need to be aware of the fact that you a) have a rompath and b) in the rompath there is/are folder(s) which correspond to the set name(s) and then finally in such rompath subfolders there are the singe files belonging to the set.


By the way: Since progetto datfiles usually are 1-set-billion-of-png files datfiles and use lots of placeholder pngs, you can reduce scan time by turning of fix-missing (and the scanner advanced options belonging to fix-missing). And solid 7z archives would be a pain to fix, so generally rebuilding would be a better option to add files.

69
clrmame Discussion / Re: support empty directories
« on: 07 October 2023, 08:52 »
Do you have an example dat?

70
clrmame Discussion / Re: [REBUILDER] multiple INPUT sources
« on: 04 October 2023, 16:45 »
Only one is currently supported ( optionally recursive ).

71
clrmame Discussion / Re: MAME SL: Fujitsu FM Towns CD-ROMs
« on: 04 October 2023, 15:06 »
Your file/folder structure should look like:

<rompath>/aressh4.zip (holding a-iv-systemdisk_new.hdm)
<rompath>/aressh4o.zip (holding a-iv-systemdisk_old.hdm)
<rompath>/aressh4/aiv - a ressha de ikou 4 (japan).chd

any other aressh4* folder/file is obsolete

72
For that test I've used a rebuilt archive, not the one you had in your archive. The problem is based on an archive file index / order problem.

When a rename operation fails (and in that case, 2 renames fail since the right name already exists in the archive), it moves the not renamed ones to backup (so they can be picked up later on again). So it made a backup of file 5 and 6 for example. So far so good. Unfortunately, it directly removed the files, so it copied 5 to backup, removed 5, copied 6, removed 6 without having the indexes refreshed in between. So when it removed 5, copying 6 was simply the wrong file.
In my case the archive order was simply the other way around. It copied 6, removed 6, copied 5, removed 5, so it always picked the correct ones. To understand this: The backup copy is index based, the removal is filename based at that point...
So it only happens when more than 1 file failed during rename (where the right name files also exists in the archive)

The fix is pretty simple, do the removal of all of the backup'ed files after the copy....

73
clrmame Discussion / Re: Download 404?
« on: 26 September 2023, 20:23 »
Maybe refresh your browser cache....(e.g. by loading the page via CRTL-F5) the links work fine here.

74
nice finding......it actually backup'ed the wrong file (when there were more than 1 in the queue....in a failed rename...blablabla...) Thank god the new scanner won't have such special things....

75
clrmame Discussion / clrmamepro 4.047a released
« on: 26 September 2023, 15:22 »
4.047a
fixed: pick wrong file for backup during a failed rename where multiple files are involved


Tiny one...but might become useful for next MAME......

76
Found and fixed....was an index problem when a backup is done when a rename failed (since the new name already exists).

New version later today....

Thanks a lot for finding that one

77
Guess what, while I can't repeat it on one machine, I did the test on another this morning and there I can repeat it. Hmm...Maybe some kind of order/timing problem...I will do further checks.

78
ok I've tried it again with the released version....and I can't repeat it at all.
Simply running a full fix scan twice ends up with a good set, nothing's lost.

79
Hmm....actually it works for me fine now.

By the way, scanner's fix missing automatically looks in your backup path for matching files which were removed in a previous unneeded case.

So I run a full fix scan, it reports missing rom: hipoly\1.11d and missing rom: hipoly\2.4a
Pretty normal for now, since they were moved to backup. Another scan will show them up as fixable and cmpro wants to readd them fine.
So nothing is lost.

Today I don't get the unpack file problem which may be the cause of the reported issue (an unpack to backup failed but the file was removed).
I will look into that again but for now I cannot repeat it. The unpack might have failed because for whatever reason the backup file already exists (however cmpro uses a new file name then....weird...)...as I said...I will double check that.


Update: Hmm...ok..one thing...yesterday I've tested it with the released exe and today with a debug version. Same code basis but updated visual studio (and of course debug mode)...maybe that's the difference....Will check when I'm done with real life work...

80
Well, yes, interesting. It all happens since one of the rename step fails ("Unpack failed on file -> E:\Temp\test3\trackfld.zip\hyprolymb\3.a4") and you/cmpro continues with fixing the unneeded fixes...
I will have a closer look at it tomorrow.

Pages: 1 2 3 [4] 5 6 7 8 9 ... 165

Page created in 0.163 seconds with 19 queries.