Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 12 19:38
    leptoquark1 starred SoCo/SoCo
  • Dec 10 21:06
    mdietrichstein starred SoCo/SoCo
  • Dec 10 19:10
    chronikum starred SoCo/SoCo
  • Dec 06 09:59
    lourheroes starred SoCo/SoCo
  • Dec 03 00:13
    tekhead88 starred SoCo/SoCo
  • Dec 02 09:16
    pwt synchronize #694
  • Dec 02 02:17
    renaudguerin starred SoCo/SoCo
  • Nov 30 09:42
    pwt synchronize #688
  • Nov 30 01:22
    icanhazpython starred SoCo/SoCo
  • Nov 29 20:57
    pwt edited #688
  • Nov 29 20:56
    pwt edited #688
  • Nov 29 17:52
    pwt opened #694
  • Nov 29 13:52
    pwt synchronize #688
  • Nov 29 12:19
    pwt synchronize #688
  • Nov 29 12:14
    pwt synchronize #688
  • Nov 29 10:57

    KennethNielsen on master

    Adds the SoCo.set_relative_volu… (compare)

  • Nov 29 10:57
    KennethNielsen closed #687
  • Nov 29 09:53
    KennethNielsen closed #692
  • Nov 29 09:11
    pwt review_requested #687
  • Nov 29 09:02
    pwt synchronize #687
Kenneth Nielsen
@KennethNielsen
@stefankoegl I was watching this presentation by Hynek (attrs etc.) about basically lowering the overhead of maintaining a FOSS project. Basically system you can put in place to make sure that the time you spend on it is spent on the things that matter. One of the suggestions there was to make the use of a code formatter mandatory (by making one of the CI checks check that formatting the code doesn't introduce a change). The point of doing this, by his argument, was not as much to get that specific code style, but basically that all discussion about code style goes away from reviews. There was also some other suggestions there, like autogenerating the contributors list from git history etc. But I wanted to run the idea by you before I open the discussion in an issue.
I have been making use of black as a code formatter for at 8 kLOC project at work and I have to say that I really find it liberating
Stefan Kögl
@stefankoegl
I've been using black in other projects as well. I've even integrated it into the tests, so tests fail if the code is not properly formatted
so a definite +1 from me
Kenneth Nielsen
@KennethNielsen
Great. I will propose it then. Have a nice weekend.
Kenneth Nielsen
@KennethNielsen
@stefankoegl hi. Quick question. Do you know if the auto deploy fuctionality only tracks tags in master or in all branches. And if currently only master is it possible to make it do it for all branches. The reason is that it will make it easier to release bugfix releases, if I can do it in a "0.18" branch instead of from master.
Well, maybe not a quick question at all. Bad habit I picked up at work :$ prefixing everything with quick question
Stefan Kögl
@stefankoegl
In git tags do not belong to a branch
So whenever you create and push a tag, it will create and deploy a release
I think you can configure travis-ci to pattern-match the tag name, if you'd like to distinguish release-tags from non-release-tags
Kenneth Nielsen
@KennethNielsen
@stefankoegl ok, great, well I don't need the tags for anything else, so that's perfect
Michael Guntsche
@maru-sama
@KennethNielsen regarding bugfix releases, most likely because of the event issue that was just fixed, do you intend to use a micro number like 0.18.1? I am still wondering if SoCo should not be declared 1.xx since in my opinion it is already very stable.
Stefan Kögl
@stefankoegl
There was some discussion on switching to 1.0: SoCo/SoCo#316
If I remember correctly there was no real consensus back then
Michael Guntsche
@maru-sama
I think the situation did not change from back then a lot. The basic functionality is working and we know what isnt. I also doubt that there will be api breaking changes in the near future. So why not go ahead and call 0.19 1.0.0 instead and then go with a x.x.x versioning from then on?
Kenneth Nielsen
@KennethNielsen
We could. I think my argument from back then was that I really wanted to get music services in before calling it 1.0, but I have to admit that there has been no progress on that, so might as well continue without it
@maru-sama yes, I intend for the bugfix release to be 0.18.1, we have done that before but luckily they are rare
Kenneth Nielsen
@KennethNielsen
@stefankoegl regarding my comment above about version 1.0. I think I agree with you that it might as well be API stability. The only thing that I can think of that might need to be done is to remove some old that we have warned about deprecation of and there might be some things that should be removed like the old music service data structures and an old Spotify plugin
Kenneth Nielsen
@KennethNielsen
:fireworks: :fireworks: version 0.18.1 bugfix release is out
Michael Guntsche
@maru-sama
That fixes the event issue I was having thanks. In a side note. Spotify direct managed to do it again and botched the spec. The xml does not have the protocolinfo set BUT the text of the element contains it. Right now I have a hackish solution in data_structures.py namely checking the text and then manually setting the protocolInfo
if element.text and element.text.startswith("x-sonos"): content['protocol_info'] = "sonos.com-spotify:*:audio/x-spotify.*" else: raise DIDLMetadataError('Could not create Resource from Element: ' 'protocolInfo not found (required).')
Kenneth Nielsen
@KennethNielsen
@maru-sama wow that sounds incredibly ugly, no chance that they will fix it I guess?
Michael Guntsche
@maru-sama
Ok I suck ad using the markup but you get the idea I think
Kenneth Nielsen
@KennethNielsen
Not really, was looking for a squinting smiley ;)
Michael Guntsche
@maru-sama
Well they seem to break stuff on a quarterly base it seems.
Let me try and get a xml dump of that
Kenneth Nielsen
@KennethNielsen
In any case, if the code markup is too difficult, I can review it in a PR
Michael Guntsche
@maru-sama
Ok, so this is the xml that's returned
b'<res xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" duration="0:03:01">x-sonos-spotify:spotify:track:3sfLdQneX6bJ4IokTpibMf?sid=9&amp;flags=0&amp;sn=9</res>' b'<res xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" />' b'<res xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" duration="0:03:01">x-sonos-spotify:spotify:track:3sfLdQneX6bJ4IokTpibMf?sid=9&amp;flags=0&amp;sn=9</res>'
So yes, why write a protocolInfo in there at all with spotify direct. This used to be different but a recent version apparently changed this.
and yes they are sending it twice.... no comment
Michael Guntsche
@maru-sama
And right now I cannot think of a better solution than parsing the text if the protocolInfo is missing, checking if it is sonos related and if yes, manually set protocolInfo. Do you have a better idea?
Kenneth Nielsen
@KennethNielsen
No. Not with my current understanding of the problem. I will be easier to see in context. Just make sure to mark these music service non-spec compliant hacks clearly with comments in the code (with an explanation of what the code was changed from an to) so it can be reverted later if the problem is fixed
Michael Guntsche
@maru-sama
I wonder if we should put these exceptions in a separate file to better track them and keep them separate from the rest of the code. On the other hand this might make it more complex
Kenneth Nielsen
@KennethNielsen
Yeah. I actually though about that. I remember reading once that for like graphics cards drivers in the Linux kernel they have files containing "Quirks", which provides the logic for exceptions to the expected behavior and it would be tempting to something like that. I do however see two problems with it. One is that I find i difficult to figure where in the structure to put it and the other challenge that even at this point it would be a pretty big task to try and track down the exceptions that are already there.
Actually now thinking about it. I think the way that I would do it, if I were to do it, would probably be to manipulate the XML before being parsed ... hmm ... that could work, not sure it is worth it... or maybe it is.
Will think a little more about the design of it on the bikecride home from work. I think if you are interested, it might be cool to try and do it for this problem. That will also pretty clearly show which music services are the sinners ;)
Kenneth Nielsen
@KennethNielsen

