Sonos plugin

lolodomo · November 30, 2012, 8:27am

So what solution ?
Is there a parameter for wget to define a timeout ?

hek · November 30, 2012, 9:11am

wget --timeout=

Sets the timeout.

hek · November 30, 2012, 9:28pm

Found this tonight when browsing some other plugin code.

local stdout = io.popen("GetNetworkState.sh ip_wan")
veraAddress = stdout:read("*a")
stdout:close()

Maybe it’s better to use this vera script to get wan ip.

guessed · December 1, 2012, 5:58am

I’ve made the tweaks to use @hek’s call above to determine the IP Address of Vera, and replaced the original mechanism for “Say” to use the new file-based provider (that @lolodomo was testing)

This is now the default for everyone using trunk, so we can get some mileage/testing on it.

It also sounds like Google replaced the Voice with a WAY better quality one. I don’t remember that last time I played with it.

lolodomo · December 1, 2012, 9:47am

[quote=“guessed, post:684, topic:169644”]I’ve made the tweaks to use @hek’s call above to determine the IP Address of Vera, and replaced the original mechanism for “Say” to use the new file-based provider (that @lolodomo was testing)

This is now the default for everyone using trunk, so we can get some mileage/testing on it.[/quote]

I see that you use PARENT_DEVICE as part of the file name rather the IP address. Isn"t PARENT_DEVICE the same for all Sonos devices (0) ?

guessed · December 1, 2012, 2:38pm

We need something unique per Sonos unit to avoid file naming collisions across two or more units registered to the same Vera.

The original code use the IP address of Vera. If you have two Sonos devices, this is going to be the same value so that wouldn’t suffice.

The parent-id variable is really the deviceId of (each) Sonos device. ‘Parent’ is a misnomer here, but it stems from other code (weather, alarm, etc) where the device Id is the parent of others.

This value is unique per registered Sonos device. I also considered using the Sonos IP, MAC and name, but the deviceId is more immediate and doesn’t change during the lifetime of the device.

jduchon · December 1, 2012, 10:32pm

Hello,

Thank you for the bug corrections (station logo) and improvements (say function)!
However, I still have the Error 500 :

luup_log:38: Sonos: error UPnP_request: status=1 statusMsg=500 result=[ Error 500
No Reason
] <0x2c427680>

in my log every 15 sec.

Am I alone in this case?

MikeT · December 1, 2012, 10:37pm

No, same with me. Just for info I have a Play:5 and Connect in my system. Mega impressed by the work done by the A-Team so far, this plugin is looking awesome!

guessed · December 1, 2012, 11:03pm

Can you pull the latest L_Sonos1.lua from trunk, and replace the version you’re running? Once it’s run for a while (after the first few error occurrences) can you grab a copy of the error you’re seeing at that time?

I put in extra diagnostics, it’ll still fail but it’ll now tell us which action/service is failing in your environment.

For example, I get one of these per Sonos device (per restart and/or reboot), but then it stops. I have a Sonos Connect, and a Sonos Play5 that I’ve tested this with:
[hr]
[tt]01 12/01/12 14:54:40.847 luup_log:666: Sonos: error UPnP_request (Browse, urn:schemas-upnp-org:service:ContentDirectory:1): status=1 statusMsg=500 result=[<s:Envelope xmlns:s=“http://schemas.xmlsoap.org/soap/envelope/” s:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”><s:Body><s:Fault>s:ClientUPnPError701</s:Fault></s:Body></s:Envelope>] <0x2d873680>[/tt]
[hr]

jduchon · December 1, 2012, 11:24pm

I confirm the error is cyclic on my configuration (Connect + Play:3). Here is the new error message:

luup_log:38: Sonos: error UPnP_request (GetAudioInputAttributes, urn:schemas-upnp-org:service:AudioIn:1): status=1 statusMsg=500 result=[ Error 500
No Reason
] <0x2ce9b680>

MikeT · December 2, 2012, 8:37am

Thanks Guessed, did as you asked, but it seems that I am getting a similar error as you and it is happening twice on reboot and then stops (no repeats that I can spot):

First this one:

luup_log:220: Sonos: error UPnP_request (Browse, urn:schemas-upnp-org:service:ContentDirectory:1): status=1 statusMsg=500 result=[<s:Envelope xmlns:s=“http://schemas.xmlsoap.org/soap/envelope/” s:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”><s:Body><s:Fault>s:ClientUPnPError701</s:Fault></s:Body></s:Envelope>] LEAK this:479232 start:2592768 to 0x18b6000 <0x2f38d680>

Then this one:

luup_log:221: Sonos: error UPnP_request (Browse, urn:schemas-upnp-org:service:ContentDirectory:1): status=1 statusMsg=500 result=[<s:Envelope xmlns:s=“http://schemas.xmlsoap.org/soap/envelope/” s:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”><s:Body><s:Fault>s:ClientUPnPError701</s:Fault></s:Body></s:Envelope>] <0x2f58d680>

MikeT · December 2, 2012, 8:56am

Looking at my logs I see a lot of these entries (and as I don’t use TuneIn I am assuming this is related to the Sonos plugin?):

FileUtils::ReadURL 0/resp:403 size 1233 Capital London, 95.8 FM, London, UK | Free Internet Radio | TuneIn <0x2f38d680>

Perhaps related is that I don’t even seem able to browse the TuneIn website…not sure if it’s just me or something others are seeing too?

lolodomo · December 2, 2012, 9:15am

[quote=“jduchon, post:690, topic:169644”]I confirm the error is cyclic on my configuration (Connect + Play:3). Here is the new error message:

luup_log:38: Sonos: error UPnP_request (GetAudioInputAttributes, urn:schemas-upnp-org:service:AudioIn:1): status=1 statusMsg=500 result=[ Error 500
No Reason
] <0x2ce9b680>

[/quote]

@guessed: it is problable that this call fails for a Play:3 without audio input. By the way, we don’t use later the result of this call. So, I would propose to suppress it.

lolodomo · December 2, 2012, 9:18am

[quote=“MikeT, post:691, topic:169644”]Thanks Guessed, did as you asked, but it seems that I am getting a similar error as you and it is happening twice on reboot and then stops (no repeats that I can spot):

First this one:

luup_log:220: Sonos: error UPnP_request (Browse, urn:schemas-upnp-org:service:ContentDirectory:1): status=1 statusMsg=500 result=[<s:Envelope xmlns:s=“http://schemas.xmlsoap.org/soap/envelope/” s:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”><s:Body><s:Fault>s:ClientUPnPError701</s:Fault></s:Body></s:Envelope>] LEAK this:479232 start:2592768 to 0x18b6000 <0x2f38d680>

Then this one:

luup_log:221: Sonos: error UPnP_request (Browse, urn:schemas-upnp-org:service:ContentDirectory:1): status=1 statusMsg=500 result=[<s:Envelope xmlns:s=“http://schemas.xmlsoap.org/soap/envelope/” s:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”><s:Body><s:Fault>s:ClientUPnPError701</s:Fault></s:Body></s:Envelope>] <0x2f58d680>[/quote]

I think it is due to the first call to Browse “AI:” that seems to fail for several for you. Can you confirm that you have two Sonos units ? In this case, don’t worry about thiese 2 errors.

MikeT · December 2, 2012, 9:20am

Yep, I have two Sonos units.

lolodomo · December 2, 2012, 9:27am

[quote=“MikeT, post:692, topic:169644”]Looking at my logs I see a lot of these entries (and as I don’t use TuneIn I am assuming this is related to the Sonos plugin?):

FileUtils::ReadURL 0/resp:403 size 1233 Capital London, 95.8 FM, London, UK | Free Internet Radio | TuneIn <0x2f38d680>

Perhaps related is that I don’t even seem able to browse the TuneIn website…not sure if it’s just me or something others are seeing too?[/quote]

Same for me ! I cannot access the main page of the web site !
I hope we have not been banished !!!

lolodomo · December 2, 2012, 9:29am

So, don’t worry except if they occur every 15 seconds.

lolodomo · December 2, 2012, 9:32am

Here is the message I get when I open http://tunein.com in a web browser:

403 - Forbidden: Access is denied.

You do not have permission to view this directory or page using the credentials that you supplied.

guessed · December 2, 2012, 4:41pm

I’ve added some logic to [tt]I_Sonos1.xml[/tt] to “cache” the results of the call (successful, or non-successful) for 30 minutes. This will greatly cut down on the number of URL calls being made against TuneIn (1/120th # calls)

This change has been checked into trunk.

This cache operates per-device. If you have 2 Sonos devices, then you’ll see the calls 2x as often (assuming you’re listening to TuneIn Radio stations on both). In the cache, you’ll see one call every 30 mins that “goes through”, and then just the successive calls that are all getting cache hits. If the channel is changed, then you’ll see another call “go through”.

Hopefully the bans are done by a bot, and will go away once we slow the rate of calls down. The next step will be to eliminate [tt]luup.inet.wget[/tt] calls, converting them over to LuaSocket HTTP calls, and putting in all the logic to “look more like” they’re coming from a Sonos unit.

root@MiOS_30000666:/tmp/log/cmh# tail -f LuaUPnP.log | grep TuneIn 06 12/02/12 8:33:04.269 Device_Variable::m_szValue_set device: 331 service: urn:sonos-com:serviceId:Sonos1 variable: CurrentService was: now: TuneIn #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2e23d680> 35 12/02/12 8:33:04.295 luup_log:331: Sonos: debug getTuneInStationLogo: start <0x2e23d680> 35 12/02/12 8:33:04.666 luup_log:331: Sonos: debug getTuneInStationLogo: Successful call to Tunein, stationId =99476 <0x2e23d680> 06 12/02/12 8:33:04.691 Device_Variable::m_szValue_set device: 331 service: urn:upnp-org:serviceId:AVTransport variable: CurrentStatus was: Yo Te Vi (Ah Ya Zein) (Alabína, L'Essentiel) now: TuneIn: ABC Triple J: #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2e23d680> 35 12/02/12 8:33:19.222 luup_log:331: Sonos: debug getTuneInStationLogo: start <0x2e23d680> 35 12/02/12 8:33:34.257 luup_log:331: Sonos: debug getTuneInStationLogo: start <0x2e23d680> 35 12/02/12 8:33:49.219 luup_log:331: Sonos: debug getTuneInStationLogo: start <0x2e23d680> 35 12/02/12 8:34:04.252 luup_log:331: Sonos: debug getTuneInStationLogo: start <0x2e23d680> 35 12/02/12 8:34:19.228 luup_log:331: Sonos: debug getTuneInStationLogo: start <0x2e23d680>

[quote=“lolodomo, post:698, topic:169644”]Here is the message I get when I open http://tunein.com in a web browser:

403 - Forbidden: Access is denied.

You do not have permission to view this directory or page using the credentials that you supplied.[/quote]

guessed · December 2, 2012, 5:27pm

These error calls come from inside the library, and those shouldn’t be suppressed since they’re handy for diagnosing failed requests (etc).

You could do the same trick you did for the other call, where you call it, let it fail, and then detect that for future call-avoidance. Alternatively, if you could determine if we’re running against a Sonos3 then the call could be eliminated outright. So far I haven’t seen anything that reliably tells us we’re hitting a Sonos3 unit though.