Good news and Bad news

JoeyD · February 5, 2015, 12:53am

The good news…there will be a bit of new, active development on the squeezebox plug-in!

The bad news…I will be doing a bit of new, active development of the Squeezebox plug-in.

I just about have what I need to get started:

[ul][li]Access to the latest code that was maintained by primarily garrettwp[/li]
[li]I have successfully installed the Logitech Media Server and the latest Squeezeplay binary so I can test[/li]
[li]I have a UI5 and a UI7 vera-lite for testing[/li]
[li]I have lolodomo’s blessing to re-use his TTS library (used in his Sonos / DLNA plugins) [/li]
[li]Ap15e has pointed me in the direction of the “SAD” wiki as a starting point for integrating TTS functions with the plug-in[/li][/ul]

Here are my plans for development:

[ol][li]Start with garrettwp’s last committed code, perform only minor tweaks and ensure proper operation on UI5 and UI7. Get that published to the app store as the new official Squeezebox app. Additional revisions will be based on that code-base.[/li]
[li]From there, build out native Text to Speech functionality. This will be based on the same library that Sonos / DLNA uses, to allow for the use of GOOGLE tts server, or a local OSX TTS server. (I don’t have a local OSX server, so that will remain untested…but should work providing I get GOOGLE to work.)[/li]
[li]TTS will be exposed as an action…probably of the child player devices, but not decided yet. I’m not familiar with how squeezebox does audio sync over multiple devices. Depending on how that works, that may dictate whether the “Say” action is exposed on the parent (server) device or on individual players.[/li]
[li]No other changes planned, but that could change, particularly for bug fixes.[/li][/ol]

I have no formal interest in Squeezebox…I’m a Sonos guy myself. But there have been requests for my SayTheWeather plug-in to interface with Squeezebox as a render target…and I’ve seen similar desires for formal TTS support here in the squeezebox forum, so I figured I’d give it a shot.

Right now I’m inquiring on how to gain control over (or get the redaction of) the current app available from the app store, which is out of date.

I have been able to successfully “test” Ap15e’s SAD functions on my local squeezebox. The primary limitation of that code (which prevents me from pretty much just “plugging that in” as a native function within the plug-in), is that Google’s TTS “api” only allows 100 characters to be processed. So there needs to be a mechanism with longer strings of text to break it into chunks, receive the multiple audio streams from google, and then stitch them together as one single audio file to be sent to be “played.”. That’s what lolodomo’s library does, so my job is primarily taking that resultant audio file and playing it as an “alert” to Squeezebox.

By “alert”, that means

Interrupting the currently playing audio (if any)
Playing the announcement
restoring the original audio.

Ap15e’s functions attempt to do this (“alert”), though I did run into a bug where if the current audio stream was “paused” (not playing), after the TTS statement, the audio stream started playing again.

So in short…much of the code is already laid out in front of me by other authors…I’ll just be trying to stitch it together.

konradwalsh · February 5, 2015, 10:20am

Thats sounds great…
I have Squeezelites - Raspberry PIs with Hifiberry amps running picoreplayer - running throughout my home.

I have found very little success in get the audio from Google TTS. The player sees the URL and plays it like any other… however, there is never any actual sound.

Anyway… I can do any testing you need … let me know if I can help…

Regarding pulling the old Squeezebox Plugin… I doubt you can… I think you’d be better off releasing your own called “Squeezebox Plugin 2015 with TTS”

system · February 5, 2015, 10:27am

Nice! Got a house full of Squeezeboxes and figuring out how to use them with my Vera EDGE. I’m quite new on the Vera platform but willing to test the plugin if needed.

Good luck and keep us posted!

system · February 5, 2015, 11:21am

I’ve been going the hifiberry route as well, they sound fantastic. I access it via Orange Squeeze on an Android tablet on the wall

One thing that has kept me away from Sonos is their lack of supporting 24 bit audio.

konradwalsh · February 5, 2015, 11:49am

I’ve been going the hifiberry route as well, they sound fantastic. I access it via Orange Squeeze on an Android tablet on the wall

One thing that has kept me away from Sonos is their lack of supporting 24 bit audio.[/quote]

they are

the best thing I have found is that I can power three PI’s with one 12v PSU and just join each one… its great… I will test a fourth as soon as it’s delivered

JoeyD · February 5, 2015, 1:27pm

Oh ye of little faith… I just received access to the plugin on the app-store.

It looks like someone (probably garrettwp) had already posted what’s known as “version 1.3” code to the store repository, but did not request official publication of it. Was probably in some stage of testing it.