@maru-sama ok, the more I think about this the more I'm convinced it is an idea worth persuing :D What I would propose is something along the lines of this:

  • Create a data_structure_quirks module whose interface is just a single pure function apply_object_quirks (we could later do a apply_ressource_quirksas well)
  • In data_structures.DidlObject.from_element, as the very first thing pass element though that apply quirks function
  • Then in the apply quirks function, make some system to check which quirks should be applied. Like basically doing a text search for the service id of something in an text exported version of the element and then if it matches, call a specific internal that applies quirks for that service

What do you think?

Michael Guntsche
@maru-sama

So in the spotify direct case the following would happen.

  • Inside quirks call a function that checks for a missing protocolInfo
  • In the case it is missing call a fixup function which itself checks in the text if it is coming from spotify direct
  • If yes add the protocolInfo for spotify and return the element

We could also put logging in the function to inform the user if any quirks were applied. So if in the future sonos decides to fix this we can disable the quirk again.
Right now I think the worst thing that can happen is that we build this up just for this specific case and nothing else will use it, but on the other hand we keep the standard code clean and move all the special case handling to a separate module.

Kenneth Nielsen
@KennethNielsen
Oh. I think I would do it the other way around. Inside the quirks function, check whether the content is spotify direct, it if is call a function that does all corrections for spotify direct, like check for that missing item and fix it. That way you will end up with n+1 functions, where n is the number of music services that have broken implementations and a translation dictionary with service search term to correction function
Don't worry about adding this just for the one case. There are more already. Besides from that there is a PR for fixing Alexa which is huge. I don't know whether that service is still that broken, but if it is, even for that it would be worth it.
And yeah, logging is a good idea
I also have another idea which might help in bringing the data structure modules back closer to spec, so this will fit in nicely with some restructuring there
Kenneth Nielsen
@KennethNielsen
@DPH hi. It's been a while since I was active with SoCo, so I'm trying to touch base with everyone. Are you interested and have time to do a little bit of testing of various PR. I have very limited time, so if possible I would like to try and do more reviews and bug squashing.
David Harding
@DPH
Hi @KennethNielsen I can make some contribution but have less time than I used to. Feel free to ask, or I will spot changes and jump in where I can. Cheers David
Kenneth Nielsen
@KennethNielsen
@DPH ok, what I will do is tag you once in a while in PRs and ask if you can test and if you do not have time to spend on SoCo, just ignore it ;)
Kenneth Nielsen
@KennethNielsen
@stefankoegl I was considering updating the code example on the io pages, but they seem to contain a lot of html. Did you use some sort of tool to generate the html?
Stefan Kögl
@stefankoegl
@KennethNielsen I apparently created it using the "Automatic Page Generator", which has been discontinued since
maybe I can find the time during the weekend to re-create it with today's tools
Kenneth Nielsen
@KennethNielsen
@stefankoegl if you can, that would be great. I think the page content wise is good enough as it is except the code example. The code example is Python 2 only and I also don't think shows of the best parts of our API. I would, humbly, suggest the code example in the frontpage of read the docs