I just want to post something very special and positive (to me): Regarding this thread Uniti core - #55 by Jens2021 my own problems with the automatic refreshing process of the Uniti Core’s database using the Downloads folder are solved after nearly 2 years of investigations. Summary of the problems is: The Core stoped refreshing it’s music database immediately after I altered the albums in the Downloads folder. And it even stops ripping CDs. I could use the UPnP server to play music which was already there but new music didn’t show up. Only solution so far was the rebuild the complete music database which took nearly 2 hours for my approx. 50.000 tracks on a 2TB HDD.
Well, today I checked the metadata for all my tracks with the automatic scan logging function of the Minim Server (free UPnP server software). This founds some technical problems in approx. 50 files (MP3 and Apple Lossless). E. G. wrong date entries like ‘0’.
I fixed this with a metadata editor and after cold restarting my Core the refreshing process now works like expected for the first time: A few seconds after altering the contents of the Core’s Downloads folder from my Mac computer these new or altered content shows up in the app.
I didn’t managed this from April 2021 until today, even Naim’s support had no solution. What’s the message now for me? The Core’s firmware has no robust metadata error handling or it is even non existent. It simply crashes reading some technically corrupt metadata. This makes sens to me because the ripping process -the primary function of the Core- uses error free metadata (seen from a technical view point) from an external source and therefore there is no need for extensive error handling within the firmware for content of the Downloads folder.
May everyone with similar problems find this solution here…
That’s very interesting and it’s not something I had heard before. Thank you for posting.
@Stevesky your dev team might be interested in this piece of problem-solving which maybe exposes an issue that was not understood before.
thanks for the reply.
I can provide my initial problem documentation e.g. with screenshots of the freaking out ripping function within the app which I had send to Naim in 2021 if you like to.
My case is to some extend an extreme one with this huge amount of tracks but I guess these metadata handling problems could occur with even a handful of tracks if there are one or more technically corrupt files.
In addition I had two tracks out of 50.000 which aren’t even playable (even not on a Mac or PC) because the file itself was faulty. But even in this extreme case the Core’s firmware should work furthermore.
But besides this I love the Core for it’s concept, great sound and tank like build quality. Great stuff.
Thanks for the very useful report - much appreciated.
By any chance, do you have a copy of the problematic files before they were fixed? I was discussing with the dev team and it will be very useful to have a copy of the bad files to ensure we can be 100% sure we have resolved this corner case crash.
@davidhendon - thanks for flagging this one up. I don’t have time to read all threads, so a little nudge of ones of interest can come in handy
thanks for asking me.
Yes, I do have copies of the corrupt files within a backup. This is not inhouse at the moment (geo-redundant backup) and will took me a few days to grab. Then I will let the Minim Server do his work again and grab the resulting logfile with its error messages too.
I will then pack all the files up on a shared cloud drive. Do you have an email address to send the download link or can I send you personal message here in the community?
Email me direct with the link:
Download link for corrupt emailed to Steve Harris.