Maintenance
From giantdisc
#Adding_Disc_Space_for_MP3_Files
Contents |
Adding Disc Space for Audio Files
To be accessible by the GiantDisc server, the mp3 files have to be located in the directories named /home/music/00, /home/music/01, /home/music/02 etc. In other words, mp3 files are searched only in all directories in the music home that consist of two digits. These directory numbers need not be contiguous - you could have the three mp3 directories 00, 37 and 61 (a directory 00 must exist). It furthermore doesn't care, in which mp3 directory a specific mp3 file is located. Due to the fact that the mp3 filenames in the GiantDisc system are unique, they will be efficiently retrieved in whatever mp3 directory they are stored. This means that the mp3 files can be freely moved around between the two-digit mp3 directories.
The normal usage of the different music subdirectories is to expand space as needed onto different filesystems. I.e. 00 runs out of space so I purchase a new HD and mount it on 01. Unused music subdirectorie should be deleted in order not to distort the database statistics function.
With the above explanation of the mp3 directory scheme it becomes becomes clear how the disc space for mp3 files can be extended. Just install a new harddisc and mount a partition to a new mp3 directory like for example /home/music/04.
When CD's are recorded from within the GiantDisc Palm client software, the system searches a mp3 directory with enough space to store the grabbed temporary wav files and the mp3 files created out of them. If no directory with enough free space can be found, the system refuses to record (grab and compress) a CD. The GiantDisc administrator should therefore regularly check if the discs aren't full.
Backup
There is no best way to backup your mp3 files. Put them on any media that has enough capacity to store all your mp3's. I personally copy them to the harddisc of another GiantDisc system. GiantDisc has limited support to synchronize the database content and the mp3 files between two independent GiantDisc servers (see below).
To backup the content of the GiantDisc database only (without the mp3 files), there are two possibilities:
- Export parts of the database with gdexportdb.pl. Depending on the command line options, this script performs the following actions:
- Option --tracks
- For each track in the database, a track info file (extension .tri) is created which contains all track informations in plain text. Each .tri file is stored in the directory where the corresponding mp3 file is located.
- Option --albums
- For each album in the database, an album info file (extension .cdi) is created which contains all album informations in plain text. All .cdi files are stored in the directory /home/music/00.
- Option --id3
- For each track in the database the id3 tags of the corresponding mp3 file are updated. (The id3 genre tag is not written.)
The id3 tag export function is slightly intelligent. The id3 tags are not modified (and thus the mp3 file is not modified) if it is not necessary.
- Perform a full database export to raw textfiles with gdbackup.tcsh in the database directory. You need to have root access rights to sucessfully run this script (I didn't manage to set the database access privileges in a way that a normal user can export data to a file). The script does a full database exports including all GiantDisc related tables.
#Synchronize_two_Independent_Servers
Synchronize Two Independent GiantDisc Servers
It might be useful to have two independent GiantDisc servers: i.e. one that is installed in the living room, and a mobile, battery powered one. Suppose that only the living room server has a CD-ROM and internet connection and thus has recording capabilities. There should be an easy way to update the mobile GiantDisc with the new audio files, cover images and database records. This is what the synchronization script gdsync.pl is used for.
Keeping two servers synchronized is also a convenient way to make a backup of your music collection.
The synchronization script gdsync.pl is invoked from a shell. It has the following options:
- --remhost: IP adress or hostname of remote host to be synchronized
- --gencprl: copy genre table from remote host to local host
- --gencplr: copy genre table from local host to remote host
- --dellocal: delete tracks/albums/covers including audio files on the local host if no corresponding track or album on the remote host was found. Be careful with this option, because it irrevocably deletes track items and audio files on the local host!
- --delremote: same as --dellocal, but deletes remote track/album/cover
- --test: if set, the script only displays what would be done. The database is not modified, and no files are changed. It is strongly recommended to use this option before really synchronizing two servers.
- --ssh: use secure ssh/scp instead of insecure rsh/rcp commands
- --help: Displays a help screen
The current synchronization script is able to compare thousands of tracks of two hosts in just a few seconds. Copying mp3 tracks over the network obviously takes more time.
How gdsync.pl works
gdsync.pl compares the content of two GiantDisc servers - the local and the remote server. It detects the last modifications since the last synchronization and updates both servers. At the end of the synchronization operation both servers (almost: see below) have the same database content and the same mp3 files.
The comparison procedure between local and remote host is now fully symmetrical. It does not matter on which host the script is run.
gdsync.pl refuses to synchronize two servers if they do not have exactly the same genre tables. There are two ways to equalize the genre tables of two servers. One method is to manually change the tables using the genre modification functions until they are equal. The second possibility is to copy one genre table over the other one using the options --gencprl, --gencplr. It is up to the user to decide which one of the servers has the "correct" one.
Notice that the languages and music type tables cannot be sychronized - they are supposed to be rarely changed.
The option --dellocal is used to delete a local track/album/mp3-file if it does not exist on the remote server. This option is only useful if the two servers were synchronized once before.
Without the --dellocal option specified, a synchronization session only adds/modifies records or mp3 files. It never deletes something. In the worst case, mp3 files are overwritten with newer versions.
If a tracks exists on the local server but not on the remote server two alternative actions are conceivable:
- A new track has been recorded on the local host. It should also be copied to the remote host. This is accomplished by a normal synchronization operation.
- The local and remote server both had that track, and the user decided to permanently delete it (i.e. on the remote host). The deletion operation should also be done on the local host. In this case a synchronization session with the option --dellocal should be started.
Note that the above two cases can't be mixed.
The database content is directly compared over the network using the DBI library. The local user must therefore have read and modification access rights to the remote GiantDisc database (which is the default setting).
Prerequisites
The mp3 files are compared and copied using 'rsh' and 'rcp' (or 'ssh' and 'scp').
ssh/scp
You should make sure that you are not prompted for a password for each of the ssh/scp commands that are invoked by gdsync.pl. One way to do this with ssh is by using rsh public key authentication. Here's a step-by-step guide how ssh can execute roemote commands without being prompted for a password:
- on the local computer execute ssh-keygen -t rsa. Enter an empty passphrase.
- copy .ssh/id_rsa.pub from the local computer to some place at the remote computer
- on the remote coputer append the lines in id_rsa.pub to the file .ssh/authorized_keys
- make sure that the following file/directory permissions are set on the remote computer:
| ~ | drwxr-xr-x |
| ~/.ssh | drwx------ |
| ~/.ssh/authorized_keys | -rw------- |
Another method to get rid of passphrase prompts is using ssh-agent and ssh-add. An http://kimmo.suominen.com/docs/ssh/ by Kimmo Suominen explains this in detail.
rsh/rcp
To grant rhost-scheme access to the remote sever (rhosts authentication), it must contain the file .rhosts in the home directory of the user music, which contains the following line:
<localhost> music
where <localhost> should be replaced by the hostname or IP adress of the local host.
A pitfall which made me loose a lot of time: the file .rhosts must not be group or world accessible! set the permissions to -rw-------
