Author Topic: SqueezeCenter for squeezebox  (Read 16110 times)

bulek

  • Administrator
  • wants to work for LinuxMCE
  • *****
  • Posts: 909
  • Living with LMCE
    • View Profile
Re: SqueezeCenter for squeezebox
« Reply #15 on: November 24, 2008, 09:23:02 pm »
Thanks guys! I tried doing what Caiman suggested and it worked just fine! Testing now to make sure all is ok... thanks for both your help!
Please post to Wiki if you already didn't....

Regards,

Bulek.
Thanks in advance,

regards,

Bulek.

colinjones

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 3003
    • View Profile
Re: SqueezeCenter for squeezebox
« Reply #16 on: November 24, 2008, 09:31:37 pm »
Don't worry, Bulek - I have every intention of updating the existing article to include this info... wonder if SqueezeCenter integration is currently in the 0810 branch? Thom are you listening? Is it?

tschak909

  • LinuxMCE God
  • ****
  • Posts: 5549
  • DOES work for LinuxMCE.
    • View Profile
Re: SqueezeCenter for squeezebox
« Reply #17 on: November 24, 2008, 09:32:50 pm »
it's not. Somebody needs to d o it.

-Thom

Zaerc

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 2256
  • Department of Redundancy Department.
    • View Profile
Re: SqueezeCenter for squeezebox
« Reply #18 on: November 25, 2008, 02:01:09 am »
Thanks Luke.

Let me paste here the commands I have put in to install the streamer for the benefit of others
Code: [Select]
dpkg -i --ignore-depends=slimserver /usr/pluto/deb-cache/pluto-slim-serverstreamer_2.0.0.44.0804112200_i386.deb

Now I have all three packages installed:
Code: [Select]
dcerouter_73xxx:~# dpkg -l | grep slim
ii  pluto-slim-server-streamer                 2.0.0.44.0804112200                  <insert up to 60 chars description>
ii  pluto-slimserver-plugin                    2.0.0.44.0804112200                  <insert up to 60 chars description>
rc  slimserver                                 6.5.4                                Streaming Audio Server
dcerouter_73943:~# dpkg -l | grep squeeze
ii  squeezecenter                              7.2.1                                Streaming Audio Server
So the dependency on "slimserver" should become a dependency on "squeezecenter", do I understand that correctly?
"Change is inevitable. Progress is optional."
-- Anonymous


caiman

  • Veteran
  • ***
  • Posts: 119
    • View Profile
Re: SqueezeCenter for squeezebox
« Reply #19 on: November 25, 2008, 09:39:35 am »
So the dependency on "slimserver" should become a dependency on "squeezecenter", do I understand that correctly?

as far as I understand, yes, that should be it.

felpouse

  • Veteran
  • ***
  • Posts: 99
    • View Profile
Re: SqueezeCenter for squeezebox
« Reply #20 on: November 25, 2008, 11:54:15 am »
Hi all,

the packages pluto-slim-server-streamer and pluto-slimserver-plugin should point from now to the new squeezecenter package for the dependencies and not to slimserver.

Best regards,

Luke

P.S.: for caiman and colin, did you try more times to do a power off and a power on and/or a reboot after the installation of the new package? Because few months ago I did it, and after a power on my new version was overwrited by the slimserver package.

colinjones

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 3003
    • View Profile
Re: SqueezeCenter for squeezebox
« Reply #21 on: November 25, 2008, 12:37:03 pm »
I did do a power off/on (but only once) and all seemed fine so far... I have noticed some feature limitations. For instance hitting Forward on the squeezebox in a play list just starts the same track again from the beginning. It would seem that the squeezebox would need to signal this back to squeezecenter, which in turn would need to send some kind of indication back through port 7890 to the DCE device, which presumably would need to send a message back to the media-plugin to process the play list position change (not sure this is how it works??) Haven't looked into it yet, but intend to telnet to port 7890 tomorrow and hit Forward to see if the squeezebox even sends anything that could trigger this process....

Also, internet radio streaming controlled through LCME doesn't work, but that isn't exactly surprising!

hari

  • Administrator
  • LinuxMCE God
  • *****
  • Posts: 2428
    • View Profile
    • ago control
Re: SqueezeCenter for squeezebox
« Reply #22 on: November 25, 2008, 06:51:40 pm »
iirc one of m1ch43l's friends was working on that.

br, Hari
rock your home - http://www.agocontrol.com home automation

Zaerc

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 2256
  • Department of Redundancy Department.
    • View Profile
Re: SqueezeCenter for squeezebox
« Reply #23 on: November 25, 2008, 07:37:25 pm »
So the dependency on "slimserver" should become a dependency on "squeezecenter", do I understand that correctly?

as far as I understand, yes, that should be it.

Hi all,

the packages pluto-slim-server-streamer and pluto-slimserver-plugin should point from now to the new squeezecenter package for the dependencies and not to slimserver.
...

I have changed the dependency for the pluto-slim-server-streamer package from "slimserver" to "squeezecenter", but pluto-slimserver-plugin never depended on "slimserver" to begin with. 

There is an updated package for pluto-slim-server-streamer available under the 0810 pre-alpha build now.

"Change is inevitable. Progress is optional."
-- Anonymous


colinjones

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 3003
    • View Profile
Re: SqueezeCenter for squeezebox
« Reply #24 on: November 25, 2008, 09:45:40 pm »
Just to update my previous post with some very basic findings.

When telnet'd into the CLI port, after issuing:

<MAC> client new
  and
listen 1

commands, the player reports everything the Squeezebox's user interface does. So when I hit Vol Up/Down or hit next track, it reports this back to the telnet session in detail. The main one that struck me as missing is that the media_plugin obviously only sends the current track in a playlist so the squeezebox doesn't see the whole play list, and is effectively playing just a single track until the end. Then presumably the Slimstreamer device receives the end of track message using the mechanism above, and media_plugin must then send the next track to be played. The upshot is that you cannot use the track forward/back on the player, it just restarts the same track again.

So at least in principle, the Slimstreamer device should be able to be extended to react to those track forward/back commands and respond appropriately. Same for keeping track of the volume level... So I guess the device must already be bidirectional to a point....

tschak909

  • LinuxMCE God
  • ****
  • Posts: 5549
  • DOES work for LinuxMCE.
    • View Profile
Re: SqueezeCenter for squeezebox
« Reply #25 on: November 26, 2008, 02:41:58 am »
Yes, we need to modify both the streamer and the plugin to handle events from the panel and the remote..but.. meh ;-)

It was intended to be used from the Orbiter, and in that respect, it works great.

-Thom

colinjones

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 3003
    • View Profile
Re: SqueezeCenter for squeezebox
« Reply #26 on: November 26, 2008, 03:11:06 am »
I guess I understand that the streamer is the actual DCE device that receives the commands to send a stream (via SqueezeCenter), etc. But could you explain, Thom, what the responsibilities of the plugin are, and how they differ from the responsibilities of the media_plugin?

Also, when the "streamer" commands the Squeezebox via the Squeezecenter to play a track, is the Squeezebox then simply finding the media itself on the shares and pulling it, or is the streamer actually sending the audio stream (presumably bypassing the sequeezecenter altogether for the actual audio data)?

tschak909

  • LinuxMCE God
  • ****
  • Posts: 5549
  • DOES work for LinuxMCE.
    • View Profile
Re: SqueezeCenter for squeezebox
« Reply #27 on: November 26, 2008, 05:02:18 am »
The media plugin in and of itself is a base class.

But to understand the differences between plugins and devices, we must examine first where they load:

* Devices load as processes, they open a socket to the dce router on the core, and can run anywhere. They are self contained in and of themselves, and must get information from other devices with DCERouter as proxy.

* Plugins, are also devices, but they load in the memory space of DCERouter. This is very important because of the way that C++ handles objects...

