Release 0.19

[KennethNielsen]

Summary

Previous release: 0.18 (#666)
Release notes: #674
Milestone: 0.19
Feature Freeze: evening of January 2nd, 2019 (see #581)
Release date: January 16th, 2020

As something new this release I would like to ask for nominations for PR's or bugs to be in this release. There is simply to many PR's to do all of them, so I want to make sure I start with those that have active interest. Write your nominations below, one PR/issue nomination per comment and upvote the ones that you care about if they have already been nominated.

I will then add them to the milestone.

[maru-sama]

Hello, can you please add #589 to the new release?
It was planned for 0.18 and before but actually got lost I think.

[KennethNielsen]

@maru-sama I've added it to the release milestone. The reason it ended up not being added, in spite of being such a small change, was that the patch no longer applies cleanly after all the event code changed. So it will have to be done from scratch, but it isn't that large a change so I will try to get to it soon. Will it be possibly for you to test an implementation in a PR?

[maru-sama]

This should not be a problem.

[relevitt]

Hi @KennethNielsen. Please add #680 to the new release. It's a fix for a bug found by @maru-sama. On some systems, temp_sock.connect() fails unless a valid port is provided. We therefore use config.EVENT_LISTENER_PORT, instead of port 0.

[KennethNielsen]

@relevitt already merged. I'm considering doing a bug fix release for it, depending on how many it is likely to affect. But let's have that discussion in the PR.

[tagdara]

0.19 still has the standing issue that protocolInfo is not included by all services, especially but not exclusively when Amazon when used in conjunction with Alexa. This started with the October 2017 Sonos update that enabled Alexa support.

The check for protocolInfo is in two places - at line 174 and 205 of data_structures, and appears to be purely legacy and academic. Simply commenting out both of these sections makes everything work.

You can search on the code for protocolInfo (and protocol_info) and see in a few cases is being DUMMY'd out or being faked, but almost never read or legitimately used.

[KennethNielsen]

SoCo 0.19 is a little late, but for once not out of real life getting busy but pure forgetfulness. I will try to wrap up 0.19 and make feature freeze today, so there is still the rest of the holidays for testing.

[KennethNielsen]

@tagdara I'm sorry that this has been a problem for so long, but please understand that the issue is not quite a simple as you lay it out. The two other parts to this issue is that:

1. Sonos isn't playing ball. Sonos does not document how the communication with their units take place. Having to reverse engineer everything is messy and error prone. (If you are feeling adventurous I would recommend having a look at the early history of the project ;)). Luckily, it seems that Sonos is using two standard pieces of technology (UPnP and DIDL-Lite) for the communication with the speakers which means that we can look for help in the specification of those technologies for help. Which brings us to the second point.
2. Maintainability: Since Sonos is doing a very poor job and ensuring that their supported music services implement the specification correctly, we get a lot of issues with non-spec compliant data structures coming in. The problem then is, that we still want to be able to look to the specifications for help if there are things we don't understand and that possibility will be diminished if we add hacky exceptions (in the main data structure implementation) for all the ways the different music services violate the specs. This has an adverse effect on the maintainability of the project, which I'm sorry to say, for me has higher priority than everything else.

So just to clear that point up: The check for protocol info isn't there for academic or legacy reasons, but because it is in the spec.

The fundamental problem then is: How can we keep a data structure implementation that follows the spec to the letter, and still make exceptions for the unlucky users of the slopy music services.

Until about a month ago I didn't have a decent solution for that, which is why I have been reluctant to add these hacks. But now I do, so let me see if I can add a fix to the problem you mention before feature freeze. I hope you have a little time over the holidays to test.

[KennethNielsen]

@tagdara please review #698 and test if that solves the problem for you

[KennethNielsen]

I've edited the dates of the original post for feature freeze today.

[KennethNielsen]

Version 0.19 is new feature frozen. Lot's of new features in there (have a look at the release notes thread #674 or the git change log for details v0.18...master for details). There are now 2 weeks for testing. I hope someone has a little time to spare to help wit the testing. In order to release we need:

• Unit tests on a Python 3 (as many versions as we can get 3.4 and up)
• Integration tests (those are the ones that require a speaker to test functionality all the way up to and including the actual unit) on a Python 3 (as many versions as we can get)
• Unit tests on Python 2.7 (for the last time)
• Integration tests on Python 2.7

Additionally it would be great with as much testing on new functionality:

• New functionality about listing and deleting music library shares was added
• Methods were added to setting relative volume and changing group volume
• Due to Copy metadata from DidlItem to MusicServiceItem in get_queue and events #589 and Beginning of data structure quirks, fix for missing protocolInfo #698 it would be great to get thorough testing of getting data structure out of the queue, fro events (and possible for being thorough) for getting them out of the music library.
• Python 3.8 support which it would also be great to have tested

[KennethNielsen]

I've branched of for SoCo 0.19 in order to be able to continue development, so all testing should now happen against the 0.19 branch

[nlagaros]

Will 0.19 be released soon?

[KennethNielsen]

@nlagaros I need help with testing. As soon as I get some indications that the unittests and integrations tests run on different environments and that the branch works for a few peoples use case it is out the door :)

[pwt]

All v0.19 unit and integration tests run successfully on:

• Python 3.9.0a4+ on Raspbian Buster
• Python 3.8.2+ on Raspbian Buster
• Python 3.7.7 on macOS 10.14.6
• Python 3.7.3 on Raspbian Buster
• Python 3.6.10+ on Raspbian Buster
• Python 3.5.9+ on Raspbian Buster
• Python 2.7.16 on Raspbian Buster

Integration tests are against Sonos version 11.0.

Notes:

• The version string needs a bump to __version__ = '0.19' in __init.py__
• The development documentation for testing [1] appears to be out of date. Instead, I'm running the combined unit and integration tests using py.test --ip <speaker_ip> soco .
• requirements-dev.txt doesn't install on Python 2.7, but one can install the minimally required packages for testing using pip install mock==1.0.1 pytest

[1] https://soco.readthedocs.io/en/latest/development/unittests.html

[KennethNielsen]

Version 0.19 is out. Thanks to all who contributed.

https://pypi.org/project/soco/0.19/
https://github.com/SoCo/SoCo/releases/tag/v0.19

🎆