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 ... 4 5 6 7 8 [9] 10 11 12 13 14 ... 158
161
clrmame Discussion / Re: lossing existed Roms during "new scan"
« on: 09 December 2021, 07:22 »
ok, let's take that the set "aceoface" with the one and only rom "aceofaeu.bin"....

where was it placed before? (O:\Games\Emulator\Mame\Software\a7800\ ?)
Was it compressed/archived (.zip/.7z/.rar) or decompressed?

You can limit the scan to that only set (set information dialog, uncheck all, only enable that one), so it would be interesting to know what the scan message shows....if it was removed there should be some fix unneeded prompt...I need the detailed information on that.

You're saying "amout of missing roms seems random"...which is actually a bit scary since it more sounds like a totally different issue (3rd party programs interfearing like virusscanners locking/blocking files or network connections failing (see SAMBA posts here on the forum)...so...can you give some detailed information about your setup. Is  O: a network share?

162
clrmame Discussion / Re: lossing existed Roms during "new scan"
« on: 08 December 2021, 09:37 »
Only had time for a quick view on it yet...

The fix unneeded screenshot looks good to me since it mentions a cpc_flop softwarelist set ("ace of aces (uk) (1985) [original] (weak sectors).dsk" ) which does not belong to a a7800 assigned rompath (I can imagine that the a7800 corresponds to the Atari 7800 software list).

In your "after" list I can see lots of "move to rompath" messages which all belong to pippin SL sets...Again, the message is correct since it seems that you've placed the pipping chds with their subfolders in a rompath which was assigned for standard MAME ones, not Software lists. Since the rebuilder does not move/create chds, they must have been moved there on a different way...maybe manually....

The other files now listed as missing in "after", well, you said you only did a rebuild in between....maybe such files were part of the dropped/source/addpath? Please double check the settings. If a new scan removed them, you'd be prompted, so please read carefully what the prompt says.


So, please double check your folders (a7800 folders shouldn't contain cpc sets) and try to minimize the problem to 1 set where you can say: It was correctly stored before the scan and it was removed completely afterwards. By the way...do you scan a network drive or anything else which may be special to your setup?

For example, focus on "11 A Side Soccer (UK) [softwarelist: cpc_cass - folder: 11assoc - size: 55kb]" (1st entry in "after" after the pippin messages) which was not listed in "before" but as missing in "after". Try to repeat that behaviour that "it disappears". Either the rebuild did something to it (but that can only mean that you used it as rebuilder source + remove rebuilt...but then it should exists in the destination) or the scanner, but then you should see a prompt.

163
clrmame Discussion / Re: lossing existed Roms during "new scan"
« on: 07 December 2021, 12:10 »
Well, can you give a single example about the "unneeded" messages? Or one of the thousands of missing roms messages?
I highly doubt that something gets lost since all unneeded files are put into the backupfolder...so please give an example here, too.

Your setup (split of chds and sets in different folders) won't work in SL combined mode unless you really only have Cubo BIOS sets and TaitoGNet files in the chds folder (since that's what you've setup in your config). For the combined mode, you need one unique path for the given bios/standard/device...so e.g. for Area51, you need area51.zip in the 'standard' assigned path and also a subfolder in there named area51 which contains the chd.
Keep in mind, chds need subfolders named after the set, that also happens for software lists.


So....I need more information about your setup....some examples which files are placed where and why message is shown......first impression is that the split of chds/roms into different folders is simply not what you can use in the combined SL mode....
If you want to keep it, you should switch to 1-profiler-per-sl mode.

164
clrmame Discussion / Re: [SOLVED] Separate paths CHD VS nonCHD?
« on: 05 December 2021, 12:06 »
If you keep CHDs in one rompath, no problem. But they will follow the general set merge setting.

So if you have full merged sets, you need a subfolder for each parent set in there and the folder holds the parent and the clone chds. If you have split merged sets, you need a subfolder for each parent and clone set and the chds are put in their belonging subfolders. If you have not merged sets, you do the same as for split, but there might be cases where you need to double chds.

As I said...as long as you don't use system default paths or the combined SL mode, it's simply another rompath which simply holds chds (in their set-subfolder). You can keep the belonging roms (if there are any) in a different rompath, zipped/7zipped or even decompressed.

165
So maybe we start with merging. Either all or none.
And I think if you're talking about non merged you most likely speak of split merged....since unmerged is really really a waste of hd space and actually it's not what you might think of.

not merged or unmerged: each set got all the files it needs in it (folder or archive 7z/zip/rar). So clone sets contain the parents again in them.....a waste of bytes.....but actually that's not the full truth since sets usually also require bios roms and since some time ago also device roms....so if you really want to talk about fully stand alone not merged sets, you'd need to double/triple/etc such files and put them in the archives, too....as you can see....there is no real need to even talk about not merged/unmerged sets.

split merged: the most common storing method since you a) have a set for each set, so you have a better look on it and b) there are no (or nearly no) dupe files since the clone sets only contain the files which are unique for them. "or nearly no" because we don't support clone of clones...so there are cases where clone sets would be a able to share files, too but they don't because the parent doesn't use it

full merged: also pretty common....but not my personal favourite....only parent sets exists and they hold each clone in it, too.

When we talk about chds, it's the same....chds are simply a part of a set. A set is a collection of roms and/or samples and/or chds and they are always stored: rompath\setname\file 1... file n for decompressed sets or rompath\setname.zip (.rar/.7z) for compressed ones. Now in theory it would mean that you put the chd in the zip file too, but since they are already compressed containers, so it doesn't make much sense...that's why you put them in a folder named after the setname. Keep in mind, the chd filename doesn't need to match the setname.
For full merged sets it would mean that you have a rompath subfolder named after the parent set which holds all chds for the parent and its clones....and you got a zipfile somewhere in a rompath with all rom files.

You can keep a folder for chds as you mentioned in your last post but that won't fit with the softwarelist combined mode. In a normal clrmamepro profile, you can of course keep as many rompaths as you like and spread the sets over them as you like.

Finally, in "normal" clrmamepro mode, you can also use system default paths which allows you to split your collection by bios...but again...then you need 1 assigned rompath per BIOS...So for example SegaSP sets would have a rompath with folders for the chds and the zip archives for the roms.....


It's basically up to you...what you prefer.....as soon as a combined SL mode or sýstem default paths are used, you will be limited though.


166
The easiest is to keep separte profiles. One for MAME without software lists and one for each software list.

If you really want to use the combined mode, you can a) limit the number of software lists on import. After that you will have the ones you've chosen plus the ones for MAME (which are Standard, Mechanical, devices and lots of BIOS ones). All software lists paths need to be distinct and unique, the other ones don't have to be unique. Assign your setup rompaths correctly to them and you can scan.

Your problem is that you try to separate chds in a standalone path. Why? A set (let's take area51 for example) consists of a rom set and a chd which is also part of it....so splitting up chds in a different folder that the belonging roms is not really a good thing.
And you can't assign the paths in that scenario if you split them up that way. Since as I said...let's take area51 for example which belongs to "Standard" needs to be assigned to 1 rompath.... and you got 2...your roms and chdspath.

so I guess...you should switch to the separated profiles options. Simply drop MAME's hash folder entries to the profiler for the softwarelists you like to use.

167
very interesting, thanks

168
clrmame Discussion / cmpro 4.044 released
« on: 29 November 2021, 15:40 »
4.044

fixed: file can get lost under some rare rename/set conditions (MAME238 diablo68 u2)
misc: update 7Zip SDK/DLL to 21.06, update unrar SDK/DLL to 6.10.2
misc: compiled with Visual Studio 2022 / Win 11

169
Check access writes maybe :) Sounds too easy but actually I don't have an idea what else should have caused this. Would be interesting if you play a bit with a minimal setup, e.g. a 1-set-1-rom datfile which you create on your own, put the file on your share and do some testing with renames/write access.


170
well....all I can say is that people had very weird issues when using Samba...most of the times it was related to typical dir-tree-walks...where it simply stopped or better..it simply completed (but didn't run through all files and folders). Some users were able to resolve the problem by updating drivers...
Nothing I can really help since cmpro simply calls win32 api functions....

171
Batcher (select more than one profile and hit load) -> Misc -> Create rompath for new dat (specify root folder)

172
hmm....but cmpro always writes its selected paths with a \ at the end.....so I wonder how you get paths without it (unless manually editing *.cmp files which is not recommended :) ).

173
Hmm...good it's resolved but still spooky. The filesystem shouldn't play a role since but if you're saying you got it "on a server" that could be the root cause, especially if e.g. SAMBA is involved somewhere. There are known weird issues connected to SAMBA (e.g. simply finished rebuild operations after e.g. 30%, etc.), which usually are connected to bad drivers or unstable connections. If you search this forum for samba, you'll find some weird things ;-)

