Please login or register.

Login with username, password and session length
Advanced search  


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 ... 127
clrmame Discussion / Re: Dates older than 1980 = Invalid?
« on: 22 April 2019, 20:06 »

there is a check during datfile parsing which checks given dates against MS-DOS (1980+) date format...so such dates won't be accepted, no matter if NTFS will be able to handle it (you'd run into trouble with zipfiles anyway....).

I will do some additional tests for pure ntfs/7z/rar later and may remove the initial check.

update 2:
removing the initial check is not enough since there seem to be some file attribute routines which won't accept files < 1980 either and will convert your 1970 file to something in 2008 ;-) ....so....as mentioned I will do some further investigation but don't count for it in April

clrmame Discussion / Re: Dates older than 1980 = Invalid?
« on: 22 April 2019, 06:48 »
The MS-DOS date format can represent only dates between 1/1/1980 and 12/31/2107.

A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC).

Statndard ZipFiles use Date in MS-DOS format

So in theory, using uncompressed files should work and zip files shouldn't. However due to holiday I haven't checked this yet and I don't know the day formats in rar/7z...have to check that later.

clrmame Discussion / Re: statistics wrong
« on: 08 April 2019, 18:35 »
ok....in case of exisiting separated bios files, the missing rom count will be adjusted....in the next nightly build

clrmame Discussion / Re: statistics wrong
« on: 05 April 2019, 17:28 »
The count is not wrong...it's just how the stats counts work. The rom count does not care about bios/merge but works on the plain defintions. If you miss a set, every file in its definition is counted as missing (as well as each file is counted for the total). There is a slight exception if no dump chds or no dump roms are included. But such files do not exist at all, while the chd belonging to the set is 'real'.

loveber3cn is a set which consists of a chd (mda-c0071) and bios rom (mb_eeprom_exp.ic54s).
Since you don't have the chd, you don't have the set and so the bios rom is counted as missing (and the set is counted as missing, too).

You don't see a message about a missing chd, since the scan tree output hides it when you disabled chds.
You don't see a message about a missing bios rom, since the scan tree output will only list it inside the bios sets themselved.
You migh not see a missing set message if you're using merged sets since then the existance of the parent + biosrom is enough...

You see....Statistic total/missing counts are based on set definitions, not parent/clone/bios relationsships....forget about the numbers...they don't bring you anything....Look at the scan tree output...if it's empty, you're good...but only related to your chosen check options.

Update: However, I will have a 2nd look at it since if biossets are separated and are available it should be counted as available.....but anyway...don't care too much about these numbers...

hmm.....I can't repeat this problem here.

Please double check your setup paths. Ensure that your rompath for orionpro_flop sets really contains the sets (e.g. bascom.7z) and it's correctly assigned to the sysdefault path belonging to the software list orionpro_flop (and not e.g. orion_flop).

I checked with a MAME + single software list import of orionpro_flop but no other lists....do you include more (if not all)?

However, if it does not see a single one of orionpro_flop sets it seems to be more a setup path problem rather than a problem in cmpro....

Ah sorry...I thought you were talking about a nightly MAME version ;-)

I will have a look...you're using standalone profiles for software lists of the all-in-one mode where you imported the information from the MAME binary, so you got MAME sets plus software lists plus the complex setup with sysdefpaths?

Could be anything ;-)
From a bad (or misstructured or not supported) 7z version, to simply bad data in the nightly build of MAME (which happens rather often).
So maybe the SHA1 is correct but not the CRC32 or the size etc....You might want to compare such values against the -listxml output of the MAME binary.

You can also send me the nightly MAME binary (or a -listxml output) and the 7z file in question.

You can use the rebuilder to clean up messy collections. The rebuilder takes all files from a scource folder, checks the hashes against the loaded database and creates all matches instances in the given destination folder. There it uses the correct naming.

Please check if you're following the official way to store sets.

rompath\setname\file 1 ... file n for decompressed sets
rompath\setname.zip (or .rar/.7z) for compressed sets.

