Bug 35 - MediaCenter compatiblity
: MediaCenter compatiblity
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Web Interface
: unspecified
: PC Windows XP
: P2 enhancement (vote)
: ---
Assigned To: KDF
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-19 16:34 UTC by Blackketter Dean
Modified: 2008-09-15 14:37 UTC (History)
0 users

See Also:
Category: ---


Attachments
allows infoFormat type formatting for cover filenames (1.38 KB, patch)
2003-12-20 03:14 UTC, KDF
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Blackketter Dean 2003-12-19 16:34:49 UTC
I just spoke with two of your colleagues Andrew and Sean about a particular problem and Sean 
suggested you might be able to add a particular capability to the SliMP3 to make it�a little more 
compatible with Media Center by J.River. (Used to be called Media Jukebox)
�
http://www.musicex.com/mediacenter/
�
So far the system we installed for Mothers Bar & Bistro in Downtown Portland is running great, 
however one of the abilities of the SliMP3 software to display the album cove art is causing us 
some difficulty because of the way that Media Center stores it...
�
Basically all of the album cover artwork for Media Center is stored in one central folder.� The files 
are each named as %ARTIST% - %ALBUM%.jpg in a specified folder.�
�
I can't find anywhere in the SliMP3 software software to allow this type of cover art storage.�
�
Would it be possible to add an option to allow the SliMP3 server software to look in a named folder 
for it's cover art in the above format?
�
Best Regards,
�
Martin Bass
�
�
� Martin Bass
� Founder & Chief Technical Officer
� Web:� www.cfreaks.com

�
Comment 1 KDF 2003-12-20 03:14:37 UTC
Created attachment 3 [details]
allows infoFormat type formatting for cover filenames

Prefix the covert art filename with % and use the same variables as the Title
Format strings.  Valid variables: CT (content type), TITLE, GENRE, TRACKNUM
(tracknumber as an int), FS (file size), ARTIST, ALBUM, COMMENT, YEAR, SECS
(total seconds), DURATION (minutes and seconds), VBR_SCALE (vbr/cbr), BITRATE,
TAGSIZE, VOLUME (volume name), PATH, FILE, EXT (file extension), LONGDATE
(current date, long), SHORTDATE (current date, short), CURRTIME(current time).
Elements can be separated by anything (or nothing).  Need strings changed to
explain this.  No central folder support yet.
Comment 2 KDF 2004-02-05 02:51:49 UTC
I'll create a coverpath option to finish this off.  its simple enough, and can
be handled just like the playlist path, with the same security.
Comment 3 Dan Sully 2004-04-01 23:09:33 UTC
Can this bug be closed? Has the work been done?
Comment 4 KDF 2004-04-01 23:16:13 UTC
The original request seemed to want all artwork stored in one location.  I have
been pondering something like an artworkdir setting, but haven't sorted out just
how to work it out.
Comment 5 KDF 2004-04-04 13:49:41 UTC
Committed April 4, 2004.  This feature now allows the setup of a central
location for artwork.  Artwork in the same location as the music file is still
enabled, regardless of ArtFolder setting.  This setting resides in Server
Settings->Interface.  By default Windows and Linux use $bin/Artwork (where $bin
is the locaiton of the server executable.  OSX uses $ENV{'HOME'}/Music/Artwork.
Comment 6 Chris Owens 2006-06-16 14:42:07 UTC
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006.  I am setting them to targets of 6.2.1 to keep them from showing up in my queries.