I just thought I would provide an update on some further investigation
work I have been doing today.

Listed below is another snippet from the SC logfile when I selected an
album by ABC on the controller (SBC):

[08-06-07 18:51:03.6787] Slim::Schema::Track::coverArt (271) Retrieving
artwork for:
file:////NAS600/media/my%20music/ABC/Traffic/02%20The%20Very%20First%20Time.wma
[08-06-07 18:51:03.6794] Slim::Music::Artwork::_readCoverArtTags (220)
Looking for a cover art image in the tags of: [\\NAS600\media\my
music\ABC\Traffic\02 The Very First Time.wma]
[08-06-07 18:51:03.7951] Slim::Music::Artwork::_readCoverArtFiles (264)
Looking for image files in \\NAS600\media\my music\ABC\Traffic
[08-06-07 18:51:04.5691] Slim::Music::Artwork::_readCoverArtFiles (352)
Found image file: \\NAS600\media\my music\ABC\Traffic\folder.jpg
[08-06-07 18:51:04.5700] Slim::Schema::Debug::query_start (26) UPDATE
tracks SET cover = ? WHERE ( id = ? ): '\\NAS600\media\my
music\ABC\Traffic\folder.jpg', '5210'

The key bit is the last line where you can see that SqueezeCenter is
updating the COVER column in the TRACKS table (on the SLIMSERVER db)
with the location of the cover/album art for track ID 5210 ("The Very
First Time").

This suggested to me that it should be possible to create my own SQL
script that would set the cover art for every track where the cover art
was missing (in the db) i.e. TRACKS.COVER was NULL. This would then
avoid the performance hit of SqueezeCenter doing this every time I
selected an album on the controller (SBC).

As I wanted to have a look at the MySQL db schema, I used the MySQL
Query Browser tool (from
http://www.mysql.com/products/tools/query-browser/) and with this found
the column on the TRACKS table that I could use to derive the filepath
for the cover art:

SELECT T.URL FROM SLIMSERVER.TRACKS T WHERE T.ID=5210

Result:

file:////NAS600/media/my%20music/ABC/Traffic/02%20The%20Very%20First%20Time.wma

As all of my album art is held in \<artist>\<album>\folder.jpg files,
all I needed to do was to set the location of this file based on the
URL filepath for the track. After a bit of playing around, I came up
with the following SQL statement:

UPDATE SLIMSERVER.TRACKS T SET
T.COVER=REPLACE(CONCAT(SUBSTRING(SUBSTRING(T.URL,1,
LENGTH(T.URL)-LOCATE('/',REVERSE(T.URL))+1),LENGTH('File://')+1),'Folder.jpg'),'%20','
')
WHERE T.ALBUM IS NOT NULL AND T.COVER IS NULL

Basically all this is doing is working from the end of the URL to find
the lowest folder location, it then adds the "folder.jpg" to this
folder path, then strips out the URL encoding stuff. I am sure that
there are probably more elegant ways of doing this, but I hadnt used
MySQL until today, so apologies if the SQL offends any of you MySQL
gurus;-)


Anyway, after I had run this against the database (it updated approx
4000+ records in about 2 seconds), I verified it by selecting a dozen
different albums on the controller and the track listing came back
virtually instantaneously. I have some further testing to do but am
very pleased with the results so far.

I will obviously need to run this whenever I add new music to the
library but as it executes so quickly, this isnt a problem.

I should add that this workaround wont necessarily work as is for
everyone who has the same performance issues (running SC on a separate
PC from a NAS) as your music library may be organised differently.
Plus, of course Logitech could change the db schema at any point
(although this is probably unlikely on any great scale). However
hopefully this may be of use to someone else.


-- 
EliteAV
------------------------------------------------------------------------
EliteAV's Profile: http://forums.slimdevices.com/member.php?userid=15932
View this thread: http://forums.slimdevices.com/showthread.php?t=45121

_______________________________________________
discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss

Reply via email to