Bugzilla – Bug 16491
artwork for podcasts no longer available in NP screen
Last modified: 2011-05-27 01:47:33 UTC
I believe this is a new bug to 7.6 Thumbnails for podcast artwork are viewable in menus, but if a podcast is selected there is no artwork shown I'm seeing the URL for the thumbnail artwork fully qualified, e.g. http://media.npr.org/images/podcasts/thumbnail/npr_hourlynews_image_75.jpg but on the NP screen it refers to a cover.jpg file with a negative ID, e.g., /music/-111515904/cover.jpg I've pointed the webUI at this URL and I get a 404 error Does that indicate a server-side issue??
I'm sure I broke this one.
Backed off a Squeezebox touch to 7.5.1 r9009. Still no podcast artwork. I'm connected to a 7.6 SBS, so will retry while connected to a 7.5.1 SBS and this 7.5.1 firmware.
Firmware 7.5.1 r9009 SBS 7.5.1 @r31258, then updated and retested with a fully updated 7.5.1. In both cases podcast artwork worked. If I take the same squeezebox Touch running 7.5.1 r9009 and connect it to a 7.6 SBS, the podcast artwork is gone. All signs point to this being newly broken in 7.6 SBS
Maybe I'm seeing something different. But in my case 7.5 wouldn't work neither. For me it looks as if the newmetadata event was ignored by SP. It does work sometimes, probably if the event is thrown before the NP screensaver kicks in. But once NP is playing it wouldn't update the artwork if it's url was added to the metadata later than the track information.
what I was describing might actually be what the other bug 16448 is about
I'm pretty sure the failure here is related to a negative value being sent for the cover id. This is a pretty visible regression. I'd elect this as a P1 must fix for 7.6.0
One thing I've found is that the cache for artwork is within an if($tags->{TITLE}) { } block. If there is no TITLE in the tags, the artwork doesn't get cached. My Music->Staff Picks->Ben's Picks->Podcasts->B.S. Report with Bill Simmons->Any stream: [11-04-07 15:07:52.1977] Data::Dump::dump (100) Warning: do { require MIME::Base64; { APIC => [ "image/jpeg", 0, "", MIME::Base64::decode("<clipped out huge chunk of superfluous-to-this bug data>"), ], COMMENT => [""], COVER_LENGTH => 48_251, TOWN => "de070ad0b08d90e45eda8604fa48007b", TRACKNUM => 0, }; } This is not all that's to the bug though, even when I remove that condition it does not show up on the NP screen. Further, streams that do have a TITLE tag have the same bug
More debug. This one is for NPR Hourly News Podcast. Artwork is found and reported to be cached, but then looking up the artwork (negative ID) results in "no artwork found" and falls back to default radio icon: [11-04-07 15:41:06.4786] Slim::Control::XMLBrowser::_cliQuery_done (715) Play an item (play). [11-04-07 15:41:06.4791] Slim::Control::XMLBrowser::_cliQuery_done (738) play http://podcastdownload.npr.org/anon.npr-podcasts/podcast/500005/135216416/npr_135216416.mp3 [11-04-07 15:41:06.4898] Slim::Utils::Scanner::Remote::scanURL (86) Scanning remote stream http://podcastdownload.npr.org/anon.npr-podcasts/podcast/500005/135216416/npr_135216416.mp3 [11-04-07 15:41:06.4906] Slim::Utils::Scanner::Remote::scanURL (202) Scanning remote URL http://podcastdownload.npr.org/anon.npr-podcasts/podcast/500005/135216416/npr_135216416.mp3 [11-04-07 15:41:06.7786] Slim::Utils::Scanner::Remote::handleRedirect (295) Server redirected to http://npr.vo.llnwd.net/kip0/_pxn=1+_pxI0=A9822+_pxL0=begin+_pxM0=+_pxR0=12596+_pxK=10412/anon.npr-podcasts/podcast/500005/135216416/npr_135216416.mp3 [11-04-07 15:41:07.0029] Slim::Utils::Scanner::Remote::readRemoteHeaders (338) Headers for http://npr.vo.llnwd.net/kip0/_pxn=1+_pxI0=A9822+_pxL0=begin+_pxM0=+_pxR0=12596+_pxK=10412/anon.npr-podcasts/podcast/500005/135216416/npr_135216416.mp3 are bless({ "accept-ranges" => "none", connection => "close", "content-length" => 2_433_443, "content-type" => "audio/mpeg", date => "Thu, 07 Apr 2011 20:41:06 GMT", etag => "\"8685bcf1e882e8fe77a706d90b9ad0c6\"", "last-modified" => "Thu, 07 Apr 2011 20:16:40 GMT", server => "Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-rhel5 mod_jk/1.2.26", }, "HTTP::Headers") [11-04-07 15:41:07.0037] Slim::Utils::Scanner::Remote::readRemoteHeaders (376) Content-type for http://npr.vo.llnwd.net/kip0/_pxn=1+_pxI0=A9822+_pxL0=begin+_pxM0=+_pxR0=12596+_pxK=10412/anon.npr-podcasts/podcast/500005/135216416/npr_135216416.mp3 detected as mp3 (audio/mpeg) [11-04-07 15:41:07.0041] Slim::Utils::Scanner::Remote::readRemoteHeaders (381) Updating content-type for http://podcastdownload.npr.org/anon.npr-podcasts/podcast/500005/135216416/npr_135216416.mp3 to mp3 [11-04-07 15:41:07.0052] Slim::Utils::Scanner::Remote::readRemoteHeaders (398) Updating redirected URL http://npr.vo.llnwd.net/kip0/_pxn=1+_pxI0=A9822+_pxL0=begin+_pxM0=+_pxR0=12596+_pxK=10412/anon.npr-podcasts/podcast/500005/135216416/npr_135216416.mp3 [11-04-07 15:41:07.0061] Slim::Utils::Scanner::Remote::readRemoteHeaders (421) This URL is an audio stream [mp3]: http://npr.vo.llnwd.net/kip0/_pxn=1+_pxI0=A9822+_pxL0=begin+_pxM0=+_pxR0=12596+_pxK=10412/anon.npr-podcasts/podcast/500005/135216416/npr_135216416.mp3 [11-04-07 15:41:07.0128] Slim::Utils::Scanner::Remote::readRemoteHeaders (537) Reading audio data in the background to detect bitrate and/or tags [11-04-07 15:41:07.0156] Slim::Utils::Scanner::Remote::streamAudioData (727) http://npr.vo.llnwd.net/kip0/_pxn=1+_pxI0=A9822+_pxL0=begin+_pxM0=+_pxR0=12596+_pxK=10412/anon.npr-podcasts/podcast/500005/135216416/npr_135216416.mp3 Buffering audio stream data to temp file /var/folders/dG/dGxVYI+lHviqVba86ogLME+++TM/-Tmp-/NBCLk9mNly [11-04-07 15:41:07.0162] Slim::Utils::Scanner::Remote::streamAudioData (748) ID3v2 tag detected, will read 49152 bytes [11-04-07 15:41:07.1788] Slim::Formats::MP3::scanBitrate (268) Read ID3 tags from stream: do { require MIME::Base64; { ALBUM => "110497: NPR News: 04-07-2011 4PM ET", APIC => [ "image/jpeg", 49, "10497: NPR News: 04-07-2011 4PM ET", MIME::Base64::decode("<clipped>"), ], ARTIST => "NPR", COMMENT => ["Comment: Stories: "], COVER_LENGTH => 28_658, GENRE => "Podcast", TCOP => 2011, TITLE => "110497: NPR News: 04-07-2011 4PM ET", TOPE => "NPR", TRACKNUM => 1, YEAR => 2011, }; } [11-04-07 15:41:07.2054] Slim::Formats::MP3::scanBitrate (296) Found embedded cover art, saving for http://npr.vo.llnwd.net/kip0/_pxn=1+_pxI0=A9822+_pxL0=begin+_pxM0=+_pxR0=12596+_pxK=10412/anon.npr-podcasts/podcast/500005/135216416/npr_135216416.mp3 [11-04-07 15:41:07.2057] Slim::Formats::MP3::scanBitrate (300) Scanned bitrate from stream: 64000 CBR [11-04-07 15:41:08.0725] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/-56449072/cover_180x180_m.jpg [11-04-07 15:41:08.0991] Slim::Web::Graphics::artworkRequest (122) Resize specification: 180x180_m.jpg [11-04-07 15:41:08.0995] Slim::Web::Graphics::artworkRequest (188) No cover found, translated to html/images/radio_180x180_m.png [11-04-07 15:41:08.1000] Slim::Web::Graphics::_cached (68) from cache: png (14154 bytes for html/images/radio_180x180_m.png)
I couldn't come to a conclusion on this bug. It's not clear how Slim::Utils::Cache is getting the negative ID in the first place, or why it's not showing up when I dump the $cache object. I've also tried using Slim::Utils::ArtworkCache but failed to understand how to put together the $data object it needs. The end of the debug in comment#8 pretty much sums up what the problem is: artwork gets cached, but then a few hundred ms later when it's tried to be recalled with a negative id, it fails to recall anything.
this is the schema of the tracks table. if id is an INTEGER PRIMARY KEY AUTOINCREMENT field, it seems wrong to be trying to save a negative number in that field, but that is what Slim::Schema::RemoteTrack::new() is trying to do sqlite> .schema tracks CREATE TABLE tracks ( id INTEGER PRIMARY KEY AUTOINCREMENT, ...etc. from Slim::Schema::RemoteTrack::new -- $self->init_accessor(_url => $url, id => -int($self), secs => 0, stash => {}); I don't see any error being thrown when this record is created, but I don't see it when querying the DB, nor does it follow that an AUTOINCREMENT field would allow a negative integer in its column. FYI, the code trace from finding artwork to attempting to save it to sqlite is Slim::Formats::MP3::scanBitrate -> Slim::Schema::RemoteTrack::updateOrCreate -> Slim::Schema::RemoteTrack::new Slim::Schema::RemoteTrack does return a valid object with a negative ID to Slim::Formats::MP3, but afaict this record is never actually stored in the database.
Was discussing the bug with Brandon today, and he posited: "at a glance, it looks like Slim::Schema::Track is database-backed, and RemoteTrack is just an LRU cache in memory with a similar API" So rather than do a database query for the cover in Web::Graphics for remote tracks (negative IDs), the thing to do is retrieve the analagous object from RemoteTrack: elsif ( $id =~ /^-\d+$/ ) { # XXX ID is a remote track my $obj = Slim::Schema::RemoteTrack->fetchById($id); Data::Dump::dump($obj); However, when I dump $obj, it does not have any information regarding the cover art: 11-05-25 18:19:54.9416] Data::Dump::dump (100) Warning: bless([ -54_972_944, 1, undef, undef, "http://cdn16.castfire.com/audio/303/2117/7141/599407/simmons_2011-05-19-171307-3953-0-1-0.32.mp3?cdn_id=33&uuid=766d9c47286c803a82b5e58b6d5d56c3&s=j1x3l", "mp3", 32_000, "4694.528", undef, undef, undef, undef, undef, "5/19: Charles Barkley", undef, undef, undef, undef, undef, 18_778_112, undef, undef, undef, undef, 0, undef, undef, undef, undef, undef, undef, undef, undef, undef, undef, undef, undef, undef, undef, undef, undef, undef, 0, undef, undef, undef, undef, {}, ], "Slim::Schema::RemoteTrack") I think this is getting closer though...
This code retrieves embedded artwork from the cache: my $remoteTrack = Slim::Schema::RemoteTrack->fetchById($id); my $coverArtImage = $remoteTrack->coverArt(); $callback->( $client, $params, \$coverArtImage, @args ); return; Note: $coverArtImage contains raw image data (not a path). What is still missing with that approach is resizing of the image.
This seems to work for podcasts with embedded artwork: Index: Slim/Web/Graphics.pm =================================================================== --- Slim/Web/Graphics.pm (revision 32413) +++ Slim/Web/Graphics.pm (working copy) @@ -159,6 +159,23 @@ } elsif ( $id =~ /^-\d+$/ ) { # XXX ID is a remote track + print("*** id: $id\n"); + + my @arrSpec = split(',', $spec); + my ($width, $height, $mode, $bgcolor, $ext) = @arrSpec->[0] =~ /^(?:(\d+)x(\d+))?(?:_(\w))?(?:_([\da-fA-F]+))?(?:\.(\w+))?$/; + my $remoteTrack = Slim::Schema::RemoteTrack->fetchById($id); + my $coverArtImage = $remoteTrack->coverArt(); + if( $coverArtImage) { + require Slim::Utils::GDResizer; + my ($res, $for) = Slim::Utils::GDResizer->resize( + original => \$coverArtImage, + width => $width, + height => $height, + mode => $mode, + ); + $callback->( $client, $params, $res, @args ); + return; + } } else { # ID is the trackid, this is deprecated because
I added some debug to find out what was going on with Eastman when using Felix's patch. What I'm seeing is that Eastman is requesting the wrong id for the NP screen. Interestingly, I believe the 50x50 request, with the correct id, is from Eastman, to fill the Playlist panel. I can confirm that the playlist panel shows the correct thumbnail for the stream. Squeezeplay only: [11-05-26 14:15:49.4845] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/-89656692/cover_180x180_m.jpg [11-05-26 14:15:49.4991] Slim::Web::Graphics::artworkRequest (122) Resize specification: 180x180_m.jpg [11-05-26 14:15:49.4995] Slim::Web::Graphics::artworkRequest (162) *** id : -89656692 [11-05-26 14:15:49.4997] Slim::Web::Graphics::artworkRequest (163) *** client: 00:1b:63:96:cb:fe [11-05-26 14:15:49.5028] Slim::Utils::Misc::msg (1212) Warning: [14:15:49.5026] Resizing from 300x300 jpg @ to 180x180 [11-05-26 14:15:49.7638] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/-89656692/cover.jpg [11-05-26 14:15:49.7751] Slim::Web::Graphics::artworkRequest (122) Resize specification: .jpg [11-05-26 14:15:49.7756] Slim::Web::Graphics::artworkRequest (162) *** id : -89656692 [11-05-26 14:15:49.7759] Slim::Web::Graphics::artworkRequest (163) *** client: 00:1b:63:96:cb:fe [11-05-26 14:15:49.8161] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/-89656692/cover_50x50_o [11-05-26 14:15:49.8179] Slim::Web::Graphics::artworkRequest (122) Resize specification: 50x50_o [11-05-26 14:15:49.8182] Slim::Web::Graphics::artworkRequest (162) *** id : -89656692 [11-05-26 14:15:49.8407] Slim::Web::Graphics::artworkRequest (163) *** client: 00:1b:63:96:cb:fe [11-05-26 14:15:49.8461] Slim::Utils::Misc::msg (1212) Warning: [14:15:49.8459] Resizing from 300x300 jpg @ to 50xX Squeezeplay + Eastman (Eastman request at 600x600 comes in first, then Squeezeplay at 180x180 for Now Playing and 50x50 for : [11-05-26 14:16:42.9836] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/-88203624/cover_600x600_p.png [11-05-26 14:16:42.9841] Slim::Web::Graphics::artworkRequest (122) Resize specification: 600x600_p.png [11-05-26 14:16:42.9843] Slim::Web::Graphics::artworkRequest (162) *** id : -88203624 [11-05-26 14:16:42.9845] Slim::Web::Graphics::artworkRequest (163) *** client: 00:1b:63:96:cb:fe [11-05-26 14:16:42.9849] Slim::Web::Graphics::artworkRequest (212) No cover found, translated to html/images/radio_600x600_p.png [11-05-26 14:16:42.9856] Slim::Web::Graphics::_cached (68) from cache: png (69125 bytes for html/images/radio_600x600_p.png) [11-05-26 14:16:43.6266] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/-88203624/cover_180x180_m [11-05-26 14:16:43.8195] Slim::Web::Graphics::artworkRequest (122) Resize specification: 180x180_m [11-05-26 14:16:43.8199] Slim::Web::Graphics::artworkRequest (162) *** id : -88203624 [11-05-26 14:16:43.8202] Slim::Web::Graphics::artworkRequest (163) *** client: 00:1b:63:96:cb:fe [11-05-26 14:16:43.8207] Slim::Web::Graphics::artworkRequest (212) No cover found, translated to html/images/radio_180x180_m.png [11-05-26 14:16:43.8211] Slim::Web::Graphics::_cached (68) from cache: png (14154 bytes for html/images/radio_180x180_m.png) [11-05-26 14:16:44.3632] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/-55877424/cover_180x180_m.jpg [11-05-26 14:16:44.4194] Slim::Web::Graphics::artworkRequest (122) Resize specification: 180x180_m.jpg [11-05-26 14:16:44.4200] Slim::Web::Graphics::artworkRequest (162) *** id : -55877424 [11-05-26 14:16:44.4203] Slim::Web::Graphics::artworkRequest (163) *** client: 00:1b:63:96:cb:fe [11-05-26 14:16:44.4226] Slim::Utils::Misc::msg (1212) Warning: [14:16:44.4224] Resizing from 300x300 jpg @ to 180x180 [11-05-26 14:16:45.4725] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/-55877424/cover.jpg [11-05-26 14:16:45.4989] Slim::Web::Graphics::artworkRequest (122) Resize specification: .jpg [11-05-26 14:16:45.4992] Slim::Web::Graphics::artworkRequest (162) *** id : -55877424 [11-05-26 14:16:45.4995] Slim::Web::Graphics::artworkRequest (163) *** client: 00:1b:63:96:cb:fe [11-05-26 14:16:45.5865] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/-55877424/cover_50x50_o [11-05-26 14:16:45.5874] Slim::Web::Graphics::artworkRequest (122) Resize specification: 50x50_o [11-05-26 14:16:45.5878] Slim::Web::Graphics::artworkRequest (162) *** id : -55877424
A breakdown of what I saw in the Squeezeplay + Eastman combination: Squeezeplay + Eastman: The first request comes from Eastman. ID not correct, send generic artwork (which is oddly the CD not the radio icon): [11-05-26 14:16:42.9836] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/-88203624/cover_600x600_p.png [11-05-26 14:16:42.9841] Slim::Web::Graphics::artworkRequest (122) Resize specification: 600x600_p.png [11-05-26 14:16:42.9843] Slim::Web::Graphics::artworkRequest (162) *** id : -88203624 [11-05-26 14:16:42.9845] Slim::Web::Graphics::artworkRequest (163) *** client: 00:1b:63:96:cb:fe [11-05-26 14:16:42.9849] Slim::Web::Graphics::artworkRequest (212) No cover found, translated to html/images/radio_600x600_p.png [11-05-26 14:16:42.9856] Slim::Web::Graphics::_cached (68) from cache: png (69125 bytes for html/images/radio_600x600_p.png) The next request comes from Squeezeplay, also for the wrong ID. I do briefly see SP start with the placeholder artwork (in this case, the radio icon) [11-05-26 14:16:43.6266] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/-88203624/cover_180x180_m [11-05-26 14:16:43.8195] Slim::Web::Graphics::artworkRequest (122) Resize specification: 180x180_m [11-05-26 14:16:43.8199] Slim::Web::Graphics::artworkRequest (162) *** id : -88203624 [11-05-26 14:16:43.8202] Slim::Web::Graphics::artworkRequest (163) *** client: 00:1b:63:96:cb:fe [11-05-26 14:16:43.8207] Slim::Web::Graphics::artworkRequest (212) No cover found, translated to html/images/radio_180x180_m.png [11-05-26 14:16:43.8211] Slim::Web::Graphics::_cached (68) from cache: png (14154 bytes for html/images/radio_180x180_m.png) The following request from SP comes immediately following the previous request. This time the ID is correct and the resized image is sent back to SP, thanks to Felix's patch. Correct artwork loads on Squeezeplay: [11-05-26 14:16:44.3632] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/-55877424/cover_180x180_m.jpg [11-05-26 14:16:44.4194] Slim::Web::Graphics::artworkRequest (122) Resize specification: 180x180_m.jpg [11-05-26 14:16:44.4200] Slim::Web::Graphics::artworkRequest (162) *** id : -55877424 [11-05-26 14:16:44.4203] Slim::Web::Graphics::artworkRequest (163) *** client: 00:1b:63:96:cb:fe [11-05-26 14:16:44.4226] Slim::Utils::Misc::msg (1212) Warning: [14:16:44.4224] Resizing from 300x300 jpg @ to 180x180 Finally there are two requests for 50x50 artwork, with the correct ID. These must be from Eastman, as a) that's the icon size for playlists in Eastman and 40px is SP's, and b) the playlist panel shows the correct artwork. [11-05-26 14:16:45.4725] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/-55877424/cover.jpg [11-05-26 14:16:45.4989] Slim::Web::Graphics::artworkRequest (122) Resize specification: .jpg [11-05-26 14:16:45.4992] Slim::Web::Graphics::artworkRequest (162) *** id : -55877424 [11-05-26 14:16:45.4995] Slim::Web::Graphics::artworkRequest (163) *** client: 00:1b:63:96:cb:fe [11-05-26 14:16:45.5865] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/-55877424/cover_50x50_o [11-05-26 14:16:45.5874] Slim::Web::Graphics::artworkRequest (122) Resize specification: 50x50_o [11-05-26 14:16:45.5878] Slim::Web::Graphics::artworkRequest (162) *** id : -55877424 [11-05-26 14:16:45.5882] Slim::Web::Graphics::artworkRequest (163) *** client: 00:1b:63:96:cb:fe [11-05-26 14:16:45.5909] Slim::Utils::Misc::msg (1212) Warning: [14:16:45.5906] Resizing from 300x300 jpg @ to 50xX
== Auto-comment from SVN commit #32474 to the slim repo by bklaas == == http://svn.slimdevices.com/slim?view=revision&revision=32474 == Bug: 16491 Description: handle negative ID request for artwork, including resizing
I checked in Felix's patch, as I think it's sane and does the correct thing for any negative ID request. What remains to be fixed is the Eastman case, but judging from my debug from comment#15, it's Eastman that's requesting the wrong thing (yet it does the right request for the playlist panel) Michael, can you take a stab at this part? Maybe a NP artwork request needs to be triggered at the same time of the playlist panel refresh?
== Auto-comment from SVN commit #8470 to the player repo by mherger == == http://svn.slimdevices.com/player?view=revision&revision=8470 == Fixed Bug: 16491 Description: a playlist item's artwork_url can be relative. We need to make it an absolute link, as Eastman is not loaded from the server.
== Auto-comment from SVN commit #8471 to the player repo by mherger == == http://svn.slimdevices.com/player?view=revision&revision=8471 == Fixed Bug: 16491 Description: backport artwork fix to Eastman 1.1