There are simpler solutions such as mconnect HD that work perfectly.
I tried AS but was not convinced in the first place and was reluctant to enter this subscription scheme.
So I came back to 3.5 and faced, again, that problem of DB syncing that does not seem to end.
Two days ago, I tried to update my library by adding 6 new albums (on a total of 6000). That took several hours without results. I stopped it and tried to find which album created problems. Hard to tell without log file… Randomly I finally isolated the culprit.
After the end of that successful DB syncing (5 files out of 6 successfully ingested), I decided to try with a new set of files (20 new albums). Obviously I put aside a copy of my DB, just in case.
The process is now running for more than 4 hours and is still stuck in the 'Synchronisation" phase.
I don’t know what is happening: no error message, nothing is coming out, and apparently no progress.
With mconnect HD, files are copied to the NAS, and a few minutes after they can be played.
I’m in a way lucky as I know a few things about computer but I can imagine how painful it is for a music lover without any knowledge in computers.
It’s a pitty that the algorithm of DB syncing is not explained (What happens when the app displays “synchronisation’ with a full blue bar, and what happens later when the message “synchronisation of /xxx/XXX” is starting to appear with a moving blue bar showing progress”. Clear messages on what the application is doing are clearly missing there.
So, I finally subscribed to see if there are some improvement in AS. So far, nothing very much conclusive…
I subscribed and I already regret that. There are still problems in the DB syncing algorithms.
After I successfully imported several albums, I thought that Studio was better than the previous version (3 hours and a half to update the library).
So, I decided to import one album I suspected to cause problems to the synchronization process. Studio run all the night, stuck at the “Synchonisation” phase. I don’t know what the hell this bloody algorithm is doing. I don’t understand why already imported files are scanned again. Are we here a victim of the MS approach: programming without thinking and leaving the user to fight with the bugs?
Are you using a windows 10 computer or a Mac? Because either OS you are using there are logs with it. On MacOS it’s a bit more difficult to get them but on Windows 10 it’s more simple.
I’m on a MAC and I use the console to filter the messages from Audirvana. Thing is that when the application is in the “Synchronisation” phase with a full progress bar, there is nothing shown in the log that seems to be relevant to the import procedure. After, when AS starts to analyse audio files, and the progress bar is active, from time to time I get some messages (Wrong cue sheets for example).
I can understand that some files cannot be imported, provided that an explicit error message is provided and that the whole process is not stuck.
Is there a way to know more about this? Is spent the whole week-end trying to understand the root cause…
Does the file path in your cue sheet still exist or have been moved to a different location?
Indeed it’s a bad cue sheet but problem is not really there. Problem is:
- To understand what the app is doing when showing 'Start syncing" or "synchronisation " message? Does it launch a kind of “find” command and then later on process the result?
- Why sometimes it takes “only” a couple of hours before it really starts the synchronisation? And why it may takes several hours (10 hours at least) without showing any progress?
- Why can’t we get the full list of errors/warnings in a separate file to try to understand why some files are not accepted and block the import process?
And yet another thing I don’t really understand:
Why the app is rescanning the full list of audio and cue sheet files when there are no changes into the vast majority of them (Only 1 album out of 6000 was updated)?
Isn’t there a room for improvement there?
On top of that, I noticed that the application crashed last night at 03:28 (Date of the crash report) with the following error:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000000000d0
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler 
What is strange is that I did not notice that this morning when looking at the status of the app…
That could explain why the import process did not end. But Why?
can you send us the whole crash at firstname.lastname@example.org?
I just sent the crash report.
But can you tell me how to access the log as the Console in Catalina is sometimes useless as it periodically remove the old messages.
Some strange error messages like this one:
Local Library Sync: Error setting albums folder loaded image in folder XXXX
What does this mean? Is this linked to problems in reading the image file? Bad filename?
Ok, after 4 hours, finally, the whole DB has been finalised. Now, I copy that version to a backup directory and will try to figure out why one album (One directory with 31 audio files, a booklet in pdf and one image in jpeg) cannot be imported to the DB…
I look carefully to the famous directory/album that is posing problems but did not find any clear reason why this particular album cannot be ingested. Apart from the audio files are larger than usual (More than 100MB), I did not find anything inside that could explain why it does not work.
I will try to play the album directly without importing it, just to see if there are problems or not.
I successfully imported the album into the active playlist and I did not see any problem at all to play it (Tried multiple tracks).
So, I’m a bit confused here. No idea on why that particular album cannot be imported.
I know that all my passed problems with wrong encoding of some accented characters is now solved, thanks to a specific process I put in place to clean everything up.
Still a mess. I tried to add the missing album (That Audirvana can play without any problem apparently) in the DB, first in the original version, then after having removed the potential sources of problems in the filename “& and ,”.
Nothing works! After 2 hours, process seems to be stuck somewhere, but where???
No information provided on the logic of the algorithm, no error message, no log, nothing…
And after all, what is the purpose of such an application where you spend more time trying to debug it than to enjoy listening to music? CD players do not pose so many problems: put the CD, push play and listen.
I probably shouldn’t get involved in this, but I do it anyway. I agree with you about the ease of use of the DB functionality.
But you can now just listen to music, right? Then you send the files to Damien and ask what’s wrong with them. Then he can probably solve it and you can relax and listen to music.
Don’t get annoyed by a piece of software.
Yap. Actually if you want to listen like with a cd player drag and drop in playlist and play - it works! Of course the library it’s a cool feature and useful for many. And annoying for others.
Ok, I finally found a solution to this! Last night it came to my mind that the network volume I used to store the audio files was maybe a bit too big (6000 albums and 90k tracks…).
I created a new shared directory on my NAS on which I initially put the album that created problems during import. And it worked!
So, I continue by adding new albums and that worked as well!
As a conclusion, I think there are limits that need to be put on the size of the mounted volumes we can use to store our audio files. I don’t know exactly where to put that limit, but I would say that above 4000 albums (rule of thumb) , it’s better to create another volume.
So, now, AS works like a charm and I can enjoy the music. Even the radios are reachable now (apparently not this json error anymore).
I’m not regretting my subscription anymore!!
This topic was automatically closed 375 days after the last reply. New replies are no longer allowed.