Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[comox]

When the new audio analysis with waveform feature was introduced in December 2019 I tried to reanalyze my library. It got about 2/3 complete and then crashed corrupting my library (I lost all views). Fortunately I had a recent backup and I recovered ok, but it was painful because I had to re-enter all of the changes I made over the 7+ days that my computer was doing the analysis.

This experience scared me because as a long time time user with a gazillion hours invested in my library I had never once experienced a crash that caused library corruption. I decided to wait a while for the new analysis feature to mature before I tried it again.

It's now a little over a year later and I decided to try again yesterday. I first cleared all audio analysis fields to ensure all data was created fresh, and to provide a simple method for me to tell which files had completed analysis and which still needed to be done. I proceeded cautiously doing the analysis in chunks of about 20,000 files, stopping after each to make a backup, and restarting MC to ensure all files were flushed to disk.

I succeeded in analyzing about 100,000 files before MC crashed, this time causing a very nasty Windows blue screen.

I successfully restored my backup, and having learned from my experience a year ago, I did not make any changes to my library while doing the analysis, so I did not have to re-do any work.

We can rule out a hardware problem because I upgraded my system in 2020 and have seen the crash on two different systems.

My library may be a little different than the norm because in addition to the usual collection of music and movies, I have a large collection of audiobooks, courses, and podcasts (about 700GB with 3 years of play time). Many of these audio files run several hours per file.

My hunch a year ago, and my hunch today, is that the problem is caused by the waveform feature. I suspect that with libraries like mine, too much waveform data is generated and some threshold is crossed causing MC to crash. The size of my "field (waveform).jmd" file was about 250MB at the time of the crash.

This hunch is reinforced by the following observation. After I restored my library I tried to resume the analysis at my last known good checkpoint by filtering on those files for which waveform was still empty. MC consistently hangs when I try to create this filter, and is apparently not able to handle the large amount of data in the waveform field. I have to kill MC with task manager to exit this hang.

My plan is to continue doing the analysis in chunks, but this time deleting the file "field (waveform).jmd" after each chunk.

Because of the large time periods involved, and risk to my library, I'm not willing to run more tests for JRiver.

I have never used, nor will I ever use, the waveform display feature.

I think you should add an option to turn off waveform analysis, as other users have requested.

[EnglishTiger]

I think you should add an option to turn off waveform analysis, as other users have requested.

I agree with you completely - Creating of the Waveform Filed/Tag should be OPTIONAL.

Unless you are not using the PC you are running the Audio Analysis on for anything else I would recommend that you reduce the "chunk size" down to around 5,000 files and makes sure you are not using all the available cores for the analysis. MC/the O.S. is going to have to rewrite every track/file analysed back to disc which can take a fair bit of time. To reduce the number of incidences MC "hanging/stalling" if it is being used for something else at the same time. Hopefully you are using the "Disc Dive Activity Light" and not the MC status bar to know when the analysing of the tracks/files and all the subsequent file rewriting has been completed.

Oh and if possible, until MC do make the Waveform Analysis Optional,  try to avoid doing analysis of any tracks/files that have a duration of more than around 30 minutes.

[jkauff]

That's a huge number of files. Do you have a utility that displays your memory use? I wonder if you're running out of usable RAM during the analysis.

[JimH]

When you are analyzing file types a group at a time, you may be able to find a file that is causing trouble.  If so, we'd like to see it.

Logging should show you where the problem is.  The wiki has a topic.

What version of MC are you using?

What OS?

I succeeded in analyzing about 100,000 files before MC crashed, this time causing a very nasty Windows blue screen.

That's a hardware problem.  Could be a driver.  Are you using a NAS?

[leezer3]

There are plenty of us with libraries of similar sizes & not experiencing the problems you're seeing.

I would agree that if you're seeing BSODs, then this is *highly* unlikely to be Media Center's fault.
First thing I'd be doing is running memtest on your machine.

The stop number from the BSOD may or may not be helpful.

[Vocalpoint]

There are plenty of us with libraries of similar sizes & not experiencing the problems you're seeing. I would agree that if you're seeing BSODs, then this is *highly* unlikely to be Media Center's fault. First thing I'd be doing is running memtest on your machine.
The stop number from the BSOD may or may not be helpful.

Agreed. Blue screens are 100% associated with hardware and their drivers. An application on it's own is not capable of creating a blue screen. There is always a file (or files) in play during a blue screen event and it will always boil down to one file to blame.

The stop numbers and other data (that can be captured from the mini dumps from a few easily downloadable free tools) will tell you where you need to look. And MC will not be directly at fault here - although it may need to reference the dodgy file or driver to operate correctly.

I once hit a scenario where my POWER SUPPLY was the main cause of blue screens - after troubleshooting for weeks. Trust me - new hardware does not always mean a dodgy file cannot self destruct with the right conditions.

Cheers

VP