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 ... 14 15 16 17 18 [19] 20 21 22 23 24 ... 165
361
Well...of course it's possible to write a converter for such files....but of course you need some additional information like a set name and optionally crc32, size information. Cmpro does not convert such files and won't do this in the future.

362
clrmame Discussion / Re: Running from NAS
« on: 28 April 2021, 16:20 »
What did you expect? ;-)
Of course using a network drive is slow. It always been and always will be...compared to a local ssd.
A full scan on a decent system on a SSD is less than ~ 1minute.
Besides of the general time drop due to lots of file access tasks over the net, you might run into problems with SAMBA which were discussed several times on this board in the past. There were buggy drivers which caused all kind of issues...mainly simply dropping files and stop operations.

So what should you do?
If data import is already slow, you should check your setup (since this is just a redirect of MAME's -listxml output). You should keep cmpro close to the drive where your files are....and avoid SAMBA.

363
The built-in dat creator works on file basis, not http links. But of course there might be other datfile generators out there....
however, a datfile should contain a hash, i.e. you somehow need to read the full file to calculate sha1/crc32s

364
Hmm...I don't really understand your request fully....

Normally you use Profiler->dir2dat to create a datfile from a selected folder from your storage media....it runs through the folders, calculates the hashes, sizes etc and forms a datfile from it.

What is your source? I mean what exactly do you mean with "from only dirs/size files"?

365
clrmame Discussion / Re: Scanner does not check crc32?
« on: 08 April 2021, 13:02 »
No everything is fine and of course the crc32 is checked.
But such old MAME versions used bitwise inverted crc32 values to mark a bad dump in the datfile.
So your file is actually ok (but  a marked bad dump):

4fafa1e7 = BOOLEAN-NOT b0505e18

There's an option in the profiler options to enable the inverted crc32 mode, then the rebuilder also rebuilds it.


Yeah...there are some weird things in 20 year old MAME versions....that's one of the reason why people should stick with the current one :)

366
clrmame Discussion / Re: Unpack failed on file
« on: 07 April 2021, 16:19 »
That zip is packed with the deflate64 compression method which is not supported. You can unpack it with e.g. 7z/winrar and pack it again as a zip and it will work.

367
There is only the following in MAME .230: videopac.xml <softwarelist name="videopac" description="Philips Videopac / Odyssey 2 cartridges">

Maybe MAMEDevs used a different file before with a different description and you only unpacked the latest MAME over your existing installation (no clean install).

369
clrmame Discussion / Re: Split vs Merge
« on: 24 March 2021, 17:47 »
I had a quick look, simple fix.
However, it should also affect the rebuilder batch (merge) options and (being picky) a possible forcepacking should also influence batcher's rebuild pack options....

Guess I find some minutes this week to add this

370
clrmame Discussion / Re: Split vs Merge
« on: 24 March 2021, 14:14 »
Well, I actually guess that a datfile forcemerging tag should be something with a higher prio in any case...
Such things are so rare and are put in the dat to really force the collection to be split/full/unmerged...so I think any batcher overwrite should still accept the forcemerging information from the dats.

Have to check if it's actually stored in the profile. Normally, the profiler reads the dat and sets the merge mode accordingly and doesn't allow changes...have to check if it also stores if the datfile actually has got a forcemerging tag..


I will check it.....

371
clrmame Discussion / Re: Split vs Merge
« on: 24 March 2021, 11:24 »
Well....The batcher options for scanner are either "per profile merge options" (so it doesn't change anything and keeps it from the profile) or you select an mode which overwrites the one from the profile

So yes, forcemerging tags are ignored since you do force an overwrite of the batcher scanner merge mode settings.

So...from this point of view it is expected :)

372
clrmame Discussion / Re: Continued from MAMEWorld...
« on: 19 March 2021, 06:08 »
That 32/64 bit thing is interesting.....actually in the 64bit version you got a version64.ini file with the needed url for update and for the 32bit version you got a version.ini with the same content (the split has some historical background).
Would be interestining to know which files you had before the update worked (which exe, which version file). (Backup?) Maybe a mixed setup is the cause of all trouble.

Autorefresh www dats...hmm..shouldn't play a role at all...but I will check it, too.

Thanks for testing!

373
clrmame Discussion / Re: Continued from MAMEWorld...
« on: 18 March 2021, 15:02 »
can you test the following if you got the update problem:
download https://mamedev.emulab.it/clrmamepro/binaries/cmpro_updatetest.7z and unpack one of the exe over yours.

Then run it, go to about and "check now". This version is hardcoded to "1.0", so it should detect the latest update and should start the update process (if you accept it). Then the download of the package starts and your versions (this test version) gets replaced.

So what is different? Well, I've moved the code which downloads the version information from update.dll to the cmpro main program and now it uses the same routines which e.g. the www profiler uses to download www datfiles.

The update process (the actual download of the package + unpack and restart) hasn't changed yet and is still handled by update.dll....however this test can give me an idea already if the general version lookup still fails for you or not.

374
clrmame Discussion / Re: Continued from MAMEWorld...
« on: 18 March 2021, 06:37 »
no prob, as I said...I really like to look at it again...because normally sending a GET request under Windows in C++ isn't magic....

377
clrmame Discussion / Re: Continued from MAMEWorld...
« on: 17 March 2021, 07:07 »
Sorry but your assumption is wrong.

The Homepage and Donate buttons simply run your standard browser with an url. (something like: ShellExecute(m_hWnd, _T("open"), donateUrl, NULL, NULL, SW_SHOWNORMAL); )


The update button calls routines in update.dll which
a) download the file from the url given in version64.ini
b) compares the version against the current one and if it's newer it downloads the package etc..etc
for a) it opens an HttpConnection, sends a GET request with a imo fine filled http request header, queries the length of the target file and downloads it.
for b) it opens the downloaded version file and compares it, then it would download the full package (pretty much the same as a) but a different file) etc..

So what people reported is that a) fails for them already because the GET request is simply dropped by the server.

You can check this by monitoring the cmpro folder if a "version" file appears (it gets removed after clicking the prompts)

But as mentioned, I've tried this on various systems, various networks and even in various countries...and it always worked for me...so really hard to say where exactly the problem is.
When I find a bit more time I will look at it again.

378
Well, actually the combined mode is crap. Period :) I got a couple of ideas on paper which actually match somehow your ideas a bit....but currently no real time to implement it.....but time will tell....Thanks for the feedback!

379
1) I can't repeat the "An error occured while reading information from: G\Mameui64\MAMEUI64.exe" at all. This error only appears when cmpro can't access the redirected -listxml or -listsoftware output file or the file itself holds xml bugs. As I said...I cannot repeat this behaviour at all...sorry.

2) Using the same executable for 2 profiles (-listxml and -listxml + -listsoftware) is not intended and will create problems. cmpro reads the xml files and stores the data in a cache file (based on the exe checksum). So you will have one and the same file for both, or if you created one with software lists and load your profile without you get in trouble. Cmpro checks if the exe changed (hash), if yes it shows you a prompt and will reimport data, if not, it loads the cached information.
Either you need 2 not binary-identical exes or use a dat for one and exe import for the other. Or you need to clean the cache all the time before loading a profile...The better way for software lists is anyway to keep them in separate profiles (simply drag'n drop MAME's hash folder in the profiler).

3) auto assign sysdefpaths. Let me tell you how it works. First you need to add rompaths. Rompaths can't have subfolders with other files. You cannot add the root of all your software lists. You need to have them separated. You can simply drop all your folders in the settings folder of course. So settings -> rompaths should show a list of paths....and not one. Then you go to systems and hit auto assign. The auto assign works as follows: Runs through all rompaths (not subpaths!), tries to match the setname against the databasis...each match increases a counter (per bios/softwarelist) and after scanning all rompaths cmpro checks which rompath scored best for bios/softwarelists XY (highest count). So for Atari2600 your 6 rompaths score 0, 1, 1, 10, 200, 7, the rompath with the 200 is assigned ...and so on.

4) nothing of the above actually has changed in years. Regarding the fix for the autodetection, that feature broke a version before so it was just a quick fix to get it up working again.

Setting up softwarelists paths in a combined profile is really a pain...yes...that's why I advice people to not use it (I actually already though of removing it). Using separate profiles is in my opinion the better way to go through it (especially with the batcher)


Regarding 2, I can think of a way that cmpro is able to support 2 different cache files though....one with and one without software lists


(actually I'm working on modifying the hash so that a) the name of the datfile/mame exe, b) the binary content and c) combined or single mode is reflected by it...so you would be able to have differnt cache files for identical mame binaries in combined/not combined mode and/or different caching files for byte-identical files in different positions)....)

380
nah...it's not.... ;-)

a set = collection of roms and/or chds and/or samples

doesn't really matter if a set consist of one rom (like a console cart dump) or 10 roms, samples and chds ;)

Pages: 1 ... 14 15 16 17 18 [19] 20 21 22 23 24 ... 165

Page created in 0.193 seconds with 17 queries.