Bugzilla – Bug 3324
Album art scaling
Last modified: 2009-09-08 09:14:00 UTC
SlimServer Version: 6.5b1 - 7137 - Linux - EN - utf8 Looks like recently album art was added as a background to the Fishbone "now playing" area. But it's interfering with visibility of the song and title information. I'll upload an illustrative screenshot.
Created attachment 1200 [details] shot showing album art Can't read the now playing data!
http://forums.slimdevices.com/showthread.php?t=23206
So, this is an issue with GD not being installed for that architecture?
It seems that way. The thread certainly suggests that for those discussing the issue there. As for this bug report, I'm not interested in going after it until it is confirmed that the GD library is working. use can try what was done in the thread, including right click->view image. filename should be cover_100x100_f_000000.jpg and should be 100px x 100px. I'm guessing that wont be the case, just as it isn't for those in the thread. GD needs to be compiled with jpg support.
(In reply to comment #3) > So, this is an issue with GD not being installed for that architecture? Essentially, the server is not attempting to perform any resizing because it doesn't think GD is functional. This is tested for with: my $canUseGD = eval { require GD; if (GD::Image->can('jpeg')) { return 1; } else { return 0; } }; at the top of Slim::Web::Graphics. The problem was apparently fixed by copying all the GD binaries from CPAN/arch/5.8 to CPAN/arch/5.8.x. It is however strange that this fixes the problem for two reasons. Firsly, @INC is set up in slimserver.pl to search 5.8.x first, then fall back to 5.8, so the relevant binaries should have been located anyway. Secondly, it is also strange that one of the logs posted contained the line: 2006-04-23 11:23:57.6105 Trying to load GD Library for TTF support: ok which is created by Slim::Display::Graphics based upon: my $canUseGD = eval { require GD; return 1; }; If GD was failing to load, both should have evaluated to false; the only difference between the two being the test for jpeg support. At present slimserver.pl doesn't attempt to load GD itself. It might be interesting to do some tests with GD added to @modules in slimserver.pl, and with a debugging option added that lists which modules failed to load at each stage, i.e. whether they failed to load from the SlimServer CPAN area and then subsequently succeeded from the system standard CPAN area. It would also be very interesting for it to dump the contents of %INC to see where everything is being loaded from.
If someone can try including GD in the list that's in slimserver.pl that would be great. As I explained on the beta list - building the perl GD wrapper can be rather complex - and you must first have a libgd2 that's been compiled with support for libjpeg, libpng and libfreetype. If you have a system package, they generally do this. The real issue here is fixing @INC so that the system library is loaded if it's available.
(In reply to comment #6) > If someone can try including GD in the list that's in slimserver.pl that would > be great. > As I explained on the beta list - building the perl GD wrapper can be rather > complex - and you must first have a libgd2 that's been compiled with support > for libjpeg, libpng and libfreetype. If you have a system package, they > generally do this. > The real issue here is fixing @INC so that the system library is loaded if it's > available. Perhaps I'm misunderstanding. I thought that the contents of @modules in slimserver.pl was just what it tried to load at startup, and quite seperate from anything that build-perl-modules.pl does. With regards to @INC, it seems to be populated sensibly on my system, containing: C:\Documents and Settings\Chris\My Documents\slim\trunk\server\CPAN\arch\5.8.8\MSWin32-x86-multi-thread C:\Documents and Settings\Chris\My Documents\slim\trunk\server\CPAN\arch\5.8.8\MSWin32-x86-multi-thread\auto C:\Documents and Settings\Chris\My Documents\slim\trunk\server\CPAN\arch\5.8\MSWin32-x86-multi-thread C:\Documents and Settings\Chris\My Documents\slim\trunk\server\CPAN\arch\5.8\MSWin32-x86-multi-thread\auto C:\Documents and Settings\Chris\My Documents\slim\trunk\server\CPAN\arch\MSWin32-x86-multi-thread C:\Documents and Settings\Chris\My Documents\slim\trunk\server\lib C:\Documents and Settings\Chris\My Documents\slim\trunk\server\CPAN C:/Documents and Settings/Chris/My Documents/slim/trunk/server C:/Perl/lib C:/Perl/site/lib . Is there any chance of adding some sort of debugging messages to slimserver.pl to see exactly what @INC and %INC contains on the problem systems?
Created attachment 1202 [details] fallback option So, given that GD is painful and unpredictable as far as being available in all systems, this patch exposes $canUseGD to the web templates so that skins can have a way to use non GD output. hreftemplate uses this the variable to add width and height to the image tag the way the images would have appeared before.
Created attachment 1203 [details] logic fix sorry, that first one had the fake negative test logic. This version is the correct logic.
Subject: Re: Album art scaling Two thoughts: (ok, 3)... 1. Better to fix the servers if we can. Let's solve the root problem before putting in hacks. 2. Web browsers can resize images. Why not let the browser do it if the server can't? 3. If 1 and 2 aren't feasible, let's make the variable something like noImageResize, rather than referring to a particular library.
The patch I attached is to let the browser do it. You can't have the height and widths there with the GD image, or the browser will still resize (thus forcing 100x100 again). The point of using the 100x100_f_ image is to get the benefit of preserved aspect ratio inside a limiting box. so we need to withhold the height and width if the scaling works. The param is so that we know WHEN to let the browser do the work. Any param name is fine with me. I'm not sure of any other way for the templates to decide, but I'm open to options. As far as guaranteeing that GD works out of the box every time, I don't see how. Even if we do fix the root cause and fall back to teh system version, you can't guarantee that every system already HAS GD installed. Granted these will mostly be linux users (because windows/osx only need one version of the library included), but I'm betting even linux users can complain loudly when the initial run has artwork going crazy.
SlimServer Version: 6.5b1 - 7173 - Mac OS X 10.4.6 (8I1119) - EN - utf8 I am seeing this on Mac OS X (Intel) as well. This also affects the "Browse Artwork" pages.
(In reply to comment #11) > The patch I attached is to let the browser do it. You can't have the height > and widths there with the GD image, or the browser will still resize (thus > forcing 100x100 again). The point of using the 100x100_f_ image is to get the > benefit of preserved aspect ratio inside a limiting box. so we need to withhold > the height and width if the scaling works. > The param is so that we know WHEN to let the browser do the work. Any param > name is fine with me. I'm not sure of any other way for the templates to > decide, but I'm open to options. > As far as guaranteeing that GD works out of the box every time, I don't see > how. Even if we do fix the root cause and fall back to teh system version, you > can't guarantee that every system already HAS GD installed. Granted these will > mostly be linux users (because windows/osx only need one version of the library > included), but I'm betting even linux users can complain loudly when the > initial run has artwork going crazy. Any objections if I give it a slightly more generic name, like serverResizesArt and make it available from a function? As for the problems with GD loading, the systems in question both seemed to have fully functional GD installations. Is it possible that something was being found in server/CPAN/ but failing to load correctly, and the system was hence not searching further through @INC. Noting that slimserver.pl makes two attempts to load modules, once with an extended @INC, then once with the standard supplied @INC, I take it that this is indeed an issue. I think I understand the point of @modules in slimserver.pl. I take it that these are modules that SlimServer simply cannot run without, yet are distributed with SlimServer (either as binaries, or for building by the user), so it as is acceptable to refuse to start without them. GD shouldn't be in this list because it is not trivial to supply the user with the means to build it themselves, and hence SlimServer can't rely on it being there. Therefore, how about something along the following lines. Adding an @optional_modules to slimserver.pl. These it should try to load in the same fashion as the contents of @modules, but failure to load any of them should not be catastrophic. This would presumably mean that GD would loaded successfully from the user's CPAN area (if it failed to load from SlimServer's CPAN area), and %INC would then point to this location, and it should hence load successfully elsewhere. I'm happy to have a go a creating such a patch, but as slimserver.pl's so cruicial, I'll leave it to someone at SlimDevices to review and commit it.
> I'm happy to have a go a creating such a patch, but as slimserver.pl's so > cruicial, I'll leave it to someone at SlimDevices to review and commit it. Here's a patch that modifed slimserver.pl as described. The behaviour for me is slightly strange. I've crippled the supplied GD binaries on my system by renaming it. With the patch as supplied, GD.pm is loaded from the system standard CPAN path, and GD::Image.pm from the slimserver CPAN path. When I attempt to resize an image, it dies with: Can't locate object method "new" via package "GD::Image" If instead I replace 'my @optional_modules = qw(GD);' with 'my @optional_modules = qw(GD::Image);' then GD::Image.pm comes from the standard CPAN path, and GD.pm from the slimserver CPAN path. The server now refuses to resize, because 'GD::Image->can('jpeg')' returns false, which is the same behaviour as discussed elsewhere in the afore mentioned thread. Placing both GD and GD::Image in @optional modules has no effect, the one listed first always fails to load on the first attempt and comes from the system CPAN, whilst the second succeeds on the first attempt. If I bypass the first attempt at loading modules from the modified @INC, and instead attempt to load GD and GD::Image from the original @INC, then resizing works fine. Hopefully the above will make sense to someone. Index: slimserver.pl =================================================================== --- slimserver.pl (revision 7178) +++ slimserver.pl (working copy) @@ -140,10 +140,19 @@ return @failed; } + # How should this get set? The command line parameters have not yet been parsed + my $d_startup = 1; + # Here's what we want to try and load. This will need to be updated # when a new XS based module is added to our CPAN tree. my @modules = qw(Time::HiRes DBD::SQLite DBI XML::Parser HTML::Parser Compress::Zlib); + # Bug 3324 + # In some cases, GD wasn't loading even though there was a working installation in + # the user's CPAN path. This is an attempt to use the use the system described above + # to load GD if possible. + my @optional_modules = qw(GD); + if ($] <= 5.007) { push @modules, qw(Storable Digest::MD5); } @@ -167,21 +176,39 @@ ); } + $d_startup && printf("Got @" . "INC containing:\n%s\n\n", join("\n", @INC)); + my %libPaths = map { $_ => 1 } @SlimINC; # This works like 'use lib' # prepend our directories to @INC so we look there first. unshift @INC, @SlimINC; + $d_startup && printf("Extended @" . "INC to contain:\n%s\n\n", join("\n", @INC)); + # Try and load the modules - some will fail if we don't include the # binaries for that version/architecture combo my @failed = tryModuleLoad(@modules); + my @failed_optional = tryModuleLoad(@optional_modules); + if (scalar @failed && $d_startup) { + printf("The following modules failed to load on the first attempt: %s\n\n", join(' ', @failed)); + } + + if (scalar @failed_optional && $d_startup) { + printf("The following optional modules failed to load on the first attempt: %s\n\n", join(' ', @failed_optional)); + } + # Remove our paths so we can try loading the failed modules from the default system @INC @INC = grep { !$libPaths{$_} } @INC; my @reallyFailed = tryModuleLoad(@failed); + my @reallyFailed_optional = tryModuleLoad(@failed_optional); + if (scalar @reallyFailed_optional && $d_startup) { + printf("The following optional modules failed to load: %s\n\n", join(' ', @reallyFailed)); + } + if (scalar @reallyFailed) { printf("The following modules failed to load: %s\n\n", join(' ', @reallyFailed)); @@ -192,9 +219,16 @@ exit; } + # And we're done with the trying - put our CPAN path back on @INC. unshift @INC, @SlimINC; + if ($d_startup) { + print "The following modules are loaded:\n"; + print map {"$_ => $INC{$_}\n"} keys %INC; + print "\n"; + } + # Bug 2659 - maybe. Remove old versions of modules that are now in the $Bin/lib/ tree. if (!Slim::Utils::OSDetect::isDebian()) {
This is giving me a headache. I think at this point I'd rather revert the changes in the skin to use the older cover.jpg urls until this can be sorted out.
(In reply to comment #15) > This is giving me a headache. I think at this point I'd rather revert the > changes in the skin to use the older cover.jpg urls until this can be sorted > out. I've committed a modified version of the patch above the creates a serverResizesArt param. How about testing for this and in href_template, and using the old style urls if it's false. Testing this patch, and seeing the difference in quality between server side resampled resizing, and client side resizing, I have no doubt that server side resizing is a worthwhile change.
I have no doubt that it will be worthwhile, but it needs to be cleaned up for users who may or may not have GD properly installed. Having run into LONG efforts trying to compile GD myself I can certainly understand that some users could be very frustrated by this. The patch only hides the problem, and if we potentially go forward to exploit the performace benefits of GD, there does need to be a better way of loading and feedback. I'd like to see what Dan has to say, when there is time, as I do not know what the actual plan is behind which packages and which versions are being included for a given platform. thanks for committing the fix. look like a good mod from here, and at least that quiets the general user complaints.
(In reply to comment #17) > I have no doubt that it will be worthwhile, but it needs to be cleaned up for > users who may or may not have GD properly installed. Having run into LONG > efforts trying to compile GD myself I can certainly understand that some users > could be very frustrated by this. The patch only hides the problem, and if we > potentially go forward to exploit the performace benefits of GD, there does > need to be a better way of loading and feedback. > I'd like to see what Dan has to say, when there is time, as I do not know what > the actual plan is behind which packages and which versions are being included > for a given platform. I suppose it depends on whether a working GD is going to be treated as a requirement, or an optional enhancement that gives SlimServer extra functionality. In the latter case, the client clearly has to do the resizing in some circumstances, and this patch seems to deal with that issue nicely. In both cases, why system with a working GD installation isn't managing to use it needs to be looked at. I'd be interested to see what log messages get generated by the above patch to slimserver.pl on some of the problem systems, and also to hear an interpretation of the results I got when I broke my SlimServer GD binaries. > thanks for committing the fix. look like a good mod from here, and at least > that quiets the general user complaints. No problem, the effort's in writing the patch to begin with.
Subject: Re: Album art scaling > ------- Comment #17 from slim-mail@deane-freeman.com 2006-04-27 > 16:47 ------- > I have no doubt that it will be worthwhile, but it needs to be > cleaned up for > users who may or may not have GD properly installed. There are two issues then, right? GD not installed and GD improperly installed. I don't think we should spend any time on trying to guess how GD might be improperly installed on a given machine. This is similar to dealing with broken Perl installs... If GD is not installed and the server can't resize images, the server should probably just serve the raw image and let the browser do the resizing. This is an only slightly more interesting problem that only affects a small number of users who should be able to build GD on their own, one way or another, so it's relatively low priority and shouldn't impact the other platforms in any noticeable way. If we can easily put a flag in for the skins to deal with no resizing, fine, but it's a low priority workaround.
(In reply to comment #19) > Subject: Re: Album art scaling > > ------- Comment #17 from slim-mail@deane-freeman.com 2006-04-27 > > 16:47 ------- > > I have no doubt that it will be worthwhile, but it needs to be > > cleaned up for > > users who may or may not have GD properly installed. > There are two issues then, right? GD not installed and GD improperly > installed. > I don't think we should spend any time on trying to guess how GD > might be improperly installed on a given machine. This is similar to > dealing with broken Perl installs... > If GD is not installed and the server can't resize images, the server > should probably just serve the raw image and let the browser do the > resizing. This is an only slightly more interesting problem that > only affects a small number of users who should be able to build GD > on their own, one way or another, so it's relatively low priority and > shouldn't impact the other platforms in any noticeable way. If we > can easily put a flag in for the skins to deal with no resizing, > fine, but it's a low priority workaround. If there's no GD installation, or a non-functional GD installation then I quite agree, let the client do the resizing. However, in http://forums.slimdevices.com/showthread.php?t=23206 there were perfectly good GD installations. A test script that used GD from the systems CPAN area ran perfectly. The problem was arising because a broken GD within slimserver's CPAN. Surerly this *is* a reasonably serious problem --- SlimServer being unable to use a fully working GD. I can't see any reason to suspect that this might just affect GD. The tests that I performed under windows do seem to hint at a potential solution. I think the problem is that when 'use GD' is called, that goes on to 'use GD::Image' and 'GD::Polygon'. It then fails with the binaries, and slimserver.pl accordingly deletes the GD symbols and GD from %INC. GD::Image and GD::Polygon however remain, and point to the SlimServer CPAN. slimserver.pl then carries on to load GD from the system CPAN, and succeeds. Now GD is loaded from the system CPAN, but GD::Image and GD::Polygon are loaded from SlimServer's CPAN, and this seems to cause problems. If nothing else, then there's the potential for different versions to be in use. My solution is hence to update slimserver.pl to look for all additions to %INC after calling 'use $module', and then call Symbol::delete_package($newModule); and delete $INC{$newModule} on all of them. I've attached a patch which attempts to do this. It works for me; if I cripple my SlimServer CPAN version of GD, GD.pm, GD::Image.pm and GD::Polygon.pm are all loaded from the system CPAN area, and resizing works. I'd be interested to hear if this deals with the problems on the problem systems.
Created attachment 1207 [details] Patch slimserver.pl to delete *all* new symbols if a package fails to load.
Created attachment 1208 [details] removed temporary debugging
On my Mac I had to jump through some hoops to get things working. I installed libgd using Fink and then installed the Perl GD bundle using CPAN. It still wasn't being found so I copied it over the slimserver-supplied packages and now it works. I love the way it looks/works but that is a lot of work for a typical Mac user.
Subject: Re: Album art scaling > ------- Comment #23 from evan@rabeck.com 2006-04-28 07:25 ------- > On my Mac I had to jump through some hoops to get things working. > > I installed libgd using Fink and then installed the Perl GD bundle > using CPAN. > It still wasn't being found so I copied it over the slimserver- > supplied > packages and now it works. > > I love the way it looks/works but that is a lot of work for a > typical Mac user. GD should work out of the box on the Mac, we include a GD build. If it's not working, then it's a separate bug.
(In reply to comment #23) > On my Mac I had to jump through some hoops to get things working. > I installed libgd using Fink and then installed the Perl GD bundle using CPAN. > It still wasn't being found so I copied it over the slimserver-supplied > packages and now it works. > I love the way it looks/works but that is a lot of work for a typical Mac user. I quite agree. IMHO, it's reasonable to expect a user to have to install GD for themselves, as long as SlimServer does work without it. However, I don't think they should really be expected to go further than a standard GD install however. If you've time, would you mind trying the following test. Reinstating the original SlimServer GD packages, making sure that resizing now fails, and then trying the patched version of slimserver.pl. I'd be interested to see if this technique does actually solve the problem.
I think I found the source of my particular problem... the provided GD.bundle (in GD.bak) is not a universal binary. TheBrain:~/Library/PreferencePanes/SlimServer.prefPane/Contents/server/CPAN/arch/5.8/darwin-thread-multi-2level/auto erabeck$ file */*bundle DBI/DBI.bundle: Mach-O universal binary with 2 architectures DBI/DBI.bundle (for architecture ppc): Mach-O bundle ppc DBI/DBI.bundle (for architecture i386): Mach-O bundle i386 GD.bak/GD.bundle: Mach-O bundle ppc GD/GD.bundle: Mach-O bundle i386
(In reply to comment #26) > I think I found the source of my particular problem... the provided GD.bundle > (in GD.bak) is not a universal binary. > TheBrain:~/Library/PreferencePanes/SlimServer.prefPane/Contents/server/CPAN/arch/5.8/darwin-thread-multi-2level/auto > erabeck$ file */*bundle > DBI/DBI.bundle: Mach-O universal binary with 2 architectures > DBI/DBI.bundle (for architecture ppc): Mach-O bundle ppc > DBI/DBI.bundle (for architecture i386): Mach-O bundle i386 > GD.bak/GD.bundle: Mach-O bundle ppc > GD/GD.bundle: Mach-O bundle i386 I believe that the patch above should deal with this problem.
Created attachment 1209 [details] @INC reordering patch - updated by dsully Chris - here's an updated patch which works for me.
Evan - I just updated the GD.bundle to include i386 parts. If you're runing svn - update, otherwise it wil be in the 2006-04-29 nightly.
(In reply to comment #28) > Created an attachment (id=1209) [edit] > @INC reordering patch - updated by dsully > Chris - here's an updated patch which works for me. Works for me too. Would be interesting to confirm that this deals with the problem systems.
Good. I'm going to commit this so it'll get more people running it. Will - since you originally submitted this bug - does it fix your problem? Thanks
Subject: Re: Album art scaling I can try it when I return home tonight or tomorrow. Will it be in tonight's nightly? If not, please give me a hint regarding the process of applying the patch. W Sent from my BlackBerry� wireless handheld -----Original Message----- From: Slim Devices Bugzilla <bugs@bugs.slimdevices.com> Date: Fri, 28 Apr 2006 12:53:37 To:spblat@gmail.com Subject: [Bug 3324] Album art scaling https://bugs-archive.lyrion.org/show_bug.cgi?id=3324 ------- Comment #31 from dan@slimdevices.com 2006-04-28 12:53 ------- Good. I'm going to commit this so it'll get more people running it. Will - since you originally submitted this bug - does it fix your problem? Thanks ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.
I can try it when I return home tonight or tomorrow. Will it be in tonight's nightly? If not, please give me a hint regarding the process of applying the patch.
Yes, it will be in tonight's 6.5 nightly.
given the skin-side fixes, look for artwork that would normally have an aspect ratio that isn't 1:1. If you see the image in teh right proportions, then it is all working. If the images are being stretched, that's the hint. You can also check by right clicking and viewing the image. If all is working, what you get will be small as well instead of the raw image's natural size.
Mac/Intel is working correctly as of the current nightly. The included GD.bundle file is being found/used and working. Thanks.
Fixed for me with the 4/29 nightly. My browser is now doing the resizing. Questions: 1) If I install libgd and/or GD.pm, will I get enhanced functionality? 2) Would you like me to test any proposed auto-build/include functionality, or shall I go ahead and install GD manualy?
(In reply to comment #37) > Fixed for me with the 4/29 nightly. My browser is now doing the resizing. > Questions: > 1) If I install libgd and/or GD.pm, will I get enhanced functionality? > 2) Would you like me to test any proposed auto-build/include functionality, or > shall I go ahead and install GD manualy? As I understand, automating the build of GD is highly non-trivial, and hence won't be done by slimserver. The latest nightly should however mean that slimserver will be able to use GD from the system CPAN path. Having GD available will mean that the server will be able to resize artwork, which improve the look of the thumbails, and also preserves aspect ratio. GD is also, I believe, required for unicode support.
Will - you should install GD manually, or via your package system. Thanks
This bug fix is now part of a released version, and so has been marked closed. If you are still experiencing this problem, please reopen the bug.