Because the plugins load in the same memory space, they have access to the public and protected structures (classes, methods, objects, etc.)

read that again.

What does this enable?

keep in mind there are other plugins besides your own:

* Climate Plugin--Handles the high level climate code
* Lighting Plugin--Handles the high level lighting code
...
* Datagrid Plugin--Handles maintaining, populating, and selectively returning what parts of a data grid to display.
* Orbiter Plugin--Handles the high level maintenance of orbiters
* Media Plugin--Handles the high level aspects of media control, pipes, the file list UI, finding which streams to create, etc..


all of the things i describe above are intentionally compartmentalized and abstracted.

These things provide the house wide logic that the rest of the system hangs off of.

Now, with this explained, I can get to the point:

The media plugin implements the MH commands, the media handler commands.

the media handler needs

* a location of some media, this can be anything, a URL, a path, some sort of uber-proprietary resource locator, something...
* a media type, is this..audio...video...dvd....game...tv...
* an entertainment area, or areas.

optionally,
* a device or device template to prefer.

and some other little bits, but not important for this discussion.

The media handler, goes into the media plugin... and there is a join table specifying player device templates for media types (MythTV Player mapped to media type 1, Xine Player mapped to Media type 5, etc.) DeviceTemplate_MediaType

...but how does this tie into the plugin? don't worry, I'm coming to task very quickly...

keep in mind that i said that plugins can reference data structures....

Devices use the Connect() method to enter into their code.... Plugins use a different entry point than Connect()... Register().....

(slight edit, I was typing too fast) ;-)

If you look in Xine_Plugin, look at the Register() method in Xine_Plugin.cpp... what do you see?  .... you see a reference into the media plugin, for registering a media connection to the media player..the Xine player... passing in a reference to the xine plugin itself.

This completes the circle...and creates the backbone of an extendable plugin system.

Now, the registered media plugins, also have a device priority devicedata, so you can specify certain media plugins to have precedence over others....

but..what does the Plugin itself do?

The plugin itself is responsible for creating a concrete form of the MediaStream class in a unique type (XineMediaStream, for example, for xine player streams)..which contains special properties for that stream... whether it contains audio, or video, etc... look at the mediastream class itself for details.

The plugin is also responsible for finding devices within an entertainment area capable of fulfilling the media handler command (Xine Plugin looks for all the xine player devices in the entertainment areas specified.)

Once we know this, we can figure out, for example:

* If we started the media stream on one machine, and it's the same machine, maybe we just need to pass a local file?
* If the source and destination machines are different, or multiple machines, this means we have to set up some plumbing to hook up the player devices, don't we?

Once we know all this, we can create the stream, figure out what we need to pass to the players, and craft CMD_Play_Media commands, for example, pointed to the player devices.

Now keep in mind, stream in this case, is a _VERY_ abstract term. You have to handle any stream management yourself, whether you do this in the plugin, or at the players, is up to you.. plugins run on the core, and have access to data structures that you may need... devices are nice and isolated on the media directors, or even running on the core itself (in the case of the squeezebox devices).....

Now, i haven't looked at the slim server streamer stuff yet, but.. this should give you an idea of what's going on behind the scenes...

but why is it this way?

very simple. It's an abstraction pattern.

This allows you to create different devices that may have different transport semantics, but are capable of handling similar data (or the flip flop of that can also be true.)..and be able to swap them out depending on the need...and furthermore, to be able to intelligently handle the same piece of media differently, depending on the device it's being beamed to.

I'm sure you see the power in it now, ;-)

-Thom
« Last Edit: November 29, 2008, 08:39:08 pm by tschak909 »

colinjones

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 3003
    • View Profile
Re: SqueezeCenter for squeezebox
« Reply #28 on: November 29, 2008, 08:02:29 pm »
holy crap, thom! I'm going on holidays today so I'm going to have to absorb this when I get back :) thanks for the detailed info tho! I've no doubt there will be more questions to come!

See you all in 3 weeks :)