Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 38
  1. #11
    Senior Member bluegaspode's Avatar
    Join Date
    Jul 2009
    Location
    Berlin, Germany
    Posts
    3,229
    Did you send at least one AUDG event to set the volume? Last thing SqueezeboxServer does when pausing the Squeezebox is sending volume 0. This needs to be reverted when starting a new song.

    As to the protocol: the Wiki is a good start, but truth is only in the SqueezePlay Sources (svn.slimdevices.com, jive repository, SlimProto.lua) and wireshark.
    Did you know: SqueezePlayer will stream all your music to your Android device. Take your music everywhere!
    Remote Control + Streaming to your iPad? Squeezebox + iPad = SqueezePad
    Want to see a Weather Forecast on your Radio/Touch/Controller ? => why not try my Weather Forecast Applet
    Want to use the Headphones with your Controller ? => why not try my Headphone Switcher Applet

  2. #12
    Junior Member
    Join Date
    Aug 2010
    Posts
    27
    Quote Originally Posted by bluegaspode View Post
    Did you send at least one AUDG event to set the volume? Last thing SqueezeboxServer does when pausing the Squeezebox is sending volume 0. This needs to be reverted when starting a new song.

    As to the protocol: the Wiki is a good start, but truth is only in the SqueezePlay Sources (svn.slimdevices.com, jive repository, SlimProto.lua) and wireshark.
    Thank you. Once I realized audg was required, and that the slimproto doc about it was lies from end to end (10 bytes long, hm?), things got better. Now I can hear my white noise, and even adjust the volume (though there's a weird delay between when I send the audg and when it takes effect, sometimes in excess of a second... going to have to figure that out.)

    The Wiki is not a good start, it's a lying piece of trash that cost me two days of coding in circles and pestering y'all. All that should be there is a link to the wireshark installation page, and a note apologizing for Logitech's inability to document their protocols.

    Anyway, thanks for the help. I don't doubt I'll be back with many more headscratchers, but when I'm done, if my code isn't too terribly specific to my own needs, I'll put it up somewhere (and it will be commented in great detail, which might save someone many, many hours).

  3. #13
    Perl Commando Dan Sully's Avatar
    Join Date
    Apr 2005
    Location
    Daly City, CA
    Posts
    2,865

    Help me write a custom SqueezeServer

    * ScottM shaped the electrons to say...

    >The Wiki is not a good start, it's a lying piece of trash that cost me
    >two days of coding in circles and pestering y'all. All that should be
    >there is a link to the wireshark installation page, and a note
    >apologizing for Logitech's inability to document their protocols.


    Before you go trashing it - recognize that for many years, Slim Devices was a
    small company, with not enough resources to work on things like public
    protocol documentation. Since being acquired by Logitech, in many ways, the
    Slim Devices team has become even smaller.

    I highly encourage you to scrap/rewrite/update the protocol document with
    your findings, especially since they are fresh in your mind.

    Thanks.

    --dan

    --------------------------------------------------------------
    <dsully> please describe web 2.0 to me in 2 sentences or less.
    <jwb> you make all the content. they keep all the revenue.

  4. #14
    Quote Originally Posted by Dan Sully View Post
    I highly encourage you to scrap/rewrite/update the protocol document with
    your findings, especially since they are fresh in your mind.
    I agree. I can't speak for the other "outsiders" who've chimed in here, but for myself, I rarely visit the wiki because I've become rather comfortable looking at existing code (often my own!) rather than the docs. So I haven't been much help maintaining the wiki. Please take a little time to clean up any errors you've found, in order to help others!
    owner of the stuff at https://tuxreborn.netlify.com/
    (which used to reside at www.tux.org/~peterw/)
    Note: The best way to reach me is email or PM, as I don't spend much time on the forums.
    Free plugins: AllQuiet Auto Dim/AutoDisplay BlankSaver ContextMenu DenonSerial
    FuzzyTime KidsPlay KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher
    SettingsManager SleepFade StatusFirst SyncOptions VolumeLock

  5. #15
    Junior Member
    Join Date
    Aug 2010
    Posts
    27
    Quote Originally Posted by peterw View Post
    I agree. I can't speak for the other "outsiders" who've chimed in here, but for myself, I rarely visit the wiki because I've become rather comfortable looking at existing code (often my own!) rather than the docs. So I haven't been much help maintaining the wiki. Please take a little time to clean up any errors you've found, in order to help others!
    At the risk of sounding like anyone's mommy or manager... the argument here is that the original and current team working on Squeeze code is tiny and doesn't have time to maintain documentation. Those are exactly the teams that need to focus the most, on good documentation and heavy commenting of the code. If you have six engineers, and two of them quit, you are very likely watching a third of the understanding about the product walk out the door. Filling that hole is hard, and while it is being filled, coding quality plummets. Public documentation is especially important, because with it you can lure volunteers and third parties to extend your product's abilities and integration with other products. There are open source projects out there with decent commenting and documentation, because they know they need it.

    I've had squeezeboxen since the early days of the product. I've done quite a bit of coding around them, and I will say that while the actual client software has always struck me as stable, the server has been a bit of a horror show. (Disclaimer: I run 6.5.4 and there are probably fixes for a lot of what I found, in later versions; I have reasons for not upgrading.) I've ended up coding around more and more problems over the years, and recently I hit the breaking point and decided if I want particular features and rock solid stability, I'm going to have to write it.

    I don't think I'm going to be updating the Wiki, as all that does is add my wild ass guesses and incomplete discoveries to the general mess, and even if the details I add are largely right, the effect of mixing good cheese and rotting cheese is that you end up with more rotting cheese. If the core developers don't commit to the documentation, the doc will never be worth anything. That's Logitech's loss; nothing says "we don't care about anything but sales, and quality be damned" like pervasively incorrect documentation.

    What I will do: if I get working code, it will be heavily commented, with explanations of what worked and what didn't and what I found. It's not the same as documentation, but for people that want to hack something working together, it might help. I'll check back here when I get to that point (probably not soon), to ask where people want the code posted.

  6. #16
    Senior Member
    Join Date
    Sep 2006
    Location
    Zurich, Switzerland
    Posts
    794
    Quote Originally Posted by ScottM View Post
    Since I'm frustrated, I'm going to mention the obvious: the documentation of the protocol (http://wiki.slimdevices.com/index.ph...otoTCPProtocol) is beyond a joke. Not simply out of date, but filled with mistakes, unanswered questions and ambiguities. As a document that carries Logitech's logo, it's an embarrassment. A formal description of the protocol is needed; if anyone knows of something better than that page, I'd be thankful.
    The wiki is a third-party collaboration tool. Just because it is hosted by Logitech does not mean that Logitech authors or is responsible for the content.

    No, there is no published formal description of the player protocol. Writing a server relies on an intimate knowledge of the quirks of how the player implements the protocol. The protocol is not versioned and relies on the players running the firmware version applicable to the specific version of Squeezebox Server being used. The player firmware source is unpublished, proprietary software.

    For example, with recent firmware, when the output underruns, the the player will automatically pause. It will not automatically unpause when the buffer is sufficiently full again.

    You suggested that the size of an AUDG packet is not 10 bytes. It is 10 bytes in the current (latest code), except when talking to SqueezePlay devices, and was 10 bytes in the 6.5 version from May 2006.

    Your best chance of deducing the implicit state machine associated with the players is to look at the state table in StreamingController.pm and the statHandler function in Squeezebox2.pm. The sequence and interrelationship between strm-s commands and STAT-STMc, STMl, STMd, STMn, STMo, STMu and DSCO is complex and critical.

  7. #17
    Junior Member
    Join Date
    Aug 2010
    Posts
    27
    Quote Originally Posted by awy View Post
    The wiki is a third-party collaboration tool. Just because it is hosted by Logitech does not mean that Logitech authors or is responsible for the content.

    No, there is no published formal description of the player protocol. ... The player firmware source is unpublished, proprietary software.
    It doesn't fall to me to tell Logitech how to run their business. But if any of those folk are reading, I'd suggest that full documentation is in their best interest - it encourages more uses for (and sales of) the hardware, gets them free testing of their software, and creates a loyal army of technically ept developers. Failing that, treat it as proprietary and don't host documentation at all. Leaving incorrect and incomplete documentation out there is the worst possible approach. It gives the impression that you're welcome to write your own software, and then makes it harder to do; and that makes them look incompetent.

    Quote Originally Posted by awy View Post
    You suggested that the size of an AUDG packet is not 10 bytes. It is 10 bytes in the current (latest code), except when talking to SqueezePlay devices, and was 10 bytes in the 6.5 version from May 2006.
    I'm testing against SoftSqueeze 3.7 at the moment (is that a SqueezePlay device?), since that corresponds to the 6.5.4 server I'm running. (I'm not brave enough to test my code against the actual hardware yet.) When talking to Soft 3.7, this succesfully sets the volume:

    unsigned char buffer[18] =
    {0, 0, 0, 0, 0, 0, 0, 0,
    1,
    0xff,
    //overwritten:
    0, 0, 0, 0,
    0, 0, 0, 0};
    uintTo4(buffer + 10, volLeft); //or right?
    uintTo4(buffer + 14, volRight);
    sendCmd("audg", buffer, sizeof buffer);

    So I'm sending 18 payload bytes, and the only part I vary is in bytes 10-17, where volLeft and volRight vary between 0 and 0x10000. It works, so in the version I have at least, it can't be a 10 byte message.

    I'm hoping that SoftSqueeze 3.7 corresponds roughly to SB Classic firmware 81, which is what I'm going to be sticking with.

    Quote Originally Posted by awy View Post
    Your best chance of deducing the implicit state machine associated with the players is to look at the state table in StreamingController.pm and the statHandler function in Squeezebox2.pm. The sequence and interrelationship between strm-s commands and STAT-STMc, STMl, STMd, STMn, STMo, STMu and DSCO is complex and critical.
    I'll give that a shot. So far I've got working happy-path code for the limited functionality I've attempted - play from a playlist of local files, with the ability to skip to Next and Prev. I suspect it will get more interesting as I add handling for things like STMn.

    I'm worried that handling music from internet sources is going to be some kind of special case; but it occurs to me that I can have my server pull music from internet sources, convert to PCM and stream that to the client just the way I stream everything else. Normally I'd reject approaches like that, because I'd rather keep the the complex conversions in the client, not the server. But given a choice between adding conversions to my server (I can find good documentation and working code for that), and discovering that slimproto has Undocumented Special Quirks when dealing with internet streams, and spending another few weeks reverse engineering them... yeah. I just talked myself into reading up on conversion software.

  8. #18
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,042
    Quote Originally Posted by ScottM View Post
    It doesn't fall to me to tell Logitech how to run their business. But if any of those folk are reading, I'd suggest that full documentation is in their best interest - it encourages more uses for (and sales of) the hardware, gets them free testing of their software, and creates a loyal army of technically ept developers.
    awy is a Logitech developer but you really want to say this to the management people and those aren't reading this forum and from what I've seen they haven't really realized the potential of third party development yet.

    By the way, I completely agree with you that it's usually both cheaper and more effective to have good documentation of important interfaces in a system than having to interpret it from the source code.

    Quote Originally Posted by ScottM View Post
    Failing that, treat it as proprietary and don't host documentation at all. Leaving incorrect and incomplete documentation out there is the worst possible approach. It gives the impression that you're welcome to write your own software, and then makes it harder to do; and that makes them look incompetent.
    All Logitech has done is to provide a free wiki service and a free forum which the community are free to use as they like. You should treat the content on the wiki as community maintained content and not Logitech maintained content, so if it isn't correct, blame the community not Logitech. And since you are part of this community we would love to get help creating a better description of the interface, either as a commented source code sample or as updated wiki documentation.
    Erland Isaksson (My homepage)
    Developer of many plugins/applets

  9. #19
    Junior Member
    Join Date
    Aug 2010
    Posts
    27
    Quote Originally Posted by erland View Post
    And since you are part of this community we would love to get help creating a better description of the interface, either as a commented source code sample or as updated wiki documentation.
    When I get my code working - and there's a fair way to go on that - I'll publish commented C++ code anywhere people like. As fair warning, it will be filled with comments like "This value seems to work with SB Classic firmware 81 and SoftSqueeze 3.7; no idea if it works anywhere else".

  10. #20
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,042
    Quote Originally Posted by ScottM View Post
    When I get my code working - and there's a fair way to go on that - I'll publish commented C++ code anywhere people like. As fair warning, it will be filled with comments like "This value seems to work with SB Classic firmware 81 and SoftSqueeze 3.7; no idea if it works anywhere else".
    Thanks, sounds great, I can recommend using Google Code to host the source code but any open source hosting service should work. When you have posted it somewhere, put a link on the SlimProto wiki page so future developers finds it and doesn't have to go through the same frustration as you have.
    Erland Isaksson (My homepage)
    Developer of many plugins/applets

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •