Bugzilla – Bug 8766
Deleted MusicIP filters should not be used anymore by SC
Last modified: 2009-07-31 10:24:54 UTC
Deleting a MusicIP filter selected in the plugin's settings will lead to always empty playlists. Steps to reproduce : 1. Create a new filter in MusicIP and save library cache 2. Select this filter in MusicIP plugin settings 3. Delete the filter from MusicIP and save library cache 4. Ask for a MusicIP mix now : it's always empty list returned If you try the URL that SC uses to ask the mix to MusicIP, it'll point to a "MusicIP API error - invalid request or internal error." error page, which is not very helpful. This problem has been driving me crazy, while trying to help another MusicIP user in these forums. The user was running Windows, but I was able to reproduce the problem with MacOS, so I think this is an OS independent problem. I'm not sure how SC gets the filter list from MusicIP, but could it be possible it checks the filter availability before asking MusicIP for the mix and either deselects the missing filter or warns the user in some way that the filter does not exist anymore ? Thanks. Sébastien
Would the filter disappear once SC has re-indexed the MIP data? This should happen within the delay defined in the MIP settings. Or after a manual scan.
I don't think so, Michael, the user still had the problem after several manual library rescans (even a full one), and SC / MusicIP restarts (which didn't help). I'll give it a try, though.
No joy after a manual library rescan. Here's another weird behaviour : as soon as the filter is deleted from MusicIP, the drop-down Filter list in the plugin's settings shows "(None)" (I had no other filter created in MusicIP), but unless you hit the Apply button (without changing anything in the plugin's settings), SC will still ask MusicIP for a mix using the deleted filter. Simply hitting the "Apply" button will solve the problem (correctly reverting back to no MusicIP filter). Since MusicIP settings can also be tied to a specific player, this is a real pain to solve these problems ...
Filter's aren't part of the export file from MIP. I think they're queried separately. Will have to investigate.
Few more tests show that this problem seems to only occur when there's only one filter created in MusicIP, it's selected within the MusicIP settings, and then deleted from MusicIP. When multiple MusicIP filters are defined, deleting the one that's used by the plugin will cause SC to (randomly?) use another one or none. In this case, MusicIP mixes are still working, but probably not in the way the user intended them to. I think SC should fail over to not using any filter at all when this happens.
the filters should be getting requested on startup. however, once selected, are stored as a pref. so much for reducing the amount of http queries.
As far as I can tell, SC is returned an error message from MIP ("MusicIP API error - invalid request or internal error."). Couldn't this trigger a filter check, if any selected in MIP settings on the SC side? Then, SC would be able to warn the user that the filter is gone on MIP side. A little bit more useful than "empty list" feedback, IMHO.
a connection error isn't necessarily something that should be used to assume a pref is no longer valid. This would ruin prefs even if musicip is only temporarily offline. An invalid return when looking for filters could be a valid trigger for clearing prefs, but we'd need to make that check when creating a mix as well as when the settings page is accessed. The user, having delted the filter, should not be surprised that the filter isn't working, but returning an empty mix is the wrong result. The fix should really be to ensure that we make a valid request. Ideally it would be nice if MusicIP simply returned an unfiltered result. I assume plugin.musicip debug log would show that there is no valid mix, or invalid params in the request.
Just asked MIP for explicit error messages : De : Sébastien PHÉLEP <seb@le-seb.org> Date : 17 juillet 2008 22:29:32 HAEC À : support@musicip.com Cc : michael@slimdevices.com Objet : MusicIP Mixer - Better feedback on error, please Hi, I've filed a bug at Slim Devices today (https://bugs-archive.lyrion.org/show_bug.cgi?id=8766) because SqueezeCenter users don't get proper feedback when they try to get a MusicIP mix using a filter that has been deleted from MIP. Could MusicIP Mixer feedback on such error be more explicit than "MusicIP API error - invalid request or internal error." ? Something as simple as "MusicIP API error - specified filter does not exist" would be really nice. SqueezeCenter could then decide what to try next accordingly (say : same request without any filter specification). Thanks. Sébastien
Sebastien - did you get any feedback from MIP?
Kind of. They answered my e-mail saying they'd pass it along to their engineers.
change 22603 (7.3): - fetch MusicIP filters asynchronously - fetch filters during plugin initialization & when settings page is loaded - remove filters from prefs when they've been removed from MusicIP This change does not yet handle the case where MusicIP is returning an empty playlist due to a missing filter. It only reduces the time such an invalid setting can survive... Should we launch a filter refresh whenever an empty playlist is returned and a filter is involved? Or should we pass the error message to the UI?
Got an answer from Wendell (MIP): "I've been hitting this issue myself with some projects I've been working on. The MyDJWeb api, which is similar, now has pretty robust error handling, and I'd like to get the same into the mixer api. For legacy reasons this is going to require a few more changes in the code base than you might expect, but it's a process which I've already started." This issue won't be fixed too soon, plus some users (me & others :-)) are always a bit behind with updates. We should find some workaround, even parsing the message for "error" seems better than nothing to me. I'll try to come up with something.
Passing the error to the UI makes sense. We could also put up the query that caused it and a bit of text to explain what might have gone wrong: "Check that MusicIP is active, and that any filters being used are available." However, with filters being async now, maybe it's worth triggering a recheck of filters and moods on an error as well. The prefs can stay, but if the user follows the response text and checks the filters, they'll get only the currently valid ones
> Passing the error to the UI makes sense. Ugly: the response (including error code etc.) isn't returned by our http query. It goes down to Slim/Formats/RemoteStream line 156: "return undef" :-(. Will talk to Andy about a way to get the response back.
change 22604 - when filters were involved in a failed query, refresh the filter list. At least on second try this would return a valid list, if the missing/wrong filter was the reason for the failure. Best we can get right now, I guess.
bug 9188 is about abusing our http stream handler for MIP. Replacing it with LWP::Simple or similar might help fix this issue.
change 22728 - add some more error handling when mix using filters is failing: remove filter from query and try again
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC