Topic: Greyhound

Not sure if this is the proper forum for Greyhound discussion (Greyhound site said 'off-topic section') - please redirect me if not.

Anyway, I've got it running and it seems to work nicely so far. I'm running it on an ancient Via EPIA mini-ITX system with Fedora 9 that functions as my music server. This machine had been sitting on the shelf next to my stereo, running RH7.3 for many years with JWZ's 'Gronk' application to drive the music queue, while I controlled the queue from my desktop across the room. A HD failure prompted the upgrade and since Gronk is no longer maintained and I had trouble getting Apache to work thru soft links I figured it was time for an upgrade.

Surprisingly, there aren't many options out there for a simple centralized music player. Amarok provides the web-control script, but that's so stripped down. Greyhound seems like a prettier alternative with fewer hiccups and a lot of potential for growth. After installing it I was a bit surprised at how new it is (less than a week in the wild!), but it seems fairly polished so far. Kudos for making it available.

Things I like about Greyhound+Amarok:
- Shows play history on same pane
- Shows time / remaining time in cut
- Volume control
- Pause
- Amarok Dynamic playlist seems to have a better random song selector

Things I miss from Gronk:
- Ability to browse/search my music library through the web page
- Ability to add arbitrary tunes from the library to the playlist

Without those two things, Greyhound+Amarok is basically just a display of the current playlist with rev/play/pause/fwd and volume control. Those are useful functions, but if I want to choose the content of the playlist I still need to go over to the music server and pull up the main Amarok GUI. Not impossible, but inconvenient.

I'm not sure how much control over Amarok is possible through the scripting interface, so these feature requests may not even be possible. I'm pleased with Greyhound and hope to see it grow to be even more capable.

Thanks,

Eric

Re: Greyhound

Hey Eric,
You've got a couple of great suggestions. Adding things to the playlist is definitely something to consider in the future. Personally I think it would be a good idea, the challenge is really just figuring out how to do a couple of things:

* Query the database through DCOP to select information from the library. This probably isn't too much of an issue, since DCOP has a way to send queries to the database (dangerous in my opinion, but we'll leave that one to the Amarok devs)
* Build up a way to browse the library from the web. This would probably involve a custom tree menu that downloads the playlist in increments using AJAX. Anything else would be too much of a load on the server. This also has implications with the iPhone interface - I'd probably need to create an interface similar to Apple's music browser for the on-the-go playlist. Either that or leave the iPhone excluded from adding music to the playlist, which I would consider a last resort if using Apple's API. Do we even want to use Apple's API if it means testing is impossible on platforms other than a Mac with the iPhone simulator (meaning, agreeing to an NDA :-S) or the iPhone itself?
* Command Amarok to append the playlist. This is a challenge, as I'm not sure of any DCOP functions that can do this. The backup plan would be to call saveCurrentPlaylist, then write out the new playlist file, then have Amarok load that new file.
* Now for the real challenge: rearranging tracks. If Greyhound was to even come close to the native interface, I'd have to implement a full list-control into Javascript. Doable, yes; easy, not very. We're looking at capabilities like shift-click to select in a row, control-click to select multiple items, and combining the two -- and then dragging to rearrange the tracks. It would be a lot of work. Plus, how do you make it work for iPhone? Only allow rearranging one at a time, or perhaps use the tap-to-select method used in Mail? It does raise a few design considerations.

All in all though, great ideas. I'll put some thought into it. Really trying to see how much exposure Greyhound gets and get some feedback on bugs and then focus on features. Internet Explorer support, by the way, went down the tubes by revision 3. tongue Thanks for the feedback! I'll get some of those ideas into the grinder and see what can be done.

--Dan

Re: Greyhound

Dan,

Thanks for the reply. I've been using Greyhound for a few days now and I'm liking it a lot. I'm accessing it primarily from Firefox 3 clients on both Fedora 9, WinXP and Mac OS X Leopard - IE support is not an issue for me.

You mentioned the difficulties in allowing Greyhound to re-arrange tracks in the playlist. This was something I could do with the previous web interface I was using (Gronk), but honestly I rarely ever did. The things I mainly did to the playlist were:

- add a new item to the head of the queue (selected by browsing the library)
- delete an item from the queue (usually the item at the head of the queue ie. next to play, but sometimes at arbitrary positions if it was something I knew I didn't want to hear).

So if these two operations were available I'd be a happy camper. Anything more complex, like reordering is overkill for my purposes.

You asked about bugs. So far it seems pretty solid (it hasn't crashed), but there are a few things that seem a bit odd:

- When I pull up Greyhound in the browser for the first time after booting a client, it always seems to display the original playlist that Greyhound had when I first launched it on the server. This will eventually update after the current song finishes playing. Note that this doesn't seem to be related to the client cache - it happens even on machines that weren't accessing it when it first started.

- the title highlighted in yellow seems to be intended to flag the current song. Sometimes it lags behind by a song (or two?)

- sometimes the current song in the playlist has a blank information line even though the title is displayed in the page titlebar/tab. I've seen this happen when using the stop button on one client, then hitting play on another freshly booted client some time later.

Other than that it's ticking along nicely. Let's hope it gets some exposure.

Eric

Re: Greyhound

I think that the problems you've seen are all related to the multithreaded/forking support. The reason for that is a bit complicated:

When Greyhound receives an incoming HTTP connection, it immediately calls fork() to create a child process, and the child handles the request while the parent continues in the server loop. There is one flaw with the way this is done, and to understand that you need to understand how Greyhound handles the playlist.

If you run Greyhound from the command line you'll see two status messages: "initializing playlist" and "rebuilding playlist cache". Greyhound uses Amarok's DCOP interface to export the current playlist to XML, and then parses that XML file. Since parsing the XML file is cheap and each song's metadata probably requires only half a kilobyte of RAM at the most, Greyhound caches the artist, track name, album, and track number in RAM. The problem with this is that this cache has to be rebuilt whenever the playlist changes. As Amarok is unable to send an event to notify Greyhound of changes to the playlist, we have to resort to polling once a minute.

So every 60 seconds, as long as there is HTTP activity (and there is if you have the interface open, because of the AJAX refresh every 10 seconds), Greyhound re-exports the playlist and re-parses it. It then computes an MD5 hash of the playlist contents. The client also keeps a playlist hash; if the client receives a refresh with a different playlist hash, the client will reload to display the new playlist contents.

Now back to that multithreading system. Since it's the child process that processes HTTP requests, the child process also handles refreshing the playlist. However, when the connection dies, so does the child and the updated playlist cache with it. The parent currently isn't notified of changes to the playlist, so new child processes will be "stuck" with the original playlist.

The current plan is to trap SIGUSR1 and have child processes send that signal to the parent when a different playlist is found. The trick is to then signal all other children to also update their playlists, and with up to 20 worker threads each parsing the same XML file, things get hairy real quick. So the best plan may be to just kill off any keep-alive connections and with them child processes when the playlist is changed. It hurts efficiency, but increases reliability.

The reason the highlighted track is "lagging behind" a song or two but displaying the correct title is because the AJAX refresh sends back a track ID which controls the highlighting, but artist/track/album metadata for the document title due to differences in different templates' HTML formatting. If any songs were added to/deleted from the playlist after the most recent refresh, the track ID will be offset. Also, it's a bit difficult to sync all that activity on the client to what's happening on the server, and especially so with a home-brew embedded webserver.

--Dan

Re: Greyhound

OK - that certainly makes sense. It seems that a fair amount of low-level work will be required to patch up and it's certainly usable as-is.

Thanks,

Eric

Re: Greyhound

Update - I actually managed to commit a patch for that bug yesterday and since a few other bugs had been fixed I went ahead and released alpha 3. I'm hoping for some help testing, especially on lesser-used distros such as Gentoo, Debian, and Slax so that I can document requirements and instructions for getting PHP working the way it should. Once we get some people to test we can move into beta. Once we go stable with 0.2, I'm gonna shoot for library features in the 0.3 feature branch. I'm planning to use the Linux kernel version numbering system just like in Enano, except Greyhound won't have prefixes like "a1", "b3", "RC2" etc. nearly taboo like in Enano.

--Dan

Re: Greyhound

Dan,

Spotted the 0.1a3 update right after my last post so I downloaded & installed it. I ran it with two simultaneous clients (both Firefox 3 - one on Fedora 9, another on WinXP) and it appeared to stay in sync a bit better at first but eventually the server crashed after about an hour of running. I tried to restart it but it refused - possibly I didn't wait long enough for the port to clear.

I've reverted to 0.1a2 (which started up fine & is running OK) for now but will try 0.1a3 some more later.

Eric

Re: Greyhound

I've noticed that the latest code tends to zombify after a while for no particular reason that I can tell. What I *really* want to do is write a graphical configuration interface that lets you configure multi-threading support. In the mean time if the server's about to crash, do a killall -9 php and the parent seems to die along with all its zombie children. Still need to look into that for sure.

--Dan

Re: Greyhound

Hey, running Greyhound 0.1a4 on Ubuntu Intrepid over here.  Amazingly stable and featured program for an alpha! 

I have only experienced two bugs with Greyhound:

- The problem mentioned above with the "highlighted" now-playing track lags behind.  It's definitely the same problem with discrepancies between the Greyhound playlist and the actual Amarok playlist.  It doesn't happen often.

- After stopping the script, it doesn't kill all processes listening on port 7447.  I always have to kill all php processes, then an sh process, and then an avahi-publish process. 

I have had no trouble with Greyhound crashing after running for a long time.

The only thing I'm really missing is the ability to add and remove files from the playlist.  I think that drag-and-drop reordering of the playlist would be a nice luxury, but basic playlist manipulation is an absolute necessity.  The dcop calls for each of those are pretty straightforward (dcop amarok playlist addMedia [file] and dcop amarok playlist removeByIndex [index]), so the only hard part would be adding library browsing support to the interface. 

Overall, excellent program with a lot of potential.  It already has a very polished feel, it just needs a couple more features.

10

Re: Greyhound

I spent a fair amount of time working on a bug that caused DCOP to go zombie today. There'll be a commit in there once I can get all my debugging crap out of there and get it stable again.

--Dan