but maybe it was just some weird bad old caching thing......keep an eye on it ;-)

174
"In my case, the rebuilder undesirably creates software-listed roms in $mameroot\software instead of $mameroot\software\$mycustomed_system_path"

It sounds like you have $mameroot\software as a rompath which is wrong if you also have subfolders in there for the single softwarelists.
Rompaths can't contain rompaths. Please check your setup again.
If you like I can have a look at your setup if you send me your *.cmp file for your used profile (cmpro settings folder) plus cmpro.ini.

175
Well, sounds like a bad setup.

The combined mode needs unique distinct rompaths per software list. Auto assign only really works if you already have paths with some sets of the belonging software lists since it's an easy best match count wins algorithm, i.e. if a folder holds 10 Atari 2600 sets and only 8 C64 sets, the path is assigned to the A2600 software lists. If no match is found, the 1st rompath is used.

24 hours sounds long. I assume you have recompress enabled which is not really needed or you're using compressed files which don't support that (e.g. solid 7z archives).

If you haven't touched your original rom collection, why should it be screwed. Sounds more like either accidently scanned it with a wrong datfile or used it as source for rebuilding and got remove-rebuilt enabled. And in either way, roms can't be lost, the scanner puts them in the backup folder and when you did a rebuild, you got them in the destination (unless you really ticked some weird options like disabling backup and remove-only in rebuilder).
If cmpro says that your path settings are invalid, then something is wrong, so you should recheck and give detailed information how you stored them and what cmpro complains about. Manually editing the cmp file is not a good idea. Better give a detailed example. Keep in mind that you can't have rompaths in rompaths and the general storing method is rompath\setname\file 1...file n or rompath\setname.zip (.rar/.7z).


For you, I recommended to use one profile per software list. Easier to setup, easier to maintain and in combination with the batcher you can run through all profiles at once.



176
erm...no, this should not happen and actually I can't repeat it here.

Can you send me: your cmpro/settings/*.cmp file which belongs to your profile, I assume you're not using a dat but a direct MAME.exe import (if not, send me the dat, too) and cmpro.ini

177
well....as long as the used datfile holds all in one set defintion (so you got a trillion isos in just 1 set), you won't succeed in testing.
You need to either:
- buy a bigger hd :)

- or split up the datfile...which is pretty easy. Load the datfile in a texteditor and decide where you want to split it. Generate a second set instance which holds the files from your 2nd hd), save this datfile and load it in the profiler.

This solution of course has a downside....since you need to know which parts are on the first and which are on the second disk...

...or you change the dat completely to 1 iso per set...then you don't need to care which file is on which disk, but you have to follow the storing methology which is always:
rompath\setname\file 1...file n for decompressed sets
rompath\setname.zip (.rar/.7z) for compressed sets where the archive holds file 1 ... file n

always keep in mind, usually a set contains more files, like a pacman arcade dump which is a collection of various IC rom dumps (sound, grafics, code,...:)

So in the last case you'd need to store isos separately in subfolders....

178
let's discuss terminology. For me one set corresponds to 1 game

A set is a collection of roms and/or samples and/or chds....so e.g. pacman (which only has roms)

Now there are collections out there where the datfile is structured to keep all games in one set....for example a NES collection which may have some thousand single nes files in one set "NES collection".

You've mentioned 6.26 TB as set size...so I think it's more one of the latter ones?

If so, you can modify the datfile used for scanning and simply break it into 2 sets....one holding files with for example 0-9-H and the other J-Z or something

179
Well, generally multiple rompaths aren't a problem since you can setup as much rompaths as you want (Settings->Rompaths).
If you now say that one set is split up on two drives....I actually wonder why :)

If you want to fix it, a rebuild to a new destination would be good thing to do where the source are your 2 folders (either drag'n drop or multiple rebuild runs or setup the 2 paths as addpaths)

If you want to keep one set split on two drives (I still don't see any usecase for that), you will run into issues during scanning since cmpro will complain that it found a set multiple times.

180
clrmame Discussion / Re: Bad URL...
« on: 20 October 2021, 07:51 »
Thanks....and yes...I should write one ;)

Pages: 1 ... 4 5 6 7 8 [9] 10 11 12 13 14 ... 158

Page created in 0.642 seconds with 21 queries.

anything