[mgalusha]

On thing to keep in mind, I'm pretty sure when it loads a play list it's putting all the pathes to all the songs in memory and I think it checks to see if they all physically exist on the drive. So instead of loading 1500 small index numbers from the DB into memory, it's probably creating an array with potentially very long strings and then checking to see if all the files are there.

I haven't looked at the code but I know if I hit play on a parent folder while browsing by folder and there are a lot of children and songs below it will take a LONG time before it even starts playing as it builds the play list on the fly. This makes me think it's checking each file on the disk and perhaps reading the tags or trying to determine the length. My slim server is still 6.5 and it's always behaved this way. The machine has a 2.8GHz P4 with 1.5 gig of ram and does nothing except run Slim server. It's a win xp box.

I have connected to the MySQL db and running queries against it didn't show any performance issues so this reinforces my thought that it's checking to see if everything returned from the DB query actually exists. It would certainly be faster to just try and play each song in the playlist without checking and if it's not found, handle the error in the code and move on.

This is just speculation but it seems to behave this way.

Oh - the Now Playing box is so you can put in what you're currently listening to.

[larrettp]

I have always suspected the same thing. This is why I find the outrageous times for library scans so annoying! What is the point if it is just going to, effectively, rescan every time you load something and the scan again when the track comes up to be replayed!

[bpape]

Not sure what you mean.  When you load a new disk, you can tell it just to look for new things and not rescan everything.  Also, these scans simply fill the DB with the metadata about the disks with regard to artis, genre, year, etc.  It has nothing to do with playlists.  The playlist is simply a list of pointers to the song elements and it verifies that they're all still there.

I guess it could use the buffer it has and scan for the next song in the list as the first song finishes but that would then make it prettty slow and nasty to navigate through the list to pick something when played out of the order it's stored in.  For 99.999% of the users who have playlists that are MAYBE at most 100 songs, it's not even noticible.  7500 songs, yeah, that's going to take a while. 

Just not sure of any other way that they can verify that all the songs in a playlist are all still valid without doing this kind of scan.  I suppose they could build a mechanism into the interface that would auto-check and correct any and all playlists every time you deleted a song or CD but then that part would become VERY long and drawn out - though not likely something that would happen all that often.

Bryan

[mcullinan]

I choose Scan changed and New music and the scan doesnt take long at all. Of course I am running on a Quad 2.5 G5, but I believe it only runs on 1 thread, so it acts like it only has 1 processor. Im sure its more disk intensive anyway. Id say it takes about 5 minutes.
Mike

[larrettp]

I also only scan new items but this still takes a long time as I have a large library. I still maintain that, since a playlist is just a text file of song file addresses, that shouldn't need to be loaded and re-checked at startup time - just get the next file pointed to and play it. If it doesn't exist, move on to the next one. It's easy. No need for buffering. Cleaning up playlists of obsolete items could be done at scan time and that would, at least, justify the wait. How about a scan error report as well?

[BRN]

Now that people have had more time to listen to firmware 83 and 86 what is the feeling? Does one sound better than the other?

[larrettp]

On the Slim Services forum, I was given a pointer to look at the database and some of the commonly used SQL. This was because I metioned that my day job is a mainframe DB2 Database Administrator and somebody said it might be an idea to have a look.

I couldn't see which indexes are currently set up but I would strongly recommend all of the 'Number 1' and 'Number 2' indexes listed below and as many of the others as you can afford. Don't forget that there is a performance overhead when a new item is added to the database but, at the moment, the scanning process takes so long as to make this negligible. The real benefit comes when retrieving data and these indexes will definitely help most, if not all of the SELECT statements in the document I saw. Also, look at the note following the indexes about 'many-to-many' tables. This confirms, to me, the behaviour I have been seeing since I first got the software - Basically, the bigger the database, the slower it gets.

Good luck

Table name with proposed indexes underneath
-------------------------------------------
contributors
IX1 id,namesort
IX2 namesort

contributor_album
IX1 contributor,role
IX2 role

albums
IX1 id,contributor,titlesort,compilation,year,disc,des c
IX2 compilation
IX3 titlesort,disc
IX4 Year,desc,titlesort,disc

tracks
IX1 album,audio,titlesort,disc,tracknum
IX2 audio

genre_track
IX1 genre,track

genres
IX1 id,name
IX2 name

I've also spotted in the documentation that several 'many-to-many' tables are created and maintained. These are an enormous I/O overhead and, if they are not indexed, will give exactly the performance log-jam we are experiencing.

Basically, the bigger the library, the longer each operation will take as the program has to do a table-scan every time.

I would strongly suggest removing the 'many-to-many' tables and all the associated creation and maintenance and applying indexes to the main tables. Then MySQL can take care of I/O in a far more efficient and much faster way.

Try running an EXPLAIN on some of the SQL statements before and after Indexing. You should see a HUGE difference.

[larrettp]

I have worked very hard to configure the whole ReadyNas/SqueezeCenter combination based on the latest versions available and I have now achieved a workable combination of options. It is now performing well although I still maintain that the database structure and SQL are the root cause of the slowness of the scans and playlist creation (see my earlier post),

There was a further problem I experienced where a track would play for about 2-3 seconds and then stop for a couple of seconds before restarting – very annoying. I experimented with different options one at a time until I decided to reinstall using the latest versions of Raidiator and SqueezeCenter available on 28/04/08. I installed these plus the Plugin Pack and the Multiplayer Plugin Pack. Then I uninstalled all Plugins through the Settings option except:

Favorites  - I would like to disable this but the ‘tick box’ will not respond
Grab Playlist
Random Mix
Save Playlist
The Synchronizer

The key to the problem of tracks Start-Stop-Starting seemed to be this one under Settings/Advanced/Network:

Synchronized Players Startup Delay – 500

On the ReadyNas FrontView, I have disabled everything and uninstalled all Add-ons except:

Services/Standard File Protocols
CIFS
NFS
AFP
Advertise AFP service over Bonjour
Advertise AFP service over AppleTalk
   HTTP   
   HTTPS

Services/Streaming Services
SlimServer

UPnP AV            - I want to remove this but I can’t
Home Media Streaming    - I want to remove this but I can’t

Services/Discovery Services
Bonjour service

UPnP               - I want to remove this but I can’t

Services/Installed Add-ons

I have uninstalled all Add-ons

System/Performance Options

The only ticked options are:

Disable full data journaling
Disable journaling
Optimize for OS X

[woodsyi]

Thanks for the information.  I guess I will need to do a spring clean up on my setup as well. 

[larrettp]

I know there was some criticism of my use of AAC (*.m4a) file types earlier. I only used this because they all originate from iTunes and I couldn't find a sensible way to convert them while maintaining the file structure. anyway, I think I have found a piece of software which will do this for me and I wanted to know what the opinion is for the best quality file type I can convert to that can be handled easily by Squeezecenter?

Any suggestions? FLAC seems to be preferable to me but I could be wrong.

[richidoo]

I like flac. dbpoweramp might do the conversions for you, it has a batch processor, but I have not tried that yet.

I use a ReadyNASNV (256MB) also, it is just barely fast enough with ss6.5, but on SC it bogs down and gets very flakey. For instance, pressing play will always have a significant delay before music starts. Pressing play again to make sure it got the message will crash the system. Even when it runs on PC (2.4GHz P4, 1gigRAM, XP) . This is using jive remote which is another animal completely. I switched back to my old SB3 until they work it out. New gold coming out this or next week is supposed to patch a lot of these connection problems.

I browse by Music Folder. I wonder if that makes a difference with the playlist verification. Probably not, it still creates a playlist anyway.  If there is nothing in a folder it will just say "Empty." It doesn't seem to have much of a delay when I run SS on the PC, playing wavs by folder.

I can hear no difference in sound quality between ss and any version of SC7. I use an external DAC.
Rich

[larrettp]

Thanks, I must say that my ReadyNas NV improved enormously when I put the 1gb memory into it. Seriously, you won't recognise it.

SC7 isn't all bad news. I've been regularly trying the nightly updates (I work abroad during the week so, for the last few weeks, I've updated it overnight when I get home on a Thursday evening). It does a FULL scan when installed which takes ages but, after that, it just has the regular slow buts:

• Loading a playlist to run
• Saving a playlist
• Synchronisation problems
• Random disconnection of Squeezeboxes
• Inability to run with SoftSqueeze synchronised to the server alongside Squeezeboxes

You learn to live with the abysmal playlist performance but I seem to have, for the moment, got round the Synch problems by using 'he Synchronizer' plugin. this isn't bad at all. I've also stopped ALL logging and added a 3000ms pause before playing a track.

As for SoftSqueeze, I thought I could use it to play music in my bedroom as well as the other 2 boxes around the house but, as soon as the computer went into 'sleep' mode, it just froze the SC. Hey-ho!

[larrettp]

Meanwhile, in the nightly updates folder - http://www.slimdevices.com/downloads/nightly/latest/trunk/ - I have been downloading the SqueezeCenter_7.0.1~nnnnn.bin files for testing. I also noticed in there, the jive_7.0.1_rnnnn.bin  and u-boot.bin files which, on the face of it, would be usable on a ReadyNas.

Should I download these and use them? What do they do? Any answers appreciated.

Thanks.

[richidoo]

larrettp, you are a Squeezebox power user! I am relieved to finally find someone else who is having the schizoid SC7 behavior. I thought I was just doing something dumb, that wouldn't be the first time... I have had my Duet for 2 months now, been kind of a PITA before I realized it was the software causing the grief. A slim tech (Julius) told me to stop downloading nightlies and wait for the new official SC7 coming out soon. Meanwhile I just switched back to 6.5.4 to wait it out. No more missed nights of listening.

Thanks for the memory upgrade tip. I have seen that mentioned before, but unsure about how much performance improvement. I will give it a try, as I am keeping the ReadyNAS anyway. 

[larrettp]

I downloaded the 14th May nightly update and it seemed to be extremely well behaved. I noticed today that a 'final' release has been posted on Slimdevices for the ReadyNas and I've just installed that, along with the plugin pack and the Multi-player plugin pack (both of which have been impressive so far but I would advise turning off the ones you don't need).

For the first time in ages (based on the 14th May version) I'm quite optimistic here. It feels like a lot has been done and I'll report my findings back.

The only downer is that I now have to wait several hours for the initial library scan to complete before I can really try it out but the radio stations are working fine and the synchronization seems good.

More later....

[larrettp]

The latest version on SqueezeCenter for ReadyNAS has now been running all weekend and is a significant improvement on all previous verions in many respects. There are still problems but I'll summarize them here:

[list=]Stuttering - I've not had any stuttering/rebuffering problems with this at all. A BIG bonus and very welcome.[/list]
[list=]Network disconnection - One of my Squeezeboxes DID suddenly disconnect and I had to connect it via wireless instead of ethernet. This really needs to be addressed.[/list]

Playlist build - this really hasn't changed at all. There is no sign of any improvement. Just make sure you have some wet paint nearby to watch dry.

Sound quality - no problems with that. It doesn't seem to have any problems with my AAC-based library, either

Overall, well done but still not perfect. PLEASE get this performance issue sorted for Release 7.1 (or even .

[richidoo]

Thanks larrettp, that is helpful info! I am back on SB3, slimserver 6.5.4, waiting out the storm. Might give Sonos a try.

Here is the list of changes to 7.0.1 - looks like there's nothing to do with my connectivity problems, that I can see.
http://svn.slimdevices.com/repos/slim/7.0/trunk/server/Changelog7.html
Rich

[larrettp]

OK, I've had some REALLY good results from the database changes I've made to the SqueezeCenter database on my Mac. so good, in fact, that I can't wait to apply them to the ReadyNAS. The only problem is, I can't connect to it. Does anybody know the host name, port number, socket name, user-id and password I should use to connect MySQL administrator to it, please? Once I've tested it there, I'll publish the results. They are very good indeed.

[JEaton]

From an old post to the SlimDevices forums:

The default configuration of the bundled MySQL only listens on the localhost IP address of 127.0.0.1, which means you can only connect to MySQL from the same computer on which it's running. If you want to connect from another computer using SQLyog or any other software, you need to change that behavior.

Edit the file /server/MySQL/my.tt and then restart both MySQL and SlimServer. Comment out the line

bind-address : 127.0.0.01

to

#bind-address : 127.0.0.1

and MySQL will then listen on both localhost and all other IP addresses bound to the machine.

The port used is 9092, the username is 'slimserver' and the password is blank.

SQLyog is a really nice program to use for connecting to MySQL servers.  You can do both database management and run queries from one GUI.  Download the free Community Edition from:

http://www.webyog.com/en/downloads.php


Edit: I might also point out the the my.tt file is a server template file that is used to generate the my.ini MySQL configuration file for the bundled MySQL server.  You can change many configuration options within the file to tune the MySQL server.   The database engine used is InnoDB, so some of those options might yield the best results.  The defaults, IMO, are pretty skimpy on the use of memory for larger libraries.

http://dev.mysql.com/doc/refman/5.0/en/server-parameters.html

[larrettp]

That's really kind but they don't do a version for Mac. Also, does anyone know the Mac equivalent of the my.tt file mentioned here, please?