Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Oct 3, 2011
  1. Server: keep a history list

    This is accessible via the "history" command, just as the
    queue is. You can use this to check what's been playing
    The history grows without bound. In practice, this isn't a
    big deal. The average track is a few minutes long and has an
    absolute path of about 50 characters or so. At that rate, we
    waste a whopping 23K per day of constant playing. In only
    2-3 years of constant playing, we'll match the 17 megabyte
    bloat we get just from loading perl and gstreamer into
  2. Server: don't report non-existent tracks as done

    This is fairly harmless, as telling a stopped gstreamer to
    stop again is ignored, and the extra 'done' notification is
    generally useless.
    Still, it's nicer to be correct, and this will matter when
    we start keeping an accurate history list.
  3. Server: refactor queue_slice to be more generic

    We'll soon have a history list, so let's allow generic
  4. Server: accept slice ranges for cmd_list

    This matches the original xqpd daemon; it's handy when
    clients want to know the next item, but not necessarily the
    entire queue (which might be gigantic).
  5. xqpd: always build with gstreamer included

    I dropped the "use" down to a "require" so that eventually
    we could plug new backends in at runtime. However, this
    fooled our auto-dependency magic.
    Let's make sure we always include the perl module in the
    built script, even if we might not run it.
  6. Server: send a qnotify during cmd_clear

    This matches the other queue manipulation commands; I just
    forgot this one when adapting them in 40c912c.
  7. Server: log plays to stderr

    The old xqpd did this, and it was nice to be able to peek
    back through it later. Perhaps it's redundant, as you could
    easily make a 'play' notification hook to do this, but
    whatever. My users can complain if they want.
  8. add some documentation

    This is still pretty beta, but it seems to be working well
    enough for daily use. And the original C xqpd has been in use
    for years, so I know I like the concept. I guess there's no
    harm in making it available to others, then.
  9. Server: allow querying of advance status

    You can now issue "advance" with no arguments to just get
    the status. This matches the original xqp daemon.
  10. add xqpc client

    This makes it easy to access the server from scripts. The
    client library is somewhat overkill, in that it is fully
    asynchronous if you want it to be. We should eventually
    document and install it so that client programs besides xqpc
    can use it, too.
  11. Server: provide notification hooks

    Code run from the rc files can help with setup, but there's
    no way for it to run on certain events. Let's provide some
    notification hooks for common things: tracks playing, tracks
    finishing, and the queue changing.
  12. xqpd: read split rc directory

    We already read ~/.xqpd/rc. However, rc-files can get pretty
    complex, as they are the main form of extensibility. So it's
    nice to let the user split them up into ~/.xqpd/rc.d/*.
  13. initial commit of xqpd

    This is a port of my existing music player, xqpd. It
    originally stood for Xine Queue Playing Daemon, but this
    version is based on GStreamer. But it's such a catchy name,
    I have to keep it.
    It fixes several issues with the original xqpd:
      1. It's backed by GStreamer, not Xine. Xine was often
         flaky. It would cut off the beginning and end of some
         tracks. It would sometimes fail to open the alsa
         device properly. I could never get gapless playback
         working properly. I'm sure there are solutions, but I
         was able to rewrite this from scratch in less time than
         it took me to fail to find solutions for xine-lib.
         Plus gstreamer seems to be used more often and better
         supported for this kind of player. And it seems more
         extensible through extra plugins and pipeline filters.
      2. It's written in perl, not C. That makes it easily
         extensible. You could extend the original xqpd by
         listening for events on the socket (and I did), but
         then you had this rats nest of scripts that all needed
         to be started after xqpd had set up its listen socket.
         Plus, this is way fewer lines of code (less than 400!).
Something went wrong with that request. Please try again.