That image is priceless 
Let me know when you have time if that’s been fixed.
Yes, Maestro on my Apple Silicon Mac takes considerably longer to load my 7TB music library (over 5,000 albums in AIFF and DSD formats) compared with Roon, JPLAY, or Audirvana. However, with the latest versions, it does eventually complete the process—it just requires a bit of patience.
In my case, I installed a free Mac app called Amphetamine, which prevents the computer from going to sleep. This gives Maestro enough time to finish loading the library without being interrupted.
Since all of my music files are already properly tagged and contain embedded album artwork, I wonder whether Maestro could provide an option to skip metadata and album artwork processing and simply use the existing embedded tags. This could potentially reduce the library loading time and may also avoid some of the metadata-related issues I have experienced with DSD files.
I hope this information is helpful.
Still really slow to load if I click Local Files - Artists. It took 60 seconds. When I clicked on an Album, it took another 60 seconds to appear then at least another 60 seconds to actually allow me to play the album. 186 Windows. These problems only occur with Local files and a fairly large library. It’s fast with Qobuz
Mitchell — this is genuinely helpful, and you’ve put your finger on the right fix. You’re correct that Maestro is doing metadata and artwork processing that a well-tagged library like yours doesn’t need, and that’s the main reason cold loading is slower than it should be. A “trust embedded tags — skip enrichment” fast-scan mode is exactly the direction, and it’s going on the near-term list. Two more things: the fact that you need Amphetamine at all is a bug on our side — Maestro should keep your Mac awake during a long scan by itself, and we’ll make it do that. And the DSD metadata issues you’ve hit are already fixed in the update building right now. Thank you — this is the kind of report that actually moves the product.
This would be most welcome! I spend a lot of time making sure my tags and artwork are quite good.
Finally, all 5,282 albums are now appearing on the Album Wall, and I can browse the library very smoothly. Scrolling up and down is fast and responsive once the library has finished loading.
However, there is still one issue. If I close the software, or even navigate to another page (for example, Settings) and then return to the Album Wall, it takes quite a long time for the albums to reload completely. This behavior does not occur in other music players such as Roon or Audirvana, where the album view remains available almost instantly.
Another suggestion is to add a vertical scroll bar to the Album Wall. At the moment, scrolling with only the mouse or trackpad can be slow when navigating a large library, and a scroll bar would make it much easier to move quickly through thousands of albums. – my mistake it actually there, but it is not visible clear due to the color.
The link below demonstrates how fast and smooth the Album Wall becomes once the software has finished loading all of the albums. It shows that the browsing performance itself is excellent—the main issue is the time required to reload the Album Wall after leaving the page or restarting the application.
Or starting to type the name/title could move the cursor to the first item in the list with those letters. Like in Windows File Explorer. Much faster and easier.
In the works and this is the way JRiver does it and we’re going to employ their strategy. We’re currently doing it the way Roon does which is slow (read the Roon forums and you’ll see lots of complaints about slow cold builds), but JRiver, on the other hand, is quite fast.
Their benchmark is 100K libraries in 14 minutes so that’s what we’re shooting for. The artwork and metadata builds in the background over time so that upon loading a fresh library you get to see and play the files right away and don’t have to wait for the rich metadata we all expect these days (something JRiver doesn’t have but Roon and Maestro do).
We want it all!
187 just shipped. Can you give it a try and see?
V187 just shipped. Can you give that a try and see if we made any headway?
Hey Paul, V187 is still only generating 1 track playlists on my system when using Ella. Is this still an ongoing issue on Mac silicone?
Thanks, Mike. Sigh, what a mole city! We’ll launch V190 tomorrow morning with the fix and a snappier library scanning mode.
I went to try the new version this morning but only got the Maestro homepage with the free trial offer and no way to log in. I have been using Maestro since May and have already paid 2 months subscription. However, I deleted Maestro, rebooted my silicon Mac and downloaded the new version of Maestro. I was able to get into the app and needed to reload my local library which it did with no issues. So back up and running again, but I thought I should let you know of the initial log in issue.
I have every faith that you’ll get there Paul. It will be worth it in the end!
Hi Paul,
I am evaluating alternatives to Roon to see if I can get improved SQ elsewhere. I’ve installed Maestro, set up my Airlens as an end-point, scanned my local library and upon going to the Home screen, I am presented with a list of album covers - one of which I recognised, so I clicked on it and nothing happened. The home page is showing me what must be available on streaming services? This confused me because I have not configured any streaming services in Maestro.
I’m not sure if presenting the user with albums they can’t play is a good experience.
Anyway - I added a single track from my local library to the Queue and it started playing [Aside: Probably should not play immediately, rather wait until the user presses play - per Roon and Audirvāna] and about 1/2 way through it just stopped. I go straight to the Windows Event Viewer in such cases and could see a bunch of errors reporting the crash.
This is the first.
This is the last:
The .xml file referenced in the event has this information
I hope this helps some 
I will reboot my PC and try again.
Regards
Mark
Mark,
This is a first-rate report — straight to Event Viewer, WER XML included — and I can already read a good deal from it. Thank you.
What your data tells me: exception 0xc000001d at the identical fault offset in both events means Maestro hit a deterministic internal failure — the same code path, twice — while serving your local track to the AirLens. That’s actually good news for both of us: deterministic crashes get found and fixed; random ones hide.
Two things from you would close the loop completely:
-
In Maestro’s Help menu you’ll find a log export (it’s a downloadable zip file) — that bundle contains my side of the story (what the app was doing in the seconds before the crash), which the Windows crash record can’t show. Send it over via email or through Maestro’s support system in Settings, and I can likely name the exact culprit.
-
What CPU is in that PC? (One of the failure modes I need to rule out relates to processor generation.)
The bigger question you’ve raised is about local only users.
Maestro was built around the marriage of your own library and Qobuz’s hundred million tracks, and today’s home screen assumes both. But the app already knows whether you’ve connected Qobuz — so what I’m considering is a home that respects that: when there’s no streaming service, your library leads, front and center, with the streaming shelves demoted and labeled — “explore with Qobuz” — and clicking one shows you what it is and what it would take to hear it, instead of doing nothing.
Same Maestro, same look.
Does that match what you’d have expected that first screen to be? Or would you go further — hide the streaming world entirely until asked? What I worry about that approach is when a primarily streaming user comes in and then gets equally confused.
First impressions are where an app earns trust, and yours started with confusion followed by a crash. Not the introduction I want anyone to have — but the fix deserves real thought, and you’ve already contributed more of it than you know.
On play-on-add: noted, and fair. There’s a case for both behaviors and you won’t be the last Roon or Audirvana listener who expects add-to-queue to wait for the play button.
One housekeeping note: a newer release is imminent with a batch of fixes in this area of the code — once I’ve read your logs I’ll tell you whether it addresses your crash directly or whether the fix follows right behind it.
An AirLens running from a local library is precisely the system Maestro was built to serve, and I’d like your evaluation to be a fair fight against Roon. Send those logs and I’ll take it from there.
Sorry about that and appreciate you letting me know.