Detailed installation instructions are available both on this site and in the included INSTALL file.
Version 2.1 has been released. As usual, the change log is the place to go for the details. A few bugs were squashed, and the major visual change is the addition of a seek-bar on the albums screen, letting you seek around within the album list by first letter.
I've experienced some problems using high speed drives and recently released CDs, so I've lowered the speed during ripping to make it more reliable. This is, of course, changable if you need faster ripping. See the man page for dagrab and modify taripdisc as necessary.
I acquired the right hardware to make the jukebox software and operating system stored on compact flash, and the harddrive will only be used to store audio. This should make upgrading a breeze, just put in an updated compact flash card.
Version 2.0 has been released and is available in the downloads section and from the subversion repository. Major changes in this release include directory structure cleaning, modular client code, a clock is displayed in the client, the now-playing screen in the client looks better, and the client responds a lot better. All the scripts have been renamed, so you might need to make some changes to your startup scripts, but they are minor. As a whole, the system is less sensitive to being started outside of the distribution directory as the code makes an effort to change to the right directory and include the correct library dirs.
Getting close to a public release of the new client code. I merged branches/client-themes branch into trunk/ (my first big subversion merge operation, it was kind of confusing at first). Just clean up now. The new client code has been running on my production jukebox for a few days now, and a few remaining bugs have popped up which I'm working on fixing before releasing 1.8.
Version 1.7 is available in the downloads section. Check the change log for details. This is mainly an update to the server portion. New features in this version include faster ripping (encoding using oggenc in a pipe is what was slowing it down, now it rips to WAV files and then encodes to Ogg Vorbis in the background when the jukebox is idle), the album-images.pl script is included, and albums can be added from collections of pre-existing audio files (see the ADDING_PERSONAL_ARCHIVE.txt file in the server/ directory for the low-down on that). Note that when updating, you'll have to make a slight change to your thundaural.conf file, the exact change is documented in the change log.
Been busy working on the new client infrastructure in the client-themes branch, not enough time for an update until now. The new client is coming along really nice, and hopefully will be done in a few days, for which there will be a new release.
By popular demand, in the subversion repository are new files to allow you to load an already digitized (Ogg Vorbis or MP3) audio collection into the Thundaural database. See the files ADDING_PERSONAL_ARCHIVE.txt, personal-archive-load.pl, and the new ripdisc.pl. This will allow you to add those songs you purchased on-line or your huge pre-existing collection of music, and not just load it from CD. It's a simple three step process if you already have a nicely laid out and clean directory structure. This is an alpha version, it worked for me on a few albums I have, your milage may vary. You may want to back up your db/data.db database file before giving this a go.
I know everyone is just dying to find out what the latest developments are in the world of Thundaural Jukebox. If so, head on over to githu and download the branches/client-themes branch. I wouldn't suggest replacing your current client directory with this, but just download it and run the interface.pl (you may need to change the line that says host=>'jukebox' to your jukebox's name/address, that'll be an option when this branch is merged into trunk).
Things to notice:
- cleaner directory structure
- Widgets/ directory contains all the interface Widgets
- increased use of inheritance
- Themes/ directory to hold theme specific code
- the amount of code needed to customize and program a widget
- animated buttons
- visual feedback when buttons are hit
- minor cleanups in the way widgets are drawn to make them more attractive and consistent
What's there so far is just for show, activating things and selecting tracks shouldn't actually kick off commands to the server. And album cover art is not shown for all albums initially (in order to test what not having cover art looks like).
Long time no update. But things have been moving along in the background. The client is being completely reworked to be more modular (like the server was previously). The on-screen widgets have been rewritten to be usable in multiple themes. I have a new design and layout for the interface, but I'm working right now on porting the current interface to the new theme and layout engine.
A subversion repository has been setup with both the thundaural source code and the sdlperl source. It is located at https://github.com/thwarted/thundaural.
If you end up with version 1.x of DBD::SQLite on your machine, you'll be using SQLite3 rather than SQLite2. There were a number of changes made to how the SQLite API works, and some changes had to made to the thundaural server code to get it working. Preliminary (not fully tested) fixes are in r20 of the trunk (in the subversion repository), and will included in the next official release.
The checkdeps script will now generate a configuration file, rather than a TAProgramLocations.pm. I've listed all the necessary perl modules in the INSTALL_PERL_MODULES file. Any issues or questions or comments, see me on ICQ or subscribe to the mailing list.
To get this version going, rename/remove your old /usr/local/thundaural directory (or where ever you had put it) and untar this version in it's place. Run the checkdeps to generate the configuation file (you'll need to do this for version 1.6 even if you had done it previously for older versions) because 1.6 uses a new configuration file format) and put the generated file in the server directory.
This is entirely optional, but you might want to checkout the instructions for convert "tracknumtags" which will give you information on correcting a blunder I made in the old riper script that didn't put track numbers in the encoded files.
Some people might be having problems if the cdrom drive they want to rip from is not accessible via /dev/cdrom. If you are one of these people, either create /dev/cdrom as a symlink pointing to the device you want to use, or edit server/Settings.pm to list the correct cdrom device.
When installing, be sure to install SDL-perl last after all the SDL-libraries (and their header/development packages) have been installed. If you don't do this, SDL-perl's configuration will not compile a perl module that supports all the necessary SDL libs.
Until a new version out, you should verify that the database you are running is version 3 or 4 before making the change I outline below. You can do this by querying the database file (sqlite /home/storage/db/data.db) and issuing a select * from meta. The dbversion will indicate which database version you are currently using. I must have gotten something mixed up in the distribution. If you run ripdisc.pl --dbfile /home/storage/db/data.db --storagedir /home/storage --device /dev/cdrom, it should report a mismatch if there is one and refuse to run. If there is, just follow the directions immediately below to change ripdisc.pl to work around this. Most likely, this won't be a problem for the average user.
I recently came across a bug that keeps the ripper script from working. The ripper script is looking for a version 3 database, but the server upgrades the database to version 4. You can fix this by changing the top of server/ripdisc.pl and change the line near the top that says:
my $accepteddbversion = 3;to
my $accepteddbversion = 4;The changes from version 3 to 4 are unrelated to anything the ripper script does, this is the proper fix, which should get you by until the next release.
Speaking of the next release, some of the features I'm working on include playing an entire disc in one shot and removing the dependncy on ogg123. Including the usual bug fixes and minor feature enhancements.
I noticed that the edit command wasn't disabled in the server, so I've released version 1.5.1. Since the schema changed, this command is no longer guaranteed to work, and will most likely be completely removed in a future version.
Version 1.5 has been released. Check the CHANGELOG for details.
There has been a lot of cleanups. The main feature is that the ripping functionality is now modular, and will attempt to interface with MusicBrainz to get album information. I recommend using dagrab for ripping. The client is more independent of the server now. I've also included some scripts to ease getting both the server and client started on bootup.
As always, feedback is welcome. I suggest using the mailing list.
These pages have been updated with information for pending release of version 1.5. I am in the final stages of testing 1.5 and will release over the weekend.
Updated the Dependencies section on the downloads page with a new patch for vorbis-tools that contains both t3i.nl's remote patch, plus my patch to their patch. What a nightmare. I plan on removing ogg123 as a playback requirement for Thundaural at some point in the future (which will come a lot sooner than it was going to). Vorbis-tools will still be required, of course, for encoding.
Between being sick and being busy at work, I have not been able to dedicate as much time to development as I'd like. Which was good because the changes were not jelling in my head. But things have been moving smoother the last couple of days. Here's an update.
First off, it was tough going writing the code to upgrade the database structure to support the changes I previously outlined. I elected to not mirror MusicBrainz exactly, but rather only store the information Thundaural needs to keep track of tracks and files itself. Mainly the changes include the removal of the specific genre from each track, and adding an attributes table that stores genres (and, in the future, other stuff). Also, there is now a seperate performers table, which is intented to help normalize the artist information. The database will also track multiple images per album, rather than only one that was supported previously. Future releases will make better use of this as I work in automatic searching and downloading of additional album images, cover art, and liner notes.
But, really, the part that has been taking the longest so far is the new ripper script. What I've got going now is much better than the older one, and much more extensible. First off, it supports using dagrab, cdda2wav, and cdparanoia, in that order, if it can find them. cdda2wav is required overall to help get disc information. What's most important about this new ripper script is that the meta-data grabbing has been modularized -- I was struggling with how I wanted to do this, and it finally fell together. First it tries MusicBrainz, then falls back on FreeDB. The great thing about being modular is that additional grabber modules can be pretty much dropped in -- I have plans to write one that uses a local MusicBrainz database, rather than relying on a connection to the Internet at ripping time. Long term plans include automatic updating of meta-data as sources with higher authority expand -- Thundaural will keep track of the fact that it got album information from FreeDB, for example, and try later to get data from a more authoritative source (currently MusicBrainz).
This folds into some of the cooler things that MusicBrainz is doing, like lyrics and additional artist information, that can help turn the Thundaural interface into a true kiosk information server for the music it contains -- but those are long range plans.
I'm hard at work on MusicBrainz database integration. This will require significant changes to the server and the ripper program, along with the database structure. I've debated continuing to use the old database structure to ease transition, but right now I'm really leaning toward using the MusicBrainz database structure, because it is definitely closer to The Right Thing™ than CDDB ever was or will be. It's also more normalized than I originally made my database (by choice, because I was lazy), so we'll gain some new methods of querying with that also (which will manifest in the way songs are chosen for "random play"). Description of the changes are as follows.
This will most likely require a bump of the major version number, unless I can find a good mapping of CDDB IDs to Musicbrainz CD Index IDs. I'm going to try to ease migration of the data using MusicBrainz queries of artist and track information already in the jukebox database (as obtained from CDDB), I'll see how that goes with my own collection before making a final decision.
I really want to convert my source control program to GNU arch/tla, because I hate the way CVS handles multi-file check-ins, but I have not gotten around to it. But eventually...
I created a mailing list for discussion of Thundaural Jukebox issues. See the mailing list page for subscription information.
Version 1.4 is available (CHANGELOG). The big things for this release include
Soon I'll have instructions on setting up X and the startup scripts for running Thundaural as a kiosk.
Special thanks to Christopher Ness and Steve Gerety for helping debug the installation routines and giving me ideas on general improvments (even if they weren't aware they were giving me ideas while we were talking).
Released version 1.3 (CHANGELOG). Theree big changes in this release; the ripping screen is prettier, new stats page, and the inclusion of a script to make sure you have all the dependencies installed. Also, I fixed some stupid bugs that were making the screen get updated when it didn't need to be.
Released version 1.2. Changes to server include the addition of thread that updates statistics. The client was changed to handle the case where there are six or less albums in the database.
Released version 1.1. See the CHANGELOG. Hopefully fixed the problem with the client randomly segfaulting in odd places. Now includes an INSTALL file and a CHANGELOG file.
If anyone with mad graphic artist skillz wants to redesign the graphics in the client's interface, I would be forever grateful. Having multiple graphic sets to choose from would force me to finish the theme support I want to include.
Removed the dependancy on SDL::Timer, which appears to be unstable in SDL_perl 2.0.2. I suspect it's unstable in perl in general. It appears to start up another thread (using SDL's threading method).
Been super busy over the last month, making lots of changes. First off, the threaded perl server portion has opened up a lot of new possiblities. SQLite has been a big win here also. Being multithreaded allows better interaction between the support programs (ogg123, the cd ripper) and the server. The cd ripper script has had a slight overhaul, mainly to have it interact with the SQLite database, but it's also more robust in the face of scratched CDs. There's now an upper limit on the number of corrections that cdparanoia will be allowed to do to a single sector. If that threshold is reached, that track is reripped without cdparanoia's ultra paranoid settings, so at least something will come off the disc, rather than cdparanoia going into an infinite loop. For discs that are really scratched but do make progress during reading, the progress of the ripping is reported better, so the user can make a determination as to if it's worth it to let it continue and (possibly) finish.
For the client end, I've abstracted the client/server interaction to a single module. The previous way I had been doing it with code that closely mirrored the data structure of the database. Now that the client isn't interfacing directly with a database, there is no need for that. There is also no longer need for the Album and Track abstractions I created -- the client just asks the server for data and it all comes back as a perl hash -- much cleaner and faster than using full objects and accessor methods for everything; I think I might have been going overboard with the OO. Sure, the client needs to know something about the data format of the server, but if something changes, it keeps the server and client consistant now anyway, rather than hiding behind a useless (in this case) abstraction. The client code has also gotten a lot simplier, the different pages of the interface (album listing, track listing, currently playing, etc) have been abstracted to perl modules, and the interface between the on-screen widgets and how they page code interactions with the screen has been cleaned up -- the interaction was inconsistant in the old version, one page would update the screen directly, another page would draw to widgets which would then draw to the screen. I also finally got the alpha channel figured out for SDL(-perl) which makes the interface visuals cleaner looking (and now supports background images and animated icons). This fixes a number of bugs related to button feedback (important with a touchscreen), and screen update timing (also important with a touchscreen). I've also created an 'error page' that is shown if the client looses connection to the server. Visually, a pause and skip button has been added (now that the new server part exists these actions can actually be done), along with an on-screen volume control. And the final upshot of all this is that it's obvious how to theme or style the client interface (although I don't have any other themes defined at this time, but they should be relatively easy to add, but'll need to be written in perl (unless you just want to change my crappy graphics)).
I've added new screenshots showing the new features.
Server portion, in perl with threads and SQLite, is coming alone nicely.
Finally got the remote interface for ogg123 to compile. Found a bug (eof on stdin causes it to go into an infinite loop), generated a patch and sent it off to the place I got the patch from. The patch against T3i's ogg123 remote prepatch source is available.
I researched Boss Ogg (which has a fantastic name!), but it uses XMLRPC, which I'm turned off of for this project, as my initial tests in perl and PHP show that it's god awful slow, but damn cool and easy to setup and use. I'm also more comfortable working in perl for a project of this size.
Otherwise, Boss Ogg looks to be a very complete package, pick up and go, as it were. Unfortunately, I'm not in the mood to just do an install and be done.
I've decided that mserv and mpd are not close enough to how I want to use them, and I can't get seem to get excited about modifying them. I'm starting to write test programs to get the networking interface going, which will replace the MySQL transport I'm currently using, which is kind of ugly and slow (because I have to poll for changes via a query). I'm also testing out using SQLite as the storage, to remove the dependancy on the relatively heavyweight MySQL all together, which is overkill for this.
I also spent quite a bit of time getting a multithreaded perl installed under Trustix, which doesn't provide a multithreaded perl. The fork design has proven too problematic in terms of subprocess control (I have a hard time getting the lowlevel details just right), hopefully I'll have better luck.
Tried using XMLRPC/SOAP with perl's SOAP::Lite module, which has a huge number of dependancies (thank you, CPAN). It's pretty cool, perl's AUTOLOAD and dynamic typing makes RPC a breeze, no need to predeclare all the remote functions, and SOAP::Lite does all the XML conversion behind the scenes (having to generate XML was one of the reasons I had not looked into SOAP sooner). Unfortunately, it's quite slow (I was working over loopback). I'm sure there's a way to make it faster, but I wasn't having much fun researching that. XMLRPC/SOAP is cool, but the natively appearing abstraction it gets you can be a red herring -- binding for another kind of RPC (text streams over TCP, ie SMTP, HTTP, etc) are trivial to write in Your Favorite Langauge if the interface is well defined, plus there is, by its very nature, less encapusulation that needs to take place than with XML-based RPC.
Both mpd and mserv seem to be lacking some of the features I need, namely some way to imply grouping of the tracks into albums and genres for browsing purposes, along with a way to designate the album coverart. I suppose I could store this information in the ogg comment fields, but neither appears to have decent support for dumping comments to a client. mserv implies a album/track structure based on the directory layout, which may cause problems for the web-based client I want to write to allow modifying the meta-data for browsing purposes. mserv has ranking capabilities though, which is one of the things I want, but it's still kind of hazy as to how this works with a jukebox like I have. mpd has a cleaner interface for automation, whereas mserv is designed a mini-mud (with other, graphical clients on top of that).
Found mserv, which seems to do everything I need, except for the ripping of the discs. It also uses a client-server protocol over TCP that makes a lot of sense. This will allow me to move away from MySQL as the communication and storage medium sooner.
Also happened across mpd, which also seems to fit the bill. Research as commenced as to which one to use.
Started creating website.
Did some final interface polishing up (finally gettind rid of the goofy up and down arrow icons I was using that idolatrare agreed were ugly) and moved the system downstairs to the pool room and hooked it up to the (relatively crappy, but we didn't find this out until now) built-in speakers. Reconfigured for only one output (so there's no confusion as to how to queue things up). The party we threw that night served as the initial usability testbed. Responses were extremely positive, even with a bug that caused a ten second pause when an album was selected.
SDL-perl issues crop up again, and I spin my wheels until 4am tracking them down. Unfortunately, the SDL-perl website is down, but that's okay, since the website didn't provide much more than the perldoc that comes with the source.
The initial design for the album browser and the track browser take final form.
While creating the previous and next album list buttons, I realize that 1152x768 on a native 1024x768 LCD screen isn't going to cut it, as the perfectly round buttons I made in The GIMP don't look round anymore. In an epiphany, I realize that I might need to set some options for the traditionally problematic ProSavage video chipset, which I've had issues with before. A google search turns up a page that describes the use of the "UseBIOS" S3 Device Option, which, when set to false, gets things working like a charm.
The touchscreen interface is started. A lot of misstarts as I narrow down problems with SDL-perl and create workarounds. I decide that creating my own widget set is the way to go. Frustration with the lack of SDL-perl documentation, specificly complete lack of the OpenGL interface (which is apparently different enough from the C interface to SDL's OpenGL subsystem to make it difficult to get anything on the screen) sets in.
Touchscreen gets delivered. I have trouble getting it to work in its native resolution, 1024x768, it seems to want to scale 1152x768 down, and XFree86's default VESA modes don't seem to be driving the screen at the correct sync and refresh rates to actually produce a picture at 1024x768. I deem this to be a minor problem.
Shuttle arrives, and I make sure to remove JP2 from the Shuttle's FX41 motherboard to get the FSB to operate at 133mhz. I go through a few installations of RedHat before realizing that a distribution designed for desktop use isn't going to cut it. Too much stuff to remove and too many installed dependancies. I settle on using Trustix, and work from the other direction, doing the "minimal install with SSH" and building up from there. RPM compilation and installation goes extremely smooth, better than I was expecting considering my experience with battling RPMs (thank you, FreshRPMS).
Design begins on the server portion, and code is working in a few days on my RH9 desktop box, although I lack dedicated hardware to test it on. At this point, I also begin researching SDL-perl, and have a hard time wading through the frozen-bubble source looking for hints on how to do things.