Bugzilla – Bug 17700
Browse Music Folder fails when there's a linked file
Last modified: 2011-12-23 07:15:33 UTC
We try to get an object for an undef url, resulting in nothing but a backtrace: [11-10-26 13:37:15.2780] Slim::Utils::OS::Win32::pathFromShortcut (593) Bad path in C:\Users\mherger\Music\00 - Kalimba.mp3 - Shortcut.lnk - path was: [] [11-10-26 13:37:15.2789] Slim::Schema::objectForUrl (812) Error: Null track request! Returning undef. [11-10-26 13:37:15.2811] Slim::Schema::objectForUrl (812) Backtrace: frame 0: Slim::Utils::Log::logBacktrace (C:/Users/mherger/workspace/7.7/server/Slim/Schema.pm line 812) frame 1: Slim::Schema::objectForUrl (C:/Users/mherger/workspace/7.7/server/Slim/Control/Queries.pm line 1690) frame 2: Slim::Control::Queries::mediafolderQuery (C:/Users/mherger/workspace/7.7/server/Slim/Control/Queries.pm line 1559) frame 3: Slim::Control::Queries::musicfolderQuery (C:/Users/mherger/workspace/7.7/server/Slim/Control/Request.pm line 1884) frame 4: (eval) (C:/Users/mherger/workspace/7.7/server/Slim/Control/Request.pm line 1884) frame 5: Slim::Control::Request::execute (C:/Users/mherger/workspace/7.7/server/Slim/Menu/BrowseLibrary.pm line 804) frame 6: Slim::Menu::BrowseLibrary::_generic (C:/Users/mherger/workspace/7.7/server/Slim/Menu/BrowseLibrary.pm line 1725) frame 7: Slim::Menu::BrowseLibrary::_bmf (C:/Users/mherger/workspace/7.7/server/Slim/Web/XMLBrowser.pm line 497) frame 8: Slim::Web::XMLBrowser::handleFeed (C:/Users/mherger/workspace/7.7/server/Slim/Web/XMLBrowser.pm line 55) frame 9: Slim::Web::XMLBrowser::handleWebIndex (C:/Users/mherger/workspace/7.7/server/Slim/Web/XMLBrowser.pm line 1149) frame 10: Slim::Web::XMLBrowser::_webLinkDone (C:/Users/mherger/workspace/7.7/server/Slim/Web/XMLBrowser.pm line 1221) frame 11: Slim::Web::XMLBrowser::webLink (C:/Users/mherger/workspace/7.7/server/Slim/Web/HTTP.pm line 1101) frame 12: Slim::Web::HTTP::generateHTTPResponse (C:/Users/mherger/workspace/7.7/server/Slim/Web/HTTP.pm line 924) frame 13: Slim::Web::HTTP::processURL (C:/Users/mherger/workspace/7.7/server/Slim/Web/HTTP.pm line 734) frame 14: Slim::Web::HTTP::processHTTP (C:/Users/mherger/workspace/7.7/server/Slim/Networking/IO/Select.pm line 139) frame 15: (eval) (C:/Users/mherger/workspace/7.7/server/Slim/Networking/IO/Select.pm line 123) frame 16: Slim::Networking::IO::Select::__ANON__ (C:/Users/mherger/workspace/7.7/server/Slim/Networking/IO/Select.pm line 184) frame 17: (eval) (C:/Users/mherger/workspace/7.7/server/Slim/Networking/IO/Select.pm line 184) frame 18: Slim::Networking::IO::Select::loop (slimserver.pl line 695) frame 19: main::idle (slimserver.pl line 645) frame 20: main::main (slimserver.pl line 1158) Additionally selecting an item _after_ this item would select the previous item. The index is getting one-off in this case.
*** Bug 17712 has been marked as a duplicate of this bug. ***
*** Bug 17793 has been marked as a duplicate of this bug. ***
Jörg - could you please get more information about the target folder that shortcut is pointing to? I see an issue where eg. the Windows' own Public music folder would cause invalid data in shortcut resolution: [11-12-23 07:30:02.8206] Slim::Utils::Misc::msg (1304) Warning: [07:30:02.8205] bless({ Arguments => "", Description => "", File => "C:\\Users\\mherger\\Music\\00 - Kalimba.mp3 - Shortcut.lnk", Hotkey => 0, IconLocation => "", IconNumber => 0, Path => "", ShortPath => "", ShowCmd => 1, WorkingDirectory => "C:\\Users\\Public\\Music\\Sample Music", ifile => 2_506_372, ilink => 2_506_356, }, "Win32::Shortcut") at C:/Users/mherger/workspace/7.7/server/Slim/Utils/OS/Win32.pm line 573. Other files which are not in that special folder seem to be fine: [11-12-23 07:30:29.4517] Slim::Utils::Misc::msg (1304) Warning: [07:30:29.4514] bless({ Arguments => "", Description => "", File => "C:\\Users\\mherger\\Music\\shortcut unc.lnk", Hotkey => 0, IconLocation => "", IconNumber => 0, Path => "\\\\192.168.0.80\\media\\Music\\ABBA\\GOLD (Greatest Hits)", ShortPath => "\\\\192.168.0.80\\media\\Music\\ABBA\\GOLD (Greatest Hits)", ShowCmd => 1, WorkingDirectory => "", ifile => 2_678_260, ilink => 2_678_244, }, "Win32::Shortcut") at C:/Users/mherger/workspace/7.7/server/Slim/Utils/OS/Win32.pm line 573. The first link doesn't return a Path (though the file is there), but only a WorkingDirectory instead.
Two issues to resolve here: - don't return invalid data if a problem occurs - why would the shortcut resolution fail in the first place The original issue I filed (index off) is due to our skipping an entry in the list, but potentially not skipping it at a later stage. I guess that issue seen by Jörg would be resolved if the link resolution did work. But we should still handle failure correctly.
OK, I'll get more info about the path. The one thing I see immediately: In the case we saw the link was not pointing to a file but to a folder.
Also: in our case here, it wasn't about wrong item counts, the item is there, it's about the item type being returned as "unknown", are you sure this is the same issue or should I file a new bug?
When using the Logitech Media Server web control (v7.7.1) to navigate the music folder, I have specific links that do nothing when I click upon them. These links are shortcuts to other folders. In my music folder, I arrange most music by having an artist folder, and under that, a folder for each album. For certain things, e.g. Christmas music, I have a separate folder with albums as folders in the Christmas folder. I also create shortcuts that link to other folder for the albums (e.g. I have an Over the Rhine Christmas album that is under /Over the Rhine/Snow Angels. I put a shortcut to the 'Snow Angels' folder in the /Christmas folder). I have no issue navigating the music folder directly on multiple squeezebox devices. However, when using the web control, I cannot navigate in the music folder through any of the shortcuts. I have the same issue with iPeng on my iphone when trying to navigate the music folder and click on an item that is a shortcut.
I can reproduce the type "unknown" issue under one condition: the target of the link is not readable. Eg. a password protected network share or an external, unplugged disk. Is iPeng expecting those items to be of a given set of types? Don't you have a fallback case for this kind of failure? BrowseLibrary is falling back to type = 'text', resulting in that non-clickable item you see in the web UI. blue - what kind of device are you using which would allow browsing of that folder? The index off is indeed a different issue, related to when the shortcut de-referencing fails.
blue - would the scanner find files in those sub-folders? Eg. are they available when browsing artists, but only unavailable when Browsing Folder? Where are the target folders located: same disk? Different disk? External media (eg. usb disk)? Network?
Jörg - please open a new bug for your issue. Further investigation showed that the issue I originally reported here is not limited to shortcuts, but is a more general issue in the "mediafolder" query. I'm sorry for the confusion.
I'm going to open a new bug for this issue, with more accurate description etc.