larrettp;299951 Wrote: > 2. It seems to me that there are 2 distinct functions to the > SqueezeCenter application. One is to gather the information abou all > the tracks in the library and the other is to access that information > to play the track (i.e. access and run the file). It's already partly separated.
The scanner code runs in a separate process but it also uses some common code, for example data access code to access the database. The design of the SqueezeCenter application is going towards object orientation, but some old parts hasn't reached this state. The the main part of the application handles: - User interaction through web interface, SqueezeBox Controller interface and IR Remote interface. For example to browse your music library in various ways and create/manage your playlists. - Playing music (streaming the music data over the network). - Adding new tracks found when browsing your library to avoid having to perform a full scanning which take a bit of time. It has been discussed that the main art of the application would be appropriate to modularize a bit more than it is today, for example so you can only run the "Playing music" part on a small computuer(for example a NAS), while running the web interface on a real computer. This kind of modularization would make it easier to run SqueezeCenter on a low resource device such as a NAS. larrettp;299951 Wrote: > > During the scan process, Playlists could be checked for any tracks > which no longer exist. These lines could easily be removed from the > list and an error report could be written to the log. This is done already today. larrettp;299951 Wrote: > > In all of the above, I am assuming the recommendations I have made > regarding Many-to-Many tables and Indexes have been applied as I can't > see any of these methods working efficiently without them. > While I can understand that your recommendation will result in better performance in some situations, I also think it might be quite a big job to change the SqueezeCenter perl code so it works towards this new structure. I've done some work in the Custom Scan plugin that is in the same line as your suggestion, basically a single "tracks" table that contains multiple rows per track. Actually it contains one row for each track/attribute combination where an attribute for example can be a genre or artist. The problem I got was that this table obviously got quite large and contained 30 rows per track if a track had 30 attributes. The result was a table size with about 3 000 000 rows for some users with a large library, which resulted in poor performance. I experimented with indexing but I did never find a solution to the problem. We had a discussion regarding possible solutions in this thread: http://forums.slimdevices.com/showthread.php?t=38714 One problem with the Custom Scan plugin is that it needs to join with the SqueezeCenter standard tables in some situation and this is troublesome since there isn't any good keys to join with that survives a rescan. The result is that in some situation I need to join text/varchar columns which obviously is a bad idea regarding performance. larrettp;299951 Wrote: > > Seriously, if you want to discuss this further offline and you are a > Slim Devices employee, please get in touch through my e-mail address in > the forum database. I'd be delighted to help. I'm not a Slim Devices employee. For most people I don't think the current SqueezeCenter database is a problem regarding performance, it's only under some circumstances it causes problem, for example when running it on low resource hardware with a large library. I think the major problem with your suggestions is that it will make the database less "object oriented" and due to this it will be a bit of work to adapt the object oriented code to it. So I suspect that before anyone at Logitech/Slim Devices are going to start changing the code according to your suggestion, they are probably going to want some third party developer to verify that the performance increase or resource usage decrease with this change results in a major difference. If it just get us 10-20% improvement I suspect no one is going to think it is worth the work. However, Logitech obviously needs to answer this themselves, this is just my suspicions. Posting your ideas in the Developers section of the forum will make it visible for the correct people, so if you really think this change is going to make a big difference I would suggest that you post your ideas there and hope someone from Logitech likes to continue the discussion. -- erland Erland Isaksson 'My homepage' (http://erland.homeip.net) 'My download page' (http://erland.homeip.net/download) (Developer of 'TrackStat, SQLPlayList, DynamicPlayList, Custom Browse, Custom Scan, Custom Skip, Multi Library and Database Query plugins' (http://wiki.erland.homeip.net/index.php/Category:SlimServer)) ------------------------------------------------------------------------ erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=45261 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