Over the next couple days I’ll update the official plug-in with the latest code that garrettwp pointed me to, though I will make just a couple modifications:

Change in service name. A couple services were kicking out errors / warnings in the log due to the way they were named:

[ul][li]urn:upnp-org:serviceId:AVTransport[/li]
[li]urn:upnp-org:serviceId:RenderingControl[/li][/ul]

Basically, the number “1” needs to be appended to the end of those service names so that it is consistent with the service “type”. Updates to several plug-in files that reference that service will be made. As a consequence, if you have any scenes with custom luup code that reference the above service names, you’ll need to update them.

I’ll probably add an input on the main control for users to enter the IP address and port of their media server, so that you don’t need to go to the advanced tab to find it.

I will post the plug-in as “Version 2.0”, although again it will be largely just the version 1.3 code with the tweaks mentioned above.

I will build on the version 2.0 codebase to try and get TTS added.

konradwalsh · February 5, 2015, 1:29pm

Well done!

guessed · February 5, 2015, 4:13pm

Change in service name. A couple services were kicking out errors / warnings in the log due to the way they were named:

[ul][li]urn:upnp-org:serviceId:AVTransport[/li]
[li]urn:upnp-org:serviceId:RenderingControl[/li][/ul]

Basically, the number “1” needs to be appended to the end of those service names so that it is consistent with the service “type”. Updates to several plug-in files that reference that service will be made. As a consequence, if you have any scenes with custom luup code that reference the above service names, you’ll need to update them. [/quote]

Those are the correct UPnP AV ServiceId’s, they should not be changed in any manner. They’re also used by other AV Gear, and things like the Sonos. Their definition files, as part of the Plugin, may need special treatment due to the potential for naming collisions.

Basically, for control-points to be able to call those services, their names need to remain unchanged.

JoeyD · February 5, 2015, 4:58pm

[quote=“guessed, post:8, topic:185787”]Those are the correct UPnP AV ServiceId’s, they should not be changed in any manner. They’re also used by other AV Gear, and things like the Sonos. Their definition files, as part of the Plugin, may need special treatment due to the potential for naming collisions.

Basically, for control-points to be able to call those services, their names need to remain unchanged.[/quote]

Thanks, guessed…when I get a chance I’ll post the log errors related to these services. I’m not sure what special treatment would be needed provided that the definition and service file names are unique and don’t collide with other installed devices.

JoeyD · February 5, 2015, 7:00pm

@guessed,

Here are the log entries that are related to the two services in question. Note, I do also have Sonos running on this same box. (a UI5 VeraLite).

1 2/5/15 1:45:52 PM Device_LuaUPnP::CreateService 23 service type/url don't match for urn:upnp-org:serviceId:RenderingControl <0x2b02a000> 1 2/5/15 1:45:52 PM Device_LuaUPnP::CreateServices removing incomplete service from 23 <0x2b02a000> 1 2/5/15 1:45:52 PM Device_LuaUPnP::CreateService 23 service type/url don't match for urn:upnp-org:serviceId:AVTransport <0x2b02a000> 1 2/5/15 1:45:52 PM Device_LuaUPnP::CreateServices removing incomplete service from 23 <0x2b02a000>

If you are not familiar with Squeezebox plugin, these services are referenced in the “Player” devices, which are children of the parent “server” device. Device 23 is the player (child) device.

Taking a look specifically at the RenderingControl service as an example, the player device definition defines the service as follows:

<service> <serviceType>urn:schemas-upnp-org:service:RenderingControl:1</serviceType> <serviceId>urn:upnp-org:serviceId:RenderingControl</serviceId> <SCPDURL>S_RenderingControl1.xml</SCPDURL> </service>

As I mentioned earlier, I’m not sure what “special care” is required here? Thanks for your help with this!

Edit: S_RenderingControl1.xml is a file distributed with this plug-in

guessed · February 5, 2015, 7:24pm

Are you running the exact version that’s here:
/ – Squeezebox Plugin

or something that’s been modified when you get the errors?

Also, what errors are earlier in your log file, prior to the ones you’re showing?

EDIT: Removed comment about SCPD files… not enough coffee this morning…

guessed · February 5, 2015, 7:34pm

[quote=“guessed, post:11, topic:185787”]Are you running the exact version that’s here:
/ – Squeezebox Plugin

or something that’s been modified when you get the errors?

Also, what errors are earlier in your log file, prior to the ones you’re showing?

… and by any chance are you on UI7?

EDIT: Removed comment about SCPD files… not enough coffee this morning…[/quote]

JoeyD · February 5, 2015, 7:37pm

