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 ... 23 24 25 26 27 [28] 29 30 31 32 33 ... 172
541
clrmame Discussion / Re: Dates don't match
« on: 11 January 2021, 08:34 »
Actually the latest nightly works like this:

- Rebuilding to zip with recompress enable, creates the right date from the dat
- Rebuilding to a decompressed file on NTFS, rar and 7z creates a file where the offset to UTC is included..

- Scanning/fixing a zipfile works fine
- Scanning/fixing decompressed/rar/7z will create a fixing loop due to the UTC offset

I love it...*sigh*...working on the decompressed/7z/rar time handling.....till then..use zip :)


ok...tried to handle decompressed files now as UTC based (which also is the reason for 7z/rar)

https://mamedev.emulab.it/clrmamepro/binaries/cmpro20210111.7z


This should fix the upper stuff...again I find it hard to say what is right if we talk about preservation...and especially if you look at it....you see the dat with 00:00:00 and you look at the archive or the file and you see an offset based value......something to think about when I got more time...but at least you shouldn't run into scan time fixing loops.


542
clrmame Discussion / Re: Dates don't match
« on: 10 January 2021, 19:55 »
It does, the problem is your filesystem which applies local timezones...so e.g. for me setting 00:00:00 will end up with 02:00:00 due to the local offset.
I'm working on it...

543
clrmame Discussion / Re: Dates don't match
« on: 09 January 2021, 19:54 »
Ah sorry...... I falsely looked the fix dat which does list 1970 and for 1970 all my comments are correct. Your original dat indeed lists 2010-04-06 which is not parsed correctly and it is reset to 1970 since it's not in correct format. It's being reset since the datetimestamp is missing. The date attribute should hold a date time string... YYYY-MM-DD HH:MM:SS.... or YYYYMMDDTHHMMSS

But I guess I can support a YYYY-MM-DD, too


Indeed I can.....
https://mamedev.emulab.it/clrmamepro/binaries/cmpro20210109.7z

544
clrmame Discussion / Re: Dates don't match
« on: 09 January 2021, 18:22 »
Erm....you're mixing 2 things.....file definitions and actual filesystem dates.

Your datfile defines the files as 1970-01-01 00:00:00. When scanning/fixing decompressed files on an NTFS filesystem, cmpro will fix the last modified date of the files. Windows won't show it correctly though but on commandline level it is shown as 1970-01-01.

Then you got archivers like rar/zip. The rar/zip format uses MSDOS date format which means the earliest date is 01/01/1980.

And if you create a fix datfile cmpro simply dumps the datfile again but limited to your missing files.

545
clrmame Discussion / Re: Dates don't match
« on: 09 January 2021, 08:42 »
If you create uncompressed files you see on commandline level that the date is correctly set.

Archives (rar/zip etc) store dates in standard MS-DOS format which only allows dates from 1980 onwards....

Bits 00-04: day
Bits 05-08: month
Bits 09-15: years from 1980


So...everything is fine

546
Cache doesn't play a role here....but good to hear it's working for your.

547
ok...found the problem, it was related to the length and there was one place in the zip code where the auto-32k support was not enabled yet...
Will be fixed in the next nightly (whenever that is coming).

Thanks.

https://mamedev.emulab.it/clrmamepro/binaries/cmpro20210108.7z

548
Thanks...I will have a look in the next days...

549
Can you provide the files somehow?
Besides the roms, cmpro.ini, the used datfile and the belonging *.cmp file from cmpro‘s settings folder.

550
clrmame Discussion / Re: ..SL CHDs and right place problem
« on: 04 January 2021, 15:10 »
There is nothing wrong. The chd is detected as unneded and moved to backup when you tick yes/yes to all.
Your datfile has no parent/clone relationship between the 2 dbz sets (the official MAME .227 one does have a relationship), so the file in the wrong folder is unneeded. Of course cmpro can auto-move it to the correct place if you simply put it in a rompath root.

551
MAME told you?
If clrmamepro told you that no valid sets were found, you most likely did not follow the official storing schema which I already menioned in this thread (rompath/setname/file 1.. file n, etc..etc..)

But of course by converting the files to chd, you change the names (*.cue/.img to .chd) and since you did not update the datfile cmpro tries to use the hash to get the correct name of the new file...which will fail since you did not update the dat ;-) And unneeded files get removed (if you got unneeded check enabled and fix options on).

So...maybe you should reduce the scan options to "missing" only.

And again...what you try to achieve is a bit away what auditing is all about. You change formats, filenames and number of files and you don't update the used database (datfile) and expect that it will work out of the box ;)

552
Thanks for this answer. I understand that the dat file is the issue here. I just wish there was a way to let a rom manager scan for file names listed in the dat, and not the extra information, such as crc32/sha1, etc.


Erm....clrmampro can do that. Simply turn off the checksum check.
But of course some other tests still need hashes to work correctly. For example if a file got a wrong name a match with the hashvalue will find the correct one.

553
Maybe the following helps to understand better:

Let's assume you currently use cmpro to scan your dreamcast/etc files in cue/bin format.
For this, you need a dafile which lists the sets with the individual files. They are listed there with size, name, hash information. It holds all sets which the datfile author added to the datfile. A set is collection of roms and/or samples and/or chds. A datfile is a collection of sets.

Now if you decide that you compress your files, you actually change information which is listed in the datfile. While you can compare a CHD with a zip container in terms of compression, you can't compare them in terms of auditing. You would be able to compress your sets to 7z/rar/zip and you would still be able to scan/audit them. But CHD is different, a chd is part of a set and not a compressed representation of a set.

So you can of course use 7z to compress your sets (cue + img + whatever other files are listed) to an archive and are still able to use the datfile.

If you really want to use the chd way and still want to scan your sets you can edit the used datfile and change the sets you converted or ask the original datfile author if he/she wants to provide a chd version :)

554
I don't really understand your scenario...since either you have a datfile for dreamcast/etc and you are able to scan your not chd-converted images (and you know what is missing), or you need to setup a datfile on your own...which will take your existing chds as basis.....or you find a datfile which uses chds instead of raw images.

well....I hope you understand the main point. The main factor is your datfile.
You need to understand what it means if you the datfile lists the file as chd or as rom.
You can of course list the chd file as a rom, then the rom crc32/sha1 are the hash values of the chd file. If the datfile lists them as disks, the given sha1 is the hash value of the decompressed file.

So...if you on your own decide to compress images as chd files, you need to ensure that you have a datfile handy which supports your task.

So maybe I should rephrase my answer.
Of course you are able to scan for missing files (whatever they represent), as long as you use a correct datfile for your task.

555
CHD stands for  "C"ompressed "H"unks of "Data", so it's a container (like a zipfile) for files, in this case hd/dvd/ld/floppy/etc../etc dumps.
Using chdman to convert your files to  a CHD is one thing, auditing is a different. First of all, you need to specify the chd in the datfile. Take a look at for example MAME's -listinfo output. CHD images are encoded in disk xml elements listing their decompressed sha1 values (which is also stored in the chd header).

For example:
<disk name="a51site4-2_01" sha1="48496666d1613700ae9274f9a5361ea5bbaebea0" region="ide:0:hdd:image" index="0" writable="yes"/>

So you need a custom datfile to check your sets since you need to tell cmpro what to look for and what the correct hash values are.

Secondly, you need to follow the general storing method, which is coming originally from MAME:
rompath\setname\file 1... file n for decompressed sets
rompath\setname.zip (.rar/.7z) for compressed sets
A set is a collection of roms and/or samples and/or chds. Since it doesn't make sense to put chds in another archive (7z/zip/rar) you store them in the first described way. For example:F:\MAME\ROMs\Standard\a51site4a\a51site4-2_0.chd where F:\MAME\ROMs\Standard is the rompath, a51site4a is the setname (defined in the datfile) and a51site4-2_0.chd is the actual chd file. Its base name also comes from the datfile.


So coming back to your question "My question is whether it is at all possible to scan my collection for missing roms ect. even though I converted my sets to .chd", the answer is no since the custom datfile will only contain information about the chd container and not the single files inside the container. You can scan for missing chds and sets of course but everything the rommanager knows about is what you (or whoever) defined in the used datfile.

556
I'm not sure I understood which OK you're talking about.
Unless you have a hard error (there are some prompts which appear when a file can't be added to an archive for example), you can configure the batcher that no "press OK" is needed.

Batcher options: Scanner: "Don't show statistics" and "Don't ask before fixing", Rebuilder: "Don't show statistics", Misc: "For updated dats: "auto update" should do it.

557
clrmame Discussion / Re: Missing ROMs but empty scan results
« on: 02 January 2021, 20:04 »
If you got dupes (identical sets exist in various rompaths) after running a rebuild, you may have rebuilder settings which don't match the scanner ones (e.g. you don't use sysdefpaths in rebuilder while you do in scanner). So a set might get rebuilt to a not wanted place accidently.
Anyway....Most likely the scan run cleaned them up. There are some rare cases where a second scan run can fix some stuff which a first one popped up.
Nothing really to worry...since your 2nd run seems to resolved it.

558
clrmame Discussion / clrmamepro 4.040 released
« on: 01 January 2021, 18:22 »
Nothing big, but I'd like to start the new year with some better version number  than a or b or something......
Happy New Year, I'm sure it will be better than last. Stay healthy

4.040

fixed: falsely hiding some missing information (split merged sets with nodump chds)

(e.g. MAME AmericanLaser sets)

559
clrmame Discussion / Re: Missing ROMs but empty scan results
« on: 01 January 2021, 16:35 »
Thanks a lot for the files. I've found the problem for not listing the files. Very nice finding.
So update to 4.040

560
clrmame Discussion / Re: Missing ROMs but empty scan results
« on: 31 December 2020, 11:19 »
Did you check if you enabled all sets and all systems?
Maybe you got an option enabled that hides things. So please check the following and do a new full scan.

Scanner->Systems-> ensure that all checkboxes are checked (or hit all)
Scanner->Scan Results->Set Information->Ensure that all sets are selected (e.g. by hitting "select all")
Scanner->Scan Results->Context Menu ->View -> ensure that "hide fully missing sets" is NOT enabled
Scanner->Hash & CHD->Available Regions -> all checkboxes should be checked

If you like you can also send me your cmpro.ini file plus the belonging *.cmp file for your profile in cmpro's settings folder (I assume you're using an official MAME binary as data source)

Pages: 1 ... 23 24 25 26 27 [28] 29 30 31 32 33 ... 172

Page created in 0.115 seconds with 16 queries.