Tag: gjay

  • Gjay 0.3.2 released

    After getting past a series of silly errors gjay version 0.3.2 is now available.  The source code was uploaded to SourceForge and the Debian package has been uploaded to the FTP master site.

    This version fixes the linking bug that have been extensively reported in a lot of Debian packages.  This is where you are using symbols of a library from another but not explicitly linking to it.  It means some versions of GCC will fail to link.

    gjay will now create playlists for Music Player Daemon or mpd and get mpd to run them too.  It does need for mpd and gjay to be on the same computer, or at least the same directory structure, so both programs know what file is.  While gjay has a full view of the filesystem, mpd uses a relative one off its own concept of a root directory.

    As a result of the two music players, both the audacious and mpd client libraries are not linked to gjay but are linked at runtime using dlsym(). It means you don’t need the audacious libraries if you like mpd or vice versa.  I’m not that experienced in using dlsym so hopefully I’ve not stuffed it up; it works for me!

    In theory, gjay could pass its playlists onto other music players.  The problem is knowing how to get the list into the player.  After it does its sorting and randomising, gjay ends up with a linked list of file-names. Now for audacious or (with some caveats) mpd it is pretty simple because they use file-names but others don’t do this.  If you know how it is done with your favourite player then let me know.

     

    Enhanced by Zemanta
  • Silly C errors in gjay

    Gjay GUI

    I have been working on Gjay to add support for http://mpd.wikia.com/wiki/Music_Player_Daemon_Wiki where I had what initially looked like a strange problem. When WITH_MPDCLIENT was defined, the program would crash in all sorts of weird places when the main program structure had this:

    #ifdef WITH_MPDCLIENT
    struct mpd_connection *mpdclient_connection;
    #endif

    But would work fine when it was:

    struct mpd_connection *mpdclient_connection;
    #ifdef WITH_MPDCLIENT
    #endif /* WITH_MPDCLIENT */
    

    I tried changing the structure to just void *blah to see if it made a difference and it didn’t. The program would crash every time.

    The answer was pretty simple in the end. The WITH_MPDCLIENT is defined in the file config.h and not every c source file was including it. Needless to say, they should! So half the program was using one version of the structure and the other was using another; no wonder the whole program was a mess because anything beyond this entry in the structure would be a few bytes out.

    With that little insanity out of the way, I can get back to making gjay work with MPD.

  • psmisc 22.13, gjay 0.3.1-2 and son 2.0

    Two updates for Debian today.

    I’m the upstream for psmisc and 22.13 finally got released, which also meant 22.13-1 Debian package got released too. There was some delay to it (see below why) but it is now out.  Unless you run a mips or superH architecture, there is not really any exciting changes, but should make it compile for those two architectures and then at least get the mips buildd underway so the versions all line up.

    Secondly, gjay had two minor bug fixes and was updated.  If the analysis daemon kept playing music instead of looking at it or the vorbis files were not being recognised, then this new version will help there.  The mpg123 command line patch will be rolled into the upstream too.

    I’m also working on getting gjay to work with the Exaile player.  If you want it to work with your player the easiest thing is to send me patches or code snippets that do the following:

    • Detect your player is running
    • Can give me the currently played song, preferably the filename of it. Exaile doesn’t so I’ll put it a kludge to guess it from title and artist
    • Remotely send a playlist to your player and get the player to start

    Last of all, my second son was born last week. It’s back to those night feeds again and is probably why I’ve not written as much code as I normally would; but I wouldn’t change that either.

  • Gjay Updated

    After a long time of testing and just plain other non-software writing stuff, I’m happy to announce Gjay 0.3.0 is released.  This is my first release of Chuck Groom’s code and hopefully it will work for you too.

    The Debian packages will be out shortly after some building and testing.  If you have a 64-bit computer it now works with 64 bits fine (ie on my amd64).

    It still needs some work, I’d like it to interact with more than audacious as the sound player. Also if you know how to in one of the sound libraries stream wav, ogg or mp3 files correctly I’d like to hear from you.  Currently gjay just uses the same old fork to mpg321 method, but idealy I’d like it to use the libraries directly.

  • Updated: psmisc, gw6c and gjay

    Time away from work and its been either raining or hot. So I’ve updated and released some software.  It always seems to happen there is a lot of Free Software development during the breaks.

    psmisc got a bunch of updates, including a new program called prtstat which formats the stat file in the procfs for a pid in (hopefully) a nice way.  No sooner had I released the latest update when a bug report came in. It seems fuser -m -k is a little too happy about killing itself. The fix is in the CVS but anoying I missed that.

    Next up was the Debian gw6c package. I was asked why it didn’t get moved from unstable to testing.  The problem is that while Linux has iproute, kfreebsd does not so the lack of a dependency was stopping it transitioning.  To make matters worse the freebsd template was missing from their package.  After some deb-substvars evilness to fix the dependencies and some dh_install overrides in the debian/rules file it should all be happy when its finished.

    Finally, I miss having good random playlists. I’m too lazy to make them myself so I use some random thing which often gives me rubbish.  A program called Gjay used to be in the Debian archive but got removed, mainly because the upstream stopped supporting it.  I can write C (the programming language its written in) and I wanted to use it, so I fixed it.  My version is 64-bit clean, so it works on my amd64 and it works with audacious not the old xmms which is great.  More importantly, it compiles, it runs and it even works properly.
    I’m just wondering if I want to release it out to the wider world or not.