[quote=“guessed, post:11, topic:185787”]Are you running the exact version that’s here:
http://code.mios.com/trac/mios_squeezebox/browser[/quote]

99% sure it’s the exact version. But just to be sure, I will delete the current files, re-download and reinstall just to be 100% sure.

I’m running this on UI5.

Also, what errors are earlier in your log file, prior to the ones you're showing?

None. They are almost literally the first log entries after a luup restart. (Though I have not enabled verbose logging.)

Before progressing, I’ll reload the files just to be sure and then I’ll report back.

guessed · February 5, 2015, 7:41pm

Also triple-check your Vera to ensure you have no-other “RenderingControl” files on it… independent of what their filenames are.

That ServiceId is exposed via a number of plugins, as would be completely valid (and required) in standard UPnP… except, Vera doesn’t DO standard UPnP, and this can completely hose you if there are dups…

JoeyD · February 5, 2015, 8:28pm

Removed squeezebox devices, then deleted files, then re-uploaded files (after re-downloading them from code.mios.com), re-added the device.

Results are the same.

So then I’m thinking there is some kind of conflict with the Sonos plug-in.

Squeezebox has these files in its distribution, along with the service IDs:

S_AVTransport1.xml                 urn:upnp-org:serviceId:AVTransport
S_RenderingControl1.xml            urn:upnp-org:serviceId:RenderingControl
S_MediaNavigation1.xml             urn:micasaverde-com:serviceId:MediaNavigation1

Sonos references these service files:

S_SonosAVTransport1.xml           urn:upnp-org:serviceId:AVTransport
S_SonosRenderingControl1.xml      urn:upnp-org:serviceId:RenderingControl
S_MediaNavigation1.xml            urn:micasaverde-com:serviceId:MediaNavigation1

So the first “issue” I see is that Squeezebox is distributing an S_MediaNavigation1.xml file as part of its distribution. Is that a standard file on Vera and so should not be distributed? I don’t know if Sonos is distributing that file as well, or if it’s only referenced.
Edit: Sonos does not distribute that file, so I’m assuming neither should Squeezebox.

Second, we do indeed have two different service files utilizing the same serviceIDs, which if I’m understanding you correctly is likely the problem. So I guess the question is…what to do about it?

Edit: To confirm, I uninstalled the Sonos plug-in and the errors in the log did in fact disappear. So your original suspicion is correct: a naming collision…but I still don’t know what to do about it…other than to avoid installing multiple plug-ins that reference the same service ID with different service files.

guessed · February 5, 2015, 8:46pm

Long standing issue in MiOS…

Here’s the RNET version of that issue:
http://forum.micasaverde.com/index.php/topic,16200.msg124515.html#msg124515

Creating a “one stop fits all” version of these files is also not the answer. Per UPnP Spec, vendors are permitted to augment these [standard] ServiceId’s with their own vendor-specific extensions… and they do. If you attempt to create a one-size-fits-all version, then it’ll be the Union of all of these extensions… which becomes impractical to maintain, along with not being a clean representation of the Services that each UPnP [Device] actually implements.

Add it to the list of “If only MiOS fixed…” stuff

JoeyD · February 5, 2015, 11:21pm

Thanks, guessed.

I was just thinking that perhaps at least between the Sonos, Squeezebox and DLNA plug-ins we could standardize the service library…but then I suspect most users don’t have more than any one of those installed anyway. (I only had both installed for testing.)

The real issue is with any other 3rd party media rendering devices…certainly can see the use case of someone having either sonos/dlna/squeezebox plus something like a specific receiver. (Just like the RNET case you referred to.) As you mentioned…simply impractical to try and maintain.

The only other option would be to use a completely different service. Forget AVTransport and RenderingControl…create “SqueezboxTransport” and “SqueezeboxControl” control. I guess the risk there is with 3rd party apps / interfaces?

In the end I suppose I’ll just leave it as-is. so no different than Sonos / DLNA plugins in that respect.

guessed · February 5, 2015, 11:37pm

Yup, that’s what I’d do…

Changing the serviceId’s just to work around a MiOS bug will only cause other ripple effects.

For example, requests to “Please implement support for AV Device Types <A, B, C, D, E, F, G, H, I…>" x nnn Control Points”

vs…

requests to “Please implement support for Devices with the [std] UPnP ServiceId <X, Y>" x nnn Control Points”

It’s both funny and sad to watch that happen when a new Plugin new comes out… 8)

PS: I generate openHAB Item Bindings for the standard UPnP AV ServiceId’s, when found on MiOS Devices. If you tweak them to use non-standard names, then [theoretically] I’d need to change something to accommodate it… which is also impractical…