Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 38
  1. #21
    Junior Member
    Join Date
    Aug 2010
    Posts
    27
    I've made progress on this. It's not complete (in particular it's not tested against real hardware, only SoftSqueeze 3.7), and there are still issues to solve, but enough is done that it looks like it's going to be a success.

    Which leads to the question of whatever anyone else is interested in running it, and what features they might want. If you're willing to help test, this is when you make feature requests for me to consider. :-)

    The target supported hardware is classic Squeezebox only, rev 81; that probably won't change, because it's all I own.

    Anyone interested in trying it would have to be a programmer, because there is no web interface, and my CLI interface is custom (I'd argue "much improved", but I'm comparing against SqueezeServer 6.5.4).

    ---Features are:

    Small, fast, threaded C++. It runs in around 7M, though this will creep up for large music collections.

    Runs on Windows, but written to be reasonably easy to port to most other OSs. Should port nicely to low speed, low memory platforms like Shiva plugs, even for fairly large music collections; and it writes to disk only to store configuration info, so it is suitable for flash drives.

    Full Unicode support for the display, CLI, and for filenames. Changing the font requires some freeware tools, but is not hard. Song titles in Arabic? No problem. (Lexicographical sorting, though, will likely never be right for any language but English; and compound characters will likely never work perfectly.)

    File formats that I know work: flac, mp3, uncompressed wav, wav with mp3 compression. Anything the SB classic supports natively is easy to add.
    Internet streaming is supported for those types as well (Squeeze Network, not yet, perhaps never).

    Fast rescan (<4 seconds for 2500 songs), and you can be playing a song while it happens, so adding music doesn't interrupt the flow.

    Song selection is by individual song, by folder ("everything in this folder", with recursion), or by playlist (.m3u or.pls, with recursion.) Removing songs from playlists uses the same mechanisms.

    Song control is the usual - skip forward and back, restart song, jump to song, pause, shuffle.

    Support for the remote.

    CLI control over the display.

    High stability, and interfaces that stay backwards compatible forever.

    ---What is not supported, and isn't a goal:

    Plugins. (The goal is to give you everything via CLI; and the C++ source will be available if you want to add directly.)

    A web interface. I just don't like them. (You can build one via the CLI if you must have.)

    Fancy cataloging. You create whatever directory structure you like to hold you music, and you select your songs by navigating that directory structure. There's no song database. Song titles are filenames (which is why unicode support was a must-have).

    Scanning files for tags, durations, etc. I'd rather keep fast rescan.


    Comments welcome.

  2. #22
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,042
    Quote Originally Posted by ScottM View Post
    Which leads to the question of whatever anyone else is interested in running it, and what features they might want. If you're willing to help test, this is when you make feature requests for me to consider. :-)

    The target supported hardware is classic Squeezebox only, rev 81; that probably won't change, because it's all I own.

    Anyone interested in trying it would have to be a programmer, because there is no web interface, and my CLI interface is custom (I'd argue "much improved", but I'm comparing against SqueezeServer 6.5.4).
    To make it interesting to me it would also have to support:
    1. Newer Squeezebox models (Radio, Touch)
    -- at least as players
    -- it doesn't necessary have to support their controller interface but it has to be able to distribute the information about currently playing track to their Now Playing screen.
    -- I think they use JSON/cometd instead of SlimProto for the Now Playing screen communication so it might be quite different to what you've done so far.

    2. Playback synchronization (unless it's already supported)

    3. Linux and preferablly also OSX support

    4. Some way to add plugins for new streaming services not natively supported by MySB(Squeeze Network) or requiring more advanced authentication model, for example services like Rhapsody, Spotify, Pandora. I don't need the browsing part, but it has to be able to connect and play them based on a url specified via your CLI interface. It doesn't matter if it has to be recompiled to add a new service, but it has to have a design where it's easy to develop support for new music services in the future.

    It feels like all this will make it too different compared to your own needs, so I'm just mentioning in case you are interested in going into this direction, but in case you are interested let me know.
    Erland Isaksson (My homepage)
    Developer of many plugins/applets

  3. #23
    Junior Member
    Join Date
    Aug 2010
    Posts
    27
    Quote Originally Posted by erland View Post
    To make it interesting to me it would also have to support:
    1. Newer Squeezebox models (Radio, Touch)
    I'd have to have the actual hardware to test against, to pull this off. So this probably isn't going to happen, unless I get an extended loan of hardware from someone. Even then... I get the impression the protocol changes radically for newer hardware, and given the dearth of documentation on the protocol, I have to admit this is probably too many hours to donate for free.

    Quote Originally Posted by erland View Post
    2. Playback synchronization (unless it's already supported)
    Probably not hard to add. I'll consider this. I had no idea anyone actually used that feature.

    Quote Originally Posted by erland View Post
    3. Linux and preferablly also OSX support
    Very feasible; it's written with portability in mind, so the primitive operations (mutex, semaphore, etc) are wrapped in classes and easily swapped out. What I don't have is a linux development environment at home. (But I do have a spare EEEbox sitting around doing nothing, and maybe it's time I learned to install Linux.) At any rate I'll be providing source, and someone adept with Linux system calls and gcc could probably get it ported and running in a couple of hours, if that.

    Currently, with one client and a catalog of about 2800 songs, the server runs in about 7M when playing local files, 8M when streaming from the internet. A sheevaplug really ought to be possible - leading to the possibility of a music server which runs entirely on solar power.

    Quote Originally Posted by erland View Post
    4. Some way to add plugins for new streaming services not natively supported by MySB(Squeeze Network) or requiring more advanced authentication model, for example services like Rhapsody, Spotify, Pandora. I don't need the browsing part, but it has to be able to connect and play them based on a url specified via your CLI interface.
    Possible. Internally, there are separate subclasses for streaming local files, streaming open internet sources, streaming a generated sine wave, etc; and adding classes for "stream pandora" and so on might not be hard. It depends on what kind of authentication and stream encryption code I'd need to add, and if I can easily support it in C++.

  4. #24
    Senior Member
    Join Date
    Aug 2009
    Posts
    406
    Quote Originally Posted by ScottM View Post
    I'd have to have the actual hardware to test against, to pull this off. So this probably isn't going to happen, unless I get an extended loan of hardware from someone.
    Well, the main reason SqueezePlay exists i probably so that you could develop and debug support for that class of players.

  5. #25
    Junior Member
    Join Date
    Aug 2010
    Posts
    27
    Quote Originally Posted by alfista View Post
    Well, the main reason SqueezePlay exists i probably so that you could develop and debug support for that class of players.
    I'll look into it. But to date I've done all of my testing against SoftSqueeze 3.7, and run into a number of bugs in 3.7 that I'm pretty sure my actual SB Classic doesn't have (and 3.8 is worse). In some ways this is not a bad thing - my little server is now hardened against all sorts of client mishaps. But unless SqueezePlay is a perfect implementation of the actual clients, there's no way I'm going to claim I produced a valid server, just testing against SqueezePlay.

    In short, if folk really want this, they need to commit to be testers. Given how hard it was to get to where I am just against SoftSqueeze, making yet another large effort for free isn't in the cards, unless there are people willing to share the load. And they would have to be programmers as well, since they will be implementing their own CLI client (mine will be too custom to meaningfully share).

    So step right up. :-)

  6. #26
    Junior Member
    Join Date
    Aug 2010
    Posts
    27

    Help with display

    I've switched to testing against SoftSqueeze to testing against an actual SqueezeBox classic. No smoke has poured out yet, and I can get music to stream. But it turns out that display handling is different.

    In my implementation, I display everything, text and all, with the graphics command, grfe. (That may be a bad move.) grfe takes a "scroll" command in byte 2, which with softsqueeze I've been setting to space, since I don't want the SB to do any scrolling. In the actual hardware client, that doesn't work; the display stays blank. It seems to demand an L, R, D or U for a scroll command, and that makes a mess of things since I update the display for all sorts of things, frequently every few seconds with minor changes, and don't want it twitching on every update.

    Anyone know if it's possible to just specify the new bitmap to draw without any scrolling?

  7. #27
    Junior Member
    Join Date
    Aug 2010
    Posts
    27
    Never mind. The (undocumented, uncommented) command for this is 'c'. (Discovered in drawFrameBuf in Squeezebox2.pm).

  8. #28
    Senior Member sbp's Avatar
    Join Date
    Apr 2010
    Location
    Denmark
    Posts
    1,165
    Hi
    I will be happy to beta-test your squeezeserver. I don't have any programming skills, so I can't help with that, but I have a linux box (Voyage linux with squeezebox server running) and a duet receiver and controller.
    If I can be of any help just ask.

  9. #29
    Junior Member
    Join Date
    Aug 2010
    Posts
    27
    Quote Originally Posted by sbp View Post
    Hi
    I will be happy to beta-test your squeezeserver. I don't have any programming skills, so I can't help with that, but I have a linux box (Voyage linux with squeezebox server running) and a duet receiver and controller.
    If I can be of any help just ask.
    Appreciated. I don't know if my code will support a Duet, and it's likely that there have been protocol changes, and it won't. But I don't know that for certain, and when I port to linux you're certainly welcome to try. I'm still weeks from having something I think is good enough to hand out, though.

  10. #30
    Junior Member
    Join Date
    Aug 2010
    Posts
    27
    OK, I'm going slightly insane. I have working code that does pretty much everything I want (which is admittedly a subset of what other people would want). I'm at the neatening, tweaking and thinking about porting to Linux stage. Just one more major issue to crack... the font to be used on the SB Classic's display.

    I really, really want a font with good unicode support, so that people have a shot of displaying their Chinese or Arabic song titles. But I also want a font that's large enough to be seen clearly across a room on that 32 pixel high display. So far, nothing I've tried is even close to as readable as the original squeezebox font (as included in the 6.5.4 server). But that font stops at U+00FF. It won't even handle European languages, let alone Asia.

    Anyone got a good solution for this?

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
  •