Disappointed with latest release (1.47) of AC. Firstly, when I fire up the software I get to see a message that tells me 'folder not found'. Ten minutes later, AC finds the folder it originally told me did not exist. But there's worse to come. When my files do appear in AC, and I click on 'Date Modified' or 'Name', all hell breaks loose! I get the Mac Beach Ball of Death' spinning away. And spinning. And spinning. Even more spinning! There's only one thing to do to remedy this problem.......It's called 'Force Quit'.
Blimey, and I thought Skippy the Bush Kangaroo was annoying! And don't get me started on Sons and Daughter's, for Santa's sake!
Back to AC version 1.43 for me. Oh, yeah. And until this annoyance is resolved I refrain from wishing you a merry Christmas. So there!

Hi Dougster,

While we cannot take responsiblity for Skippy, we do take problems with AudioCodex very seriously. So, firstly, apologies for your experience. Secondly, thanks for the bug report.

Your situation, from memory, is a little bit of an edge case for us, but obviously we need to test more thoroughly against external volume watched folders with a large number of items. We are attempting to reproduce the issue, although we have some suspicions about where the problem originates.

AudioCodex 1.47 introduced some "smarter" code to disable Source list items if they are not found at app launch. You may be falling foul of this new code, as we may not have considered every situation.

We will get to work on it after the barbeque.

Hi Doug,

I've investigated the issues you reported further, and I'm pretty sure that what you are seeing is due to a user-interface synchronisation error in version 1.47, where the user-interface is not being properly updated when selecting a Watched folder until after the initial scan of its contents is completed.

Compounding this, a (redundant in this case) check of the existence of a Watched folders files is being carried out after the folder has been scanned, but before the user interface is updated, which is almost doubling the amount of time required to initially scan and display a Watched folders contents, and while the initial scan of a Watched Folder is carried out on a dedicated thread, leaving the user-interface freely responsive, the final pre-flight check is currently carried out on the main thread, and as such the app may beach-ball temporarily while the pre-flight check is underway if there are a huge number of files to verify.

This lag is most apparent if a 'locatable-but-as-yet-unscanned-this-session' Watched Folder that contains a 'lot' of items nested in subfolders is auto-selected at launch-time, due to that Watched Folder having been the last viewed source-item when the app was last quit normally. I didn't notice this lag during testing as I don't usually use individual Watched Folders with more than a few thousand media items in them; from memory you are using a Watched Folder with way more items than that, and these factors, combined with my poor choice of default descriptive appendage for Watched Folder titles ('folder not found' in this case) have converged to produce the anomalous behavior you described.

As such, I feel it is likely that the app didn't actually crash ( you could verify this in Console.app's Crash Reporter logs) and would have 'un-beach-balled' and returned to normal functionality once the entire scanning process for the Watched Folder was completed, but I will need to perform some additional edge-case testing to confirm this.

Thanks again for bringing this to our attention, I have already made interim changes to the current build as a result, and I will also be going through the Watched Folder scanning code in detail to check that nothing else is amiss. We will have these items fixed for the next official update, but we have yet to decide on a release date for that verison, so in the interim I'll prepare a special build for you that hopefully eliminates or at least mitigates these behaviors; I'll email you a download link when it's ready.

Cheers,

Mantis

Hi Mark,
Thanks for the perfect Christmas present! AudioCodex is now working superbly again. Perhaps it's my greed in overloading it with too many MP3s that made it die on me in the first place! But you've performed a miracle. I'm really impressed in how swiftly you sorted out the problem I had with AC. Not only that, I really do like the way in how AC fires up with the scanning of files being shown.
Thanks for your hard work. It really is appreciated.
Happy Christmas!
Doug.

Just to follow up, AudioCodex 1.48 resolves the issue discovered by Dougster. It is a recommended update for all AudioCodex users, especially those with large Watched Folders.