Fixes issue reported at https://discuss.mopidy.com/t/428.
Mopidy-HTTP-Kuechenradio includes a non-ASCII UTF-8 character in its
default config. If Mopidy didn't already have a config file, it crashed
when trying to create the initial config file based on the default
config of all available extensions.
Fixes case where we could have an empty album. We could alternatively be more
conservative and only limit to fully empty albums. But I think we only want
ones with names anyway.
This adds basic checks for the library provider lookup:
- Check that uri schemes are respected
- Check that blacklisting and globbing works
- Check uri successfully gets converted to a track
Allows us to debug cases where a "bad" extension is blocking the startup. In
there future we might also warning log extension that take longer than some
threshold to help find these cases.
Adds a new get_currents_tags method for fetching the full set of current tags.
There are still some untested cases for this, and I also suspect we still want
some API refinements one core starts using this.
Newer versions of the protocol have removed this tag, so we should as well.
This also works around the issue of #881 which was breaking things with
newlines in comment fields.
The readcomments command seems to replace this, but it seems to only care about
specific extra tagtypes, not the general comment tag we normally collect when
scanning things.
(cherry picked from commit 08a8d5c43b)
This was disabled together with a bunch of other changes without any
explanation in commit f24ca36e5a. I'm
guessing that this wasn't intentional, and no test covered the case.
(cherry picked from commit 4e508cd017)
This was added for #881, where the correct fix turned out to be to remove
comments from the responses. We should still add some sanity checks for
verifying that our responses at the very least only contain printable chars.
Newer versions of the protocol have removed this tag, so we should as well.
This also works around the issue of #881 which was breaking things with
newlines in comment fields.
The readcomments command seems to replace this, but it seems to only care about
specific extra tagtypes, not the general comment tag we normally collect when
scanning things.
This was disabled together with a bunch of other changes without any
explanation in commit f24ca36e5a. I'm
guessing that this wasn't intentional, and no test covered the case.
