These are the manual installation instructions. If you run debian there are packages available. See the INSTALL.debian file for instructions. There are also alien'ed rpm's. I have not had time to test these but at least in theory, they should work :) Look in http://fringe.theory.org/rpms/ If you do have any problems, please don't hesitate to contact me at brian at theory dot org. Please excuse the spam prevention measures. Yes, I'm paranoid. +--------------+ | | | Dependencies | | | +--------------+ program debian package (.deb) RedHat Package (.rpm) ------- --------------------- --------------------- PostgreSQL (6.5/7) postgresql, postgresql-dev, postgresql-client libpq libpgsql2 mpg123 mpg123 MP3Info.pm libmpeg-mp3info-perl md5sum dpkg perl perl-5.005-base perl modules: Pg libpgperl Digest::MD5 libmd5-perl Digest::SHA1 libmd5-perl MPEG::MP3Info libmpeg-mp3info-perl for the mod_perl_client: apache apache, apache-common apache modules: modperl libapache-mod-perl for the ripper: lame cdparanoia cdparanoia eject eject also for now you will need to be running the linux kernel, or another kernel with a compatible /dev/dsp. possibly more :) +--------------+ | | | Building | | | +--------------+ For now, here's the build procedure: cd djukebox/messages ./configure make make install ldconfig cd .. ./configure make make install cp -a mod_perl_client /var/www # this part is _not_ verbatim Become the postgres user: su - postgres Create the djukebox user: createuser -d USER_TO_RUN_DJUKEBOX_AS Become root again: exit Become the djukebox user: su USER_TO_RUN_DJUKEBOX_AS Create the djukebox database: createdb djukebox Create the djukebox database fields: psql -f DB djukebox At this point everything is in place, but you still need to build the database of mp3's. This is done the first time you run the djshared. The djshared will add new mp3's it finds to the database at any time, but the first time it is run it will have to add them all, which may take quite some time, depending upon several factors such as the number of mp3's, the speed of the database machine, and the speed of the mp3 machine. Now you should create the actual djukebox user account you will use with your client. You can do this by using the support/djuseradd and support/djpasswd perl scripts: perl support/djuseradd USER_TO_RUN_DJUKEBOX_AS perl support/djpasswd USER_TO_RUN_DJUKEBOX_AS The DB script creates a user named henry with a password of hi for you There is no direct user deletion interface now (eg delete from users where..) +--------------------+ | | | Upgrading | | | +--------------------+ Well, if you are upgrading from a previous release hopefully you know what you are doing. There have been database changes (of course) from the last release, but (hopefully) nothing too revolutionary. At this point the upgrade process is still by hand, but there is a script to analyze your schema against the DB file in the distribution so you can see what's different. the checkdb script checks your current schema against a file, such as the DB file in the distribution, and tells you what's different. Doesn't give sql to fix it just yet, but its a start. It turns out that postgresql 7.0 has a bug in the cluster code that will nuke the table being clustered. So either upgrade or don't cluster. Other than that make sure you do a make install ; ldconfig from the messages directory on each machine you run on. Nasty problems can occur when components get linked against different versions. +-----------------------+ | | | /etc/djukebox.conf | | | +-----------------------+ You will need on each host a configuration file /etc/djukebox.conf Fortunately now you should be able to skip the rest of this section and just use the support/mkdjconf.pl script. It will ask you a bunch of questions and then spit out a djukebox.conf file in the current directory. Simply move this to /etc and volia, you should be in business. If for some reason you want to know more, here it is: component name required directives ------------------------------------------------ info_server stereo_server djshared lookattree mod_perl_client info_server_host [This list is not finished!] Currently supported directives are name default value used by ------------------------------------------------ dbhost localhost everyone dbname djukebox everyone dbport 5432 everyone djshared_poll_interval 30 djshared lookattree * djshared filenametype DefaultFilename djshared stereo_server_port 26000 stereo_server stereo_server_owner - stereo_server djshared_port 26001 djshared djshared_owner - djshared stream_port 26002 djstreamd info_server_port 26003 info_server info_server_owner - info_server info_server_host - clients encode_dir '.' ripper new_track_dir '.' ripper logdir - everybody loglevel -1 " maxlogsize 102400 " log_to_terminal - " the syntax is directive=value directive=value ... lookattree is special in that there is no default value, and it is mandatory. You should have one of these for each directory that holds mp3 files in your system. It will search subdirs as well so be careful. filenametype is also special in that there is a default value which never goes away. You should read the section "Filenames" below in order to have your MP3 files properly read into the database. Logging is new and not used everywhere. If you don't include a logdir you will get no logging. Everything else is optional. +---------------+ | | | Init Script | | | +---------------+ There is now a prototype init script. It is the file init at the top level. It is designed to work on a debian system and uses start-stop-daemon. I haven't checked if this will work on rh derived systems. Ths init script works but is waiting for me to finish debianizing the tree. To use, copy to /etc/init.d and for each component you want it to work for (djstereod, djinfod, djshared, djstreamd, djtella), do an ln like this: ln -s init component You can then start the component with /etc/init.d/coponent start. It may even stop the component if you are lucky :) This is all stuff that will be handled automatically soon (hopefully) +--------------+ | | | MP3 Server | | | +--------------+ on each host, run the djshared script (located in the source root) as your djukebox user: perl djshared This will take a while if you've not done it before. my pentium 100 takes a few hours. The speed of the database machine seems to make a big difference. It's also a good idea to stick a psql -c vacuum djukebox in a cron job for the postgresql user. Once day is probably good. the mp3 server is split into two distinct parts, the perl script and the djstreamd (c++). The perl script starts the djstreamd at startup. The startup time of the script can vary greatly. It remembers what files were where before so if nothing has changed, it should be relatively quick. I still need to speed it up but its not too bad. If stuff has moved around it needs to md5sum again and that's a little slower. The md5sum is done now by sampling the mp3 file at regular intervals. Seems to speed things up but the database stuff is slow too. djstreamd is started by djshared. It's real simple and doesn't know anything at all except what port to listen on (from /etc/djukebox.conf), as well as what directories it is allowed to serve files from (also from /etc/djukebox.conf) be careful as it will serve up any file whose path starts with one of the lookattrees in /etc/djukebox.conf. This is done for simplicity as this component never even talks to the database. +-----------------+ | | | Stereo Server | | | +-----------------+ The stereo server is pretty straightforward. Run it like this: djstereod The stereo server is where the actual mp3 decoding and noise making take place. It also takes client requests that relate to the local queue of songs. You will want to run one of these on each machine that you desire to make noise. Client requests related to what tracks are available go to the info server. +---------------+ | | | Info Server | | | +---------------+ The info server is pretty straightforward. Run it like this: djinfod It is the job of the info server to dispense information about the current state of the system to clients. This includes everything that is not playing queue specific, like a list of stereo servers, artists, albums, tracks, etc. There only needs to be one info server for each djukebox domain. It is probably a good idea to run this on the same host as the database, as then all of your single points of faliure are on the same box :) +-----------+ | | | Clients | | | +-----------+ At this point there are two clients. The first and less interesting is the shell based client, client.pl. It also happens to be broken right now. It was the first client and it sucks pretty badly if you actually want to use it to listen to music. There is also the mod_perl client. It is much better. You will need to put something like this: SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI allow from all PerlSendHeader On in your /etc/apache/httpd.conf The top level page is perl/login.pl You will only need to run one instance of apache with the mod_perl client to allow complete access to an entire installation. +------------+ | | | ripper | | | +------------+ The ripper is the one salvaged component from the old mpserv system. Quite possibly becuase it's the only one I didn't write :) the ripper works best when you define your encode_dir and new_track_dir in /etc/djukebox.conf encode_dir is where the cdda data is ripped to disk and encoded. This should not be within any of the lookattrees defined there because fild_files.pl checks there every so often for new files and keeps md5sums of the files it finds. This is problematic when the file is not fully written, as the database will get polluted with junk. new_track_dir can be defined to tell the ripper where it should put the encoded tracks when they are done. This way content can be seamlessly added to the system. Just keep feeding your cdrom music and it will show up (eventually) in the jukebox. If you have an smp machine you should give the number of cpu's to the ripper with -f. The default mode of operation is suck mode, in which the cdrom drive you are running on becomes hungry and eats as many cd's as you will give it. This mode is best for maximum throughput. When a disc is done the drive will eject. All you have to do (usually) is change the disc and close the drive. Occasionally the cddb logic requires you to choose from a list of multiple hits, or worse case, enter information mannually. +--------------+ | | | djtella | | | +--------------+ Djtella is the djukebox interface to GnutellaNet. It is a somewhat ruffed up copy of the hagelslag router that maps gnutella searches to database queries and vice versa. There is no interface for downloading or origionating searches. Use your favorite gnutella implementation that supports that. There is no push support or uploads either. Downloads work though. It looks for incoming phrases in artist names, album titles, and track titles. Search results can then be downloaded. It also recognizes a few key phrases. If it gets a search for artists it will respond with a list of all artist names. These are not downloadable search hits. You must then issue a search for the artist to download tracks. Similarly, you can also search for albums from a particular artist, by searching with a string like skinny puppy albums which will return a list of albums as hits. +--------------+ | | | issues | | | +--------------+ In addition to all the garbage up above, there are still more issues to be dealt with. you may need to do a /etc/init.d/apache restart if you change any of the modules that the mod_perl client uses. Don't download or encode in any of the lookattree dirs. This will cause havoc with the djshared because it checks every djshared_poll_interval seconds to see if anything has changed. If there are tracks in the process of being written to this will pollute the database with a bunch of crap. Best to work outside of the lookattree area and then move stuff over when it's complete. It would be good to have a way to detect these kinds of problems. I can't seem to think of one offhand. The included ripper will refuse to work in (or under) any of the lookattree dirs. There is user authentication now too. Login protocol has changed. There are some issues to deal with here, namely that the digested passwords stored in the database are enough to get access to the system :( +--------------+ | | | Other Stuff | | | +--------------+ The database schema is in the DB file. I should probably document it better. Note that if you want to run djshared on a different host than the DB you need to set up host based access in pgsql/data/pg_hba.conf, and make sure the postmaster gets started with -i The message protocol is all in the messages/messages file. It's a big perl data structure that gets eval'd by the two perl scripts there to write all the code for the library. One for C++ and one for perl. If you change the messages file you need to re-run ./configure or just run the perl scripts directly and then make clean && make install Some of the code is rather nasty. In particular genmessages.pl and genperlmessages.pl in messages/ are both pretty gross. Also MpStreamReciever.cc is largely incomprehensible and the djshared is not real great either. +-------------+ | | | Filenames | | | +-------------+ The Djukebox system relies to some extent on being able to parse certain information out of a mp3 filename if it should become necessary. This is handled through the filenametype directive in /etc/djukebox.conf. Most people who have large mp3 collections have a consistent naming convention for their files. Unfortunately almost everyone has a different convention. This is okay as far as djukebox is concerned. All you have to do is write a perl module to parse that information out into a hash and djukebox can deal with your filenames. There are two filename parser modules that presently come with djukebox. There is the DefaultFilename.pm and MpServFilename.pm. The former is a last resort that maps the filename to the track title, leaving the artist and album unknown. The latter is for mpserv format filenames, which my (and at least one other) site use. These are also the filenames generated by the ripper included in the distribution. The DefaultFilename.pm is always loaded by the djshared. Any other filename modules you wish to be loaded can be specified as filenametype directives in /etc/djukebox.conf. The module api is as follows: member sub test() takes a filename string and returns true or false if the filename is of a type which can be parsed by this module. DefaultFilename.pm always returns true on test(). MpServFilename returns true if there is a '=' character. member variable priority tells the djshared which order to try the modules in. DefaultFilename.pm has a priority of -10. MpServFilename.pm has a priority of 0. member sub parse() takes a list of fields which are currently supported, a hash initialized with these fields set to 'unknown', and the filename to parse. It should fill in as many of these fields as possible. DefaultFilename.pm sets the 'title' field to the filename. MpServFilename.pm does considerably more.