Sonos plugin

Plugins & Plugin Development Sonos
761

Works well, thanks!

762

Nope… serving audio through the cgi-scipt did not remove the delay.

#!/usr/bin/haserl
<?
echo "Content-type: audio/mpeg"
echo "Content-disposition: attachment; filename=$FORM_filename"
echo "Content-Length: $FORM_length"
echo "Connection: close"
echo ""

if [[ -z $FORM_filename ]]; then
    echo "File not specified."
else
    if [[ -f "/www/$FORM_filename" ]]; then
            cat "/www/$FORM_filename"
    fi
fi
exit 0

I still think it is weird that the delay is there in lighthttpd… Keep-alive is pretty normal nowadays… why does this affect the sonos?

763

@hek,
Did you trace the packet response in this case? I’ve seen other [small] web servers that basically ignore any script-generated [tt]Connection:[/tt] headers, and maintain HTTP Keep-Alives none-the-less (at the server-level). I’ve also done the same myself, but on a slightly larger scale with corp load-balancers.

I wouldn’t [generally] want to switch this off, at the [tt]lighttpd[/tt] level, since it’ll impact all usages of the HTTP stuff… potentially giving people bad performance for everything else. Although as an experiment it should be fine.

Either way, it still just a theory, based upon observed packet data & timings. In my observation, the Socket connection was being kept open by [tt]lighttpd[/tt], and it wasn’t until it was closed (after a 5s timeout) that the Sonos began to play the (<4k) content it had received up front.

764

Data refresh in the Player tab is no more working >:(
Any code change in the javascript file on your side, guessed ?

765

I probably introduced the bug yesterday.
I will provide a fix later today

766

For the startup delay of TTS, do you think that concatening enough zero at the end of the file to make it big enough could be a solution?

767

I wondered about that, you’d have to experiment with different sizes to see what’s big enough to fill the buffer.

768

[quote=“lolodomo, post:764, topic:169644”]Data refresh in the Player tab is no more working >:(
Any code change in the javascript file on your side, guessed ?[/quote]
The only mod I’ve ever done in the JS was to add the drop down option for Russian.

769

[quote=“lolodomo, post:764, topic:169644”]Data refresh in the Player tab is no more working >:(
Any code change in the javascript file on your side, guessed ?[/quote]

I’m using an early release and it is not updating on mine either - just shows 'No Information"

Have you updated your Sonos to the latest software 3.8.4 release recently? (i did)
Could this have introduced something?

These are the notes for the 3.8.3 upgrade → Release notes for Sonos S2 | Sonos And they may have released a service pack after 3.8.3 - see here → http://forums.sonos.com/showthread.php?t=32587 - which would explain me being on 3.8.4

770

Using all the latest files from trunk, it’s working for me (at least it’s updating for Radio stations as well as MP3 from my fileserver). You may want to double check all of the download bits to ensure you’ve got revised versions of all of them.

Also, which specific part of the UI are you seeing the “No information” label in, since this might also make a difference. I sometimes have to force-refresh my browser to get the right bits picked up.

… and yes I have all the latest Sonos bits :wink:

771

Hi Guessed, “No Information” can be seen on all my Sonod dashboard devices. It look like it is related to grouping, even though looking at them on the Sonos ios App they all have something ‘playing’ they all show “No Info”

I’m a few releases behind the latest, so I’ll set some time aside to update to the latest one in the trunk.

772

Quick question: I would like to update my SONOS plugin. Is it just a matter of overwriting the existing files in Vera with those from the repository? OR do you have to delete your SONOS device first and recreate it after the file updates. Likewise if the device has to be deleted, what happens to any scenes that may refer to it - do they need updating as well? Basically I like this plugin and I don’t want to wreck it!!

773

Just upload the new files and reload.

774

New commit in trunk:

  • Data refresh bug fixed
  • After chossing a Web radio in the favorite list, the information now provides the station name

Sorry for the bug I created yesterday. That’s a chance I discovered it today.

775

On my side, I am in version 3.8.3. I noticed no impact to the plugin (I used version 3.8 before).

776

I just committed the change.

777

@lolodomo,
So we’ve got a fair amount of stuff in the Plugin now. You had a couple of items listed that you wanted to add:

http://forum.micasaverde.com/index.php/topic,8505.msg94031.html#msg94031

But I’m wondering if we should wait on those, and look to freeze/tag the codeline for a “first release” publication. The longer we wait for this, the more folks will need to “migrate” to the apps.mios.com version once we release it, which will cause it’s own set of deviceId headaches for anyone wanting to be auto-updated in future 8)

Thoughts?

PS: I still need your apps.mios.com Id and the corresponding EmailId in order to add you to the apps.mios.com auth’d list. Can you send me a PM with those details?

778

There is nothing in my TODO list that requires to wait.

If you confirm that the Pandora stuff is working well, there is no remaining problem I am aware.

But in my opinion, we have two subjects to conclude before the release:

  • a discussion about what keeping in the refresh loop (UPnP calls and variables) and what refreshing or not when saving the playback context

  • different investiguations not all closed about the Say stuff: start delay and proper ending. For the starting delay, I will check my idea if possible today. For the automatic stop, did you verify your idea with the metradata ?

779

I already removed the obsolete AV variables from the refresh loop, and the obsolete AV UPnP calls from the ACTION handler block.

So it’s paired back to a smaller set of standard ones now, although not all have been tested/trialled, but that shouldn’t be a problem.

I think you’re saving a reasonable amount of context for now, we can always add to it as needed in future.

Eg. Cross-Sonos state for multinode Say (etc)

The metadata to stop playback of HTTP content does stop it from repeating, but it doesn’t improve the delay-problem, which is what I was really looking to have it do. I didn’t consider it worthwhile as a release blocker (and to force retesting this area)… At least not until we have a more complete fix.

Pandora is working for me, but we can wait until we have the confirmation from another user.

780

[quote=“guessed, post:779, topic:169644”]I already removed the obsolete AV variables from the refresh loop, and the obsolete AV UPnP calls from the ACTION handler block.

So it’s paired back to a smaller set of standard ones now, although not all have been tested/trialled, but that shouldn’t be a problem.

I think you’re saving a reasonable amount of context for now, we can always add to it as needed in future.

Eg. Cross-Sonos state for multinode Say (etc)[/quote]

No, I was thinking about two other points:
1 - your message when you discovered that 1s was required to poll updated data and so if we could avoid do a full data refresh when using TTS
2 - my message relative to the really useful variables.
Next message will follow with a proposal.

The metadata to stop playback of HTTP content does stop it from repeating, but it doesn't improve the delay-problem, which is what I was really looking to have it do. I didn't consider it worthwhile as a release blocker (and to force retesting this area).... At least not until we have a more complete fix.

But why adding the code (metadata) to stop properly TTS ?
I imagine a call_delay will still be needed to restore the context ?