Indeed all files that crash the program have a SNPID set to "000". After correcting those with an unused SNPID, I eventually got the report that displays the correct SNPID and just have to set it to these values. Now everything is fine.
It's been a long time since I wanted to clean out the mess in my kontakt libraries! Great tools and huge thanks for the support!
Cheers!

 

Hi Fred, I got the issue sorted, even on the M1. Bear in mind all of my Libraries show up and work fine in Kontakt, and the only reason I was running this was to get a list of my SNPIDs. When I removed my oldest xmls from Service Center, the software ran as expected and created the list. I added them back in batches and discovered I had a duplicate of 1 library with a different name and ID. Kontakt didn't mind, but SNPIDer 4.0.1 crashed. Of course, it would have been nicer if SNPIDer identified something like this for me, but hey, what do I expect for free?!
I saved the file in case you'd like to be able to replicate the issue.

Thanks for your work! It's still a useful tool to allow us to get a nice list... For example, I see that some of the nicnts indeed have 4 digit IDs that are truncated in the xml. And I previously was pretty haphazard about choosing my ID numbers. Having a list will make it much easier to prevent issues down the line.
I'll also say that even though Kontakted is way overpriced, it's also a been a very useful tool that has allowed me to effortlessly add new libraries.

 

Last edited: Apr 10, 2021

Glad it works for you

 

Well I'm happy it worked out for you in the end, and on M1 too ! I'm keeping a copy of your post to add to my "things to look at" list , and yes, the file would be handy for debugging, if you'd care to send it to me. TIA.
You can even have 5 character SNPID's like aB123 !
I bought Kontakted 4 myself about 4 months before 5 came out and was a paid upgrade which was fundamentally just a bug fix for the latest systems. A total rip-off . I"m just making my own version a little more presentable (again, I made it for my own needs initially), before giving it away here. It won't be too long now

 

Yeah, no argument there. If you're gonna overcharge for a basic app like that, it at least should have free bug fixes! I was in the same boat, though to his credit, I wrote the author and he immediately gave me the upgrade for free.

Anyway, I think what was crashing your app was that the duplicate xml had a SNPID of "000", so maybe that's an easy fix? Thanks again for making this useful tool, and making it free on top of that!

 

Last edited: Apr 11, 2021

Sadly I get an error message on opening the app...and I'm on latest Catalina. It looks like a great tool but not sure how I can overcome it being unable to be opened.

 

An "error" message?
Or just that it says it's from an unknown manufacturer, because it can't be opened due to your security settings that you haven't changed?

 

This is not a SNPIDer bug ! It is a known OSX bug due to the extended attributes (xattr) getting corrupted. The usual solution is to fix it through the terminal. It only takes a minute (or less !) and the command you want is :
xattr -cr /Applications/AppName.app
… where "/Applications/AppName.app" is the path to SNPIDer. That should fix it for you. I like to just type (or paste) "xattr -cr ", yes there's a space at the end, and then just drop the application concerned in the terminal window, which automatically adds the correct path. Type "Enter" or "Return"… done !
There ar plenty of posts videos around for this. Google is your friend

 

Thanks.
Got it working - but sadly the app crashes and automatically shuts down when it's in the middle of the process. Nothing I can seem to do about that....

 

I had the same issue. It was caused by a duplicate xml I had with an SNPID of "000". I found it by methodically removing half of the xmls from the /Library/Application Support/Native Instruments/Service Center folder, running the app, and then again until it ran to completion. I pretty quickly narrowed it down to just 1. Once I removed the culprit, it worked fine. Of course you may have more than 1, but the basic idea is the same...

 

Bloody hell... Seems like an enormous manual pain in the ass to do this - is this app even worth all that bother?!

 

It's really not that big a deal, but for me it was more of an academic exercise than anything. If it's not worth it to you, then don't.

 

Hi.
As InTheChips says, it's almost certainly a corrupt xml. Duplicates would not crash the app, unless the duplicate is also corrupt ! If I'm wrong on that, I'd need an example !! I ran tests myself with duplicate xmls deliberately duplicated and was unable to make it crash. Corrupt ones however will, and do crash it. It would eventually be possible to write in checks to parse each xml for validity first, but this would be a lengthy process and would surely have to be made as a separate task rather than doing it systematically with each generation of the list.
In any case FastFox, if you don't see a use for the software, throw it in the bin and ask for your money back !

 

Me again I I'll mitigate my last post a little as the idea of checking for corrupt XMLs intrigued me a little, and a bit of research has turned up a low level system routine that does just that ! I've messed about with it a bit on my XMLs (360 odd) and I deliberately corrupted a few. It turns out that, as a "low level" routine it is actually pretty fast, so I'll probably incorporate this in an update ! I'm thinking that the best way to treat these problem files would be just to skip them when creating the listings, but add the information at the end of the reports. I'll see…
Despite FastFox's rather condescending "is this app even worth all that bother?!", some people do find it useful

 

Version 4.1.0 Posted.
See first post

 

FYI Fred, using the latest version 4.1.0 on Big Sur 11.2:

- it was crashing without any prompts or error, simply the program would just disappear towards the end of the second progress bar. Luckily due to some of the previous posts on here, I did the binary elimination method, moving xmls in and out of the Service Centre to find the culprit, which was indeed an xml with 000. Not sure if it was also corrupt or something, but basically, it seems as though the functionality you said you've included so that SNPIDer doesn't crash when encountering 000 doesn't seem to be working. At least, not on my OS.

- Another failure point I encountered, even when the above 000 problem xml was eliminated, most of the time when I run the optional extra check to see that all instruments are matching their corresponding xml, it also crashes without a word. I only got that check to work twice with no differences in operation on my end. In fact, I'm pretty sure one time I ran it successfully immediately after a failed attempt without changing anything. I didn't even move an xml at all. So it seems that feature is a little shaky for some unknown reason.

But the tool was still useful in the end and I'm really grateful for all your altruistic work on this and for supplying it to all of us. I'm not supplying this feedback out of annoyance, but rather to help you troubleshoot/improve this little app.

Thanks for your work!

 

Thanks for the feedback. It's always appreciated. What would be even more helpful would be the XML that you isolated, if you still have it. It's not the fact that it's a "000" that crashed the software. IT HAS TO BE something else, but without the file, it's impossible to check. I too am on Big Sur 11.2.3 and for testing purposes, I deliberately corrupted 5 XML files in different ways and all of them were picked up by the software without crashing. This included SNPIDs of "000". So I really can't say without having a file shown to be crashing the software. Someone sent me one way back, which I kept, and which does not crash my system anymore as it did before.
People who find corrupt XMLs, please send them to me

 

i only use windows but from what i can see on the xml template,
RAS2 is obsolete, you should use RAS3 instead, as NativeAccess.xml does.
if not it will never match with the service center check.
some old libraries created for kontakt 5 also need a nicnt update to work in 6, all the updated data are in NativeAccess.xml

RAS2 use kontakt 5 scheme (HKCU content location+serial in windows)
RAS3 is for kontakt 6 (KHLM content location+SHA crypted jwt files)

the best thing to do is rename NativeAccess.xml in ProductsHint.xml to add the last addons to K5n as the old discontinued service center should do online. open native access over will generate a new one, you even don't need a backup.
if not K5 will never see the new products.(like world percussion creator)

it is more than only the SNPID to modify. it need to update the security mode to match with kontakt 6 scheme.

you'll be able to load RAS3 products from K5 if you update ProductsHint.xml
the bug should come from this part because you add libraries from K5 using an old ProductsHint.xml list still in RAS2 not matching with NativeAccess.xml RAS3. both files should be the same references, one used by K5(ProductsHint.xml), one used by K6(NativeAccess.xml).

 

Mmmmmm… interesting and precious information here bobdule. Thanks a lot. I'll look into all that…