erland wrote: > Now, people who have sniffed the network or looked in the server log > files from LMS with network debugging enabled knows how much traffic > there is continuously between the player and server when using the > system. What Logitech did with mysqueezebox.com is essentially to move > the server part to the cloud which means that all this network traffic > have to be handled by a central server with the result that you are > extremely dependent that the central server must be available for > scenario 2, so you aren't just dependent on an internet connection you > are also extremely dependent on the cloud server itself. This is what > you get with a slim device when you move the server part to the cloud, > basically a system which is extremely dependent on a cloud server being > up.
Now that's a little confusing if not wrong here. Please define "the server part". As long as you're using (and that's what you're talking about wrt. to looking at logs), "the server part" is not moved to mysb.com. What is there is content aggregation for music services. LMS is reaching out to mysb.com to eg. get the data to build the menus for your favorite music service. But all the player control still happens in LMS. It receives that OPML data and creates SlimBrowse menu for your devices. Yes, you are dependant on mysb.com to use most of the music services. But not because you lose control over your device, but because you lose access to the music service's API. erland wrote: > As long as you can keep the cloud server up, it's not a problem, but > let's just say that it's a lot easier to operate a cloud server which > responds to 2 messages per minute from each device compared to one that > have to respond to 200 messages per minute from each device. I'm not > sure about the exact numbers here but generally a solution with slim > devices requires a lot more network traffic than a solution with > thick/rich devices. I don't know where you got those numbers or even that impression. LMS will talk to mysb.com to get information (title, album, artwork) about the next track to be played and (depending on the music service) report successful playback after some time. But while listening (not navigating), there's not much more relevant traffic than this. There is some other information exchange which is mostly irrelevant to the player's operation, like prefs synchroniation (optional). But you won't miss it when mysb.com was to go away. erland wrote: > I'm not going to go into any details how we have solved it but let's > just say that we have learned a bit from Logitech's mistakes and we > don't plan to repeat them, What? You think using perl was a mistake? :-P It'll be interesting to see what you're going to win over mysb.com for the SB user. Unless you modify the player's firmware to move more of the player control to the device instead of the server there's not much room for improvement imho. It's a limitation of this device which we should have fixed long ago. ------------------------------------------------------------------------ mherger's Profile: http://forums.slimdevices.com/member.php?userid=50 View this thread: http://forums.slimdevices.com/showthread.php?t=98467 _______________________________________________ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
