Bugzilla – Bug 17182
Favorites pointing to local items are no longer functional
Last modified: 2011-04-29 08:54:51 UTC
Adrian, I'm seeing any Favorite that points to local albums/artists/tracks are now failing to work in 7.6. I think it's due to a checkin you made in March Client side request and error: { --[[table: 0x17437180]] "favorites", "playlist", "play", "favorites_title:10000 Hz Legend", "favorites_type:audio", "favorites_url:db:album.titlesearch=10000%20HZ%20LEGEND", "isContextMenu:1", "item_id:e9745eaf.1", "type:audio", "useContextMenu:1", } 20110426 21:33:27.649 WARN net.comet - Comet.lua:888 Comet {Tunevault}: _response, /slim/request id=13 failed: request failed with error: Bad dispatch! server side error: [11-04-26 15:48:41.1753] Slim::Control::Request::execute (1926) Error: While trying to run function coderef [Slim::Plugin::Favorites::Plugin::cliBrowse]: [Can't call method "can" without a package or object reference at /home/bklaas/sbs/7.6/trunk/server/Slim/Music/Info.pm line 1128. line 1128 of Info.pm is in the isPlaylistUrl method, and corresponds to checkin r32130 made on March 19th 1117 sub isPlaylistURL { 1118 my $url = shift || return 0; 1119 1120 # XXX: This method is pretty wrong, it says every remote URL is a playlist 1121 # Bug 3484, We want rhapsody tracks to display the proper title format so they can't be 1122 # seen as a playlist which forces only the title to be displayed. 1123 return if $url =~ /^rhap.+wma$/; 1124 1125 if ($url =~ /^([a-zA-Z0-9\-]+):/) { 1126 1127 my $handler = Slim::Player::ProtocolHandlers->handlerForProtocol($1); 1128 if (defined($handler) && $handler->can('isPlaylistURL')) { 1129 return $handler->isPlaylistURL($url); 1130 } 1131 1132 if (Slim::Player::ProtocolHandlers->isValidHandler($1) && !isFileURL($url)) { 1133 return 1; 1134 } 1135 } 1136 1137 return 0; 1138 } can you suggest a fix?
== Auto-comment from SVN commit #32361 to the slim repo by adrian == == http://svn.slimdevices.com/slim?view=revision&revision=32361 == Bug: 17182 Description: protect against dumb response from S:P:ProtocolHandlers->handlerForProtocol - this can return 0 or 1 as well as package names
Ben - try r32361
thanks Adrian, that fixed it
Verified on r 32376