At this point I think you need the architectural model of the squeezebox system, I think it will make things go a lot smoother for you.
There are three components in a squeezebox system: player, server and controller. Each of these is connected via a network. Think of the player part as black box, it gets audio samples streamed to it from the server. If the player has the capability to display images it can also have cover art streamed to it from the server. The player is a pure slave to the server, it plays the samples it is sent and displays what it is sent. The server is the heart of system, it connects to sources of audio samples (files on a hard drive, files on a NAS box over a network, stream over the internet etc) and sends them to players. A particular server can support many players and controllers. The server keeps a database on information about the "song files" it knows about. This database can be used to sort and search for music in many different ways. The data for this database usually comes from tags in music files. A controller controls the behavior of a player, but it does not talk directly to the player, it talks to the server on behalf of the player. The controller is used to specify what music out of the library to play, and when to play it (stop, start, volume etc). The controller also displays to the humans the status of what is playing etc. In general a controller can control one player at a time, but can be switched to controlling different players. Thus with one controller you can start playing music on playerA, then switch to controling playerB and start music playing on it. First lets go into into a little more details about servers. There are three types of servers: LMS on a computer, mysb.com and TinyLMS. LMS is a perl program that runs on your own PC. It can see music files on drives on the computer or over network shares from some other system. It can stream music to many players and receive commands from many controllers. It hosts a web page which is both control for the server itself (where music files are stored, when to scan the files to rebuild the database, what format to stream samples to the players etc) AND a controller. As with any controller you can choose what player is going to be controlled at any given time. Mysb.com is the "server in the cloud". Logitech maintains banks of computers in various parts of the world that contain many instances of a special version of the server. The primary reason for mysb.com is to provide audio data from the internet to players that are not connected to a local LMS, either because the you don't have any of your own files, or your computer is turned off but you still want to listen to internet radio. At this time mysb.com does not offer "cloud storage" for your own files, it is purely about streaming sources on the internet. Mysb.con also provides a web page which is a controller but it's a little different in that it can only control the player when it is connected to mysb.com. You can connect other controllers to mysb.com to control a player, you don't HAVE to use the web page controller (remember a controller is actually talking to the server on behalf of a player, not directly to a player). TinyLMS is a stripped down version of LMS that runs on the Touch hardware. Because of memory limitations it cannot host a web page. This causes a problem because the web page is how humans perform setup operations on the server. This made it difficult for the developers, they had to come up with a setup for the server that would work in all cases without any user setup options. Tiny LMS is also has other restrictions such as no plugins or transcoding (the Touch hardware does not have enough memory to support these) Controllers can either be in SB hardware or software running on other computers. Many people use controller apps that run on iPhones, Android phones, plugins to browsers, separate programs that run under various OSes etc. You can choose what server a controller is connected to (say your local LMS, mysb.com etc) and what player it is controlling. A particular player can actually be controlled by more than one controller at a time. For example you can control the player in a Touch with both the controller in its own box and with iPeng on an iPhone. Both controllers will get the same status from the server. If you try and push the stop button on one and the play button on the other at the same time, things can get rather interesting! Different hardware boxes have different implementations of these. The initial squeezeboxes (up through the SB, transporter and boom) have a player and some form of display and interface. They didn't really have a controller in the sense of the above architecture, The display, IR remote and buttons (if any) interfaced directly to the server, which created an instance of a controller for that player. The Duet contained a player box and separate handheld controller box. (the controller can control other SB players and the receiver can be controlled by other controllers). The Radio has both a player and a controller in one box. Most people don't do it but it is possible to control the player part from another controller, and you can use the controller part to control another player. The Touch contains all three parts in one box, server, controller and player. They are all independent pieces that just happen to share the same box. The Touch screen is connected to the controller NOT the player, so you can use the screen to control another player if you want. You can control the player from another controller. The server can send audio data to the player in the Touch and to other players. If you really wanted to you could have the player in the Touch connected to LMS on a different computer, the server in the Touch supplying audio to another squeezebox, the player in the Touch connected to the controller in another box and the controller in the Touch controling another player. Why you would want to do this I don't know, but the architecture does allow it! (I've actually tried this and it does work) I hope this overview of the architecture makes it a little easier to understand how the system works. John S. ------------------------------------------------------------------------ JohnSwenson's Profile: http://forums.slimdevices.com/member.php?userid=5974 View this thread: http://forums.slimdevices.com/showthread.php?t=95584 _______________________________________________ Touch mailing list Touch@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/touch
