View Full Version : File Deficit after Reloading SqueezeCenter

2009-06-13, 07:34
My Vista SqueezeCenter server is a slim-profile, energy efficient HP machine in my homerun closet.

Its nearly sole use is to serve my music files to 2 Booms and a Duet.

However, over the past month it has started to lock up more and more frequently.

So yesterday I rolled it back via the Windows restore function by a month. However, it continued to lock up so I uninstalled and reinstalled SqueezeCenter 7.3.2 or whatever the latest release is.

I also moved all the music off the C-drive onto one of the 2 external hard drives prior to the roll-back. I have about a terrabyte of .flac files on those hard drives now.

However, I noticed that the song or file count in SqueezeCenter decreased by 6000-7000 files. I checked the folder that SqueezeCenter scans and it contains valid shortcuts to all the music and yes, I did a total rescan when I reinstalled SC.

I browsed to the folders in question via SC also. So clearly SC is recognizing the folders in question:


I did a file count in the folders in question and came up with over 40,000 but there are graphics files, some .cue files, and some .log files as well as a few others.

current file count per SqueezeCenter: 32,000+
current file count per Windows explorer: 40,000+
file count per SqueezeCenter prior to reinstall: 42,000+

Was the pre-reinstall file count erroneous and contributing to the unstable behavior?

Most of my music files are .flac but there are also .mp3 and .ape files.

Any thoughts?


Jim (in Austin)

2009-06-13, 11:00
Well, I decided to answer my own question:


That page shows all the files and their distribution and totals.

Apparently (?) SC was reading all the non-music files and counting them (?) and this may have resulted in the system instability I was seeing (?).


2009-06-13, 11:39
Also I noticed a stray shortcut to a music folder in one of the music folders.

Could SC have counted one of the folders twice?

Actually I'm glad this problem gave me the opportunity to clean up SC.

When I first started ripping and storing files on the server, I didn't have a good overall game plan. I still don't but it's improving.

Perhaps sample setups and strategies for storage and tagging of files would be a good addition to the new and improved website.

Several folks with cool, stable setups could submit the details of their setup for publication on the website so that folks new and old to Squeezebox could benefit and not make mistakes like I did.

2009-06-13, 13:29
Are you sure you installed SC 7.3.x and not a beta version of SC 7.4? SqueezeCenter 7.4 has been experiencing scanner problems that miss many files.

2009-06-14, 03:42
I'm using 7.3.2

2009-06-14, 03:59
So what is your expected song count? By your spreadsheet I count 35,674 music (flac, ape, and mp3) music files.

Are these music files all single-track-per-file (each file is one song) or do you have any albums ripped as a single file with a CUE sheet to break them up into tracks?

What do you use the .cue files for? If they're not used to break up album-per-file rips into tracks, I would recommend going to Settings > Advanced > File Types and entering "cue" into both of the 'Disabled' extensions boxes, then run a 'clear library' scan.

Does SC see all three of the linked music folders? Can you confirm that you have music files from each of them?

2009-06-14, 04:24
Also I noticed a stray shortcut to a music folder in one of the music folders.

Could SC have counted one of the folders twice?

Yes. That might explain how SC counted 42,000 songs when there were only 35,000, but not why it now only sees 32,000.

Most people use a fairly simple library organization, which works well for all but classical music:


Then maybe a folder for compilations.

Various Artists\Album\Songs

I used to have my library split across drives, so split it using something like:


2009-06-14, 04:28
I did a complete reinstall of Vista plus updates (which was agonizingly slow because of Vista)

I then reinstalled SC 7.3.2 and the file count matched exactly.