"The rompath folder contains 559 *.sms file"  - You see, that's a wrong way. either you compress them one by one or you create subfolders for each set.

You should consider to download the zip version ;-)
Guess I haven't touched the installer for a decade or two ;) I will check it tough...

clrmame Discussion / Re: Empty results window
« on: 04 March 2019, 20:15 »
the nighlly builds only hold the changed files...so yes, you need to copy them over your existing installation

clrmame Discussion / Re: Empty results window
« on: 04 March 2019, 19:41 »
Can't repeat that. What do you mean with latest beta by the way? latest datfile (if so, please provide it) or latest cmpro nightly build.
Ensure you got a stats.ini file in your cmpro folder.

clrmame Discussion / Re: Empty results window
« on: 04 March 2019, 17:11 »
erm....and what exactly is the question/problem?

clrmame Discussion / Re: clrmamepro profiler icons
« on: 04 March 2019, 17:10 »
Did you use the official or a nightly build?

clrmame Discussion / Re: clrmamepro profiler icons
« on: 02 March 2019, 08:51 »
well...the icon is red if the scan tree window got an entry...so maybe you should do a scan again and check if something is listed there.....or maybe you did not enable all sets?

Zum Müllverzeichnis:
Nun ja....man kann Dateien rebuilden und die Option "Remove rebuilt sourcefiles" anwaehlen, dann werden die Dateien, die erfolgreich im Zielverzeichnis erzeugt wurden vom Quellverzeichnis entfernt. Was dann noch uebrig ist, ist nun ja...'Muell', aber wie du schon erkannt hast, nur fuer das aktuell geladene datfile. Klar kann man jetzt andere 3rd Party Programme drueberlaufen lasseun um identische Dateien zu loeschen, aber letztendlich bleiben halt Sachen übrig. Normalerweise (wenn man jetzt zum Beispiel von einer MAME version zur nächsten wechselt) sind das vielleicht bad dumps, die halt durch neue, good dumps ersetzt worden sind. Manchmal werden aber auch Sets aus MAME entfernt (z.B. aus Copyrightgründen), dann sind es natuerlich valide Dumps, die man vielleicht irgendwann wieder braucht.
Letztendlich ist es dir ueberlassen, was du mit den Dateien machst...

Zu CRC32/SHA1....nun ja...CRC32 hat den Vorteil, dass es in den Archivheadern gespeichert ist, sprich, man muss nur das zipfile (7z/rar) einlesen und man hat schon Informationen, ob eine Datei passt oder nicht. Die Datei zu entpacken dauert einfach laenger. Da CRC32 heutzutage aber in MAME auch schon nicht mehr ausreicht um eine Datei eindeutig zu identifizieren, wird dann doch noch der SHA1 Wert ermittelt...indem die Datei in den Speicher entpackt wird. Man kann also via schnellem CRC32 check schonmal aussortieren...und bei einem Treffer schaut man dann nochmal genauer hin....(das laesst sich optional auch abschalten)

Samples gehoreren in einen Samplepfad...Sowohl in MAME als auch in clrmamepro (settings->Pfad Selektor -> sample paths). Wenn man einen direkten MAME import verwendet (oder ein MAME datfile), dann haben Samples keinerlei Größen- und Hashangaben. Sprich, du kannst sie auch nicht rebuilden. Abhilfe schafft ein separates Samplesdatfile (zum Beispiel von Progetto). Dieses beinhaltet Hashes/Größen und du kannst damit arbeiten.

Der Rebuilder (wenigstens der öffentliche ;-)) rebuildet keine CHDs...Das Warning Fenster spuckt aber Information darueber aus, ob er ein valides CHD gefunden hat. CHDs an die richtige Stelle zu manövrieren ist aber auch recht einfach, einfach in einen Rompfad ablegen (also ohne Unterverzeichnis) und der Scanner findet es und verschiebt es an die richtige Stelle (mit Unterverzeichnis und richtigem Namen). Und wie erwaehnt, chds sollten nicht in ein gepacktes ROM Archiv mit reingepackt werden. Seh ein CHD wie ein separates zip File an.

Aaaalso.....CHD = Compressed Hunks Of Data ...mit anderen Worten...ein gepackter Datencontainer....Inhalt des Containers kann z.B. ein CD/DVD/HD image sein...aber durchaus auch andere Formate...Floppies, Laserdisks, etc...und ja, du brauchst sie um das jeweile Spiel zu spielen, denn dieses beinhaltet ja die eigentlichen Daten. Es gibt zum Beispiel Systeme, die quasi nur aus dem BIOS set bestehen und die eigentlichen Spieldaten sind dann z.B. DVD images. Also..ja, du brauchst sie.

Was das Ablegen angeht, geht MAME wieder konsequent seinen Weg:
ROMPfad\SetName\Datei 1 ...Datei N fuer nicht komprimierte Sets
ROMPfad\SetName.zip (oder .7z) fuer komprimierte Sets wo die einzelnen Dateien dann im Archiv stecken.
Rein theoretisch kann man CHD files auch nochmal in ein Zipfile stecken...bringt aber nichts, denn es ist bereits komprimiert. Also fuer CHDs gilt: ROMPfad\SetName\CHD1...CHDn (fuer das jeweilige set).
MAME erlaubt auch, dass man CHD files einfach ohne Unterverzeichnis in einem ROMPfad speichert. Wenn man das nutzen will, muss man das in clrmamepro aber explizit einschalten.

Nun zu den Versionen: Das CHD Format hat auch mittlerweile diverse Versionsupdates bekommen. Da MAME's -listxml output aber keinerlei Informationen darueber ausspuckt welche Version gebraucht wird, muss man das clrmamepro mitteilen (settings->compressor->chdman). Aktuell ist 5. Alte Versionen (.78) verwenden sicherlich eine viel aeltere..vielleicht 3 wie in deinen Screenshots...dann musst du halt innerhalb von clrmamepro das auf 3 umstellen.

Teilweise kann man chds auch umwandeln, allerdings gab es auch mal eine Version in der zusaetzliche Metadaten gespeichert wurden (und vorher nicht). Ein Upgrade ist also nicht immer möglich...ein Downgrade möglicherweise schon.

der rote Anteil entspricht dem Abschnitt der die generelle Anzahl der einzelnen set/file Typen auflistet...
Sprich...es gibt 4720 sets, von denen du 4720 auch "eingeschaltet" hast...die Sets beinhalten 1042 Parent sets...usw..

Unter uns: du brauchst keine Statistiken ;-) Wie gesagt...wenn die ScanResults Baumansicht nichts listet bist du fertig....

1) einem Splitset sieht man erstmal gar nicht an ob es ein Clone- oder ein Parentset ist. Das weiss man eigentlich nur wenn man sich die Dateien anschaut und mit dem Datfile vergleicht. Split Sets sind halt sehr verbreitet, da man dadurch a) jedes Set als Datei vorliegen hat (bei full-merged sets hat man ja nur noch das Parentset in dem alle Clones mit reingepackt werden) und b) trotzdem einen Speicherplatzgewinn hat, da die Clonesets ja nicht nochmal die Dateien verwendet, die mit dem Parentset uebereinstimmen.
"unmerged" verwendet eigentlich niemand....
Die Frage ist im Wesentlichen, was der verwendete Emulator denn unterstützt. Ja es gibt wahrscheinlich Emulatoren, die Parent/Clone Beziehungen gar nicht zulassen und Sets benötigen wo im Setarchiv jede Datei vorhanden ist. MAME ist es eigentlich egal, da der ROM loader alle ROM Pfade durchsucht und sowohl im Parent- als auch im Cloneset nach passenden Datein sucht. MAME sucht sich also alles zusammen...und schau auch nicht auf Dateinamen, sondern schaut nach File Hashes.
Wenn du jetzt irgendeine Retropie Version (oder aehnliches) verwendest...tja...ich weiß es ehrlich gesagt nicht, welches Format die Version dann unterstützt...muss man herausfinden.
Der Trend bei den MAME-maniacs geht halt eh dahin alle Sets zu haben....da stellt sich die Frage nicht ;-)

2) Scanner, das Hauptwerkzeug. Der Scanner untersucht deine Sets, entdeckt ob Dateien fehlen, ob Dateien umbenannt werden müssen, etc etc...Die Baumansicht des Scanner Outputs ist *die* Information die du brauchst um zu sagen, dass deine Sammlung ok ist oder nicht. Kein Eintrag zu sehen, gut, dann gibt es keine Fehler (bezogen auf die gesetzten Scaneinstellungen). Wenn man die Fixoptionen des Scanners aktiviert versucht clrmamepro Fehler auch zu beheben. Bei Dateiumbenennungen ist das kein Problem, bei völlig falschen Dateien natuerlich schon, denn clrmamepro kann ja nicht einfacht auf wundersame Art und Weise Dateien herbeizaubern. Der Scanner gibt dir detaillierte Informationen über den Zustand deiner Sets.
Der Rebuilder ist dagegen dateibasierend. Dem Rebuilder geht es nicht darum eine Aussage über Sets zu machen, schon gar nicht Fehler aufzuspüren oder zu beheben. Dem Rebuilder ist es auch egal, ob Sets komplett sind oder nicht. Er erzeugt keine kompletten Sets (er kann, er muss aber nicht).
Der Rebuilder ist ein Modul welches dir hilft unbekannte, falsch benannte Dateien, sprich eine große Menge Schrott, einfach mal ausmisten zu lassen. Er liest eine Datei (!, nicht Set) aus dem Quellverzeichnis, berechnet CRC32/SHA1 Werte und vergleicht diese dann mit der Datenbank (Datfile). Wir er fündig, werden alle Treffer im Zielverzeichnis erstellt (zu Archiven hinzugefügt). Dort wird der richtige Name verwendet. Sprich, wenn z.B. eine Datei von 300 Sets verwendet werden sollte, werden alle diese 300 Sets erzeugt...aber sie enthalten dann erstmal auch nur diese eine Datei.
Der Rebuilder wird auch gerne verwendet um bestehende Sammlungen zu durchsuchen und Dateien fuer einen anderen Emulator zu erzeugen. Sprich man lädt ein Datfile für Emulator X, hat aber Sets für Emulator Y, dann lässt man einfach mal den Rebuilder über diese Sets laufen und schaut, welche Dateien aus der Y Sammlung zu X passen.
Hauptsächlich ist der Rebuilder praktisch um neue Dateien seiner Sammlung hinzuzufügen. Der Scanner kann das über fix-missing, aber hier ist der Rebuilder im Vorteil (schneller, andere Voraussetzungen, einfach Drag'n Drop in den Scanner).

Ein übliches MAME update ist in etwa so:

1) man hat eine vollständige MAME Sammlung und nun kommt eine neue MAME Version raus. Sollte man ein MAME Profil basierend auf der MAME.EXE Datei haben, erkennt clrmamepro automatisch, dass ein Update vorhanden ist und importiert die neuen Daten
2) Als ersten sollte man den Scanner laufen lassen, da dieser alle möglichen Fehler behebt. Danach sollte man eigentlich nur noch fehlende Dateien haben (nämlich die, die durch das MAME update hinzugekommen sind), ggf. sind auch noch Dateien vorhanden, die durch die neue Version komplett ersetzt werden (z.B. redumps)
3) Hat man die neuen Dateien gefunden, kann man jetzt den Rebuilder verwenden um sie hinzuzufügen (dabei zeigt Rebuilder Destination auf den Rompath). Man kann die Dateien einfach via Drag'n Drop in den Scanner schmeißen...und den Scanner auch so einstellen, dass er nach dem Rebuild automatisch neu scannt.
4) man wiederholt 3 bis man keine fehlenden Dateien mehr angezeigt bekommt.

Pages: [1] 2 3 4 5 6 ... 127

Page created in 0.093 seconds with 20 queries.