Mpserv is an architecture for playing MP3s distributed throughout a LAN or high-speed WAN. The core is the server which houses a database of song titles available through the network. Clients connect to this server and request songs to be played on the stereo connected to the server machine.
need: mpg123 >=0.59n, perl >=5.002
usage: perl server.pl
desc: Attaches itself to port 2600 using the TCP protocol.
There is a (purposely) rudimentary CLI available. Just telnet into the server and type 'help' for the commandset available. This is truly meant to be used by an external
(probably GUI) client.
The server has a database of all mp3's available as well as a playing queue holding the song currently playing and any waiting to be played.
A basic set of operations are supported, including addition, promotion, demotion and deletion of queue elements.
If the currently playing song is deleted, it will stop playing and the next song in the queue will begin. If it is demoted, it is interrupted and the next song in line is played. The first
song is then requeued to be played next. This is equivalent to promoting the number 2 song in the queue.
need: perl >=5.002, GTK >= 1.06, Perl/GTK >=0.5000
usage: perl client.pl [host-address]
desc: A GTK client for playing and modifying the server mp3 queue.
Omitting the host-address causes the client to look at the localhost for the mp3 server.
The GUI client should be fairly intuitive. The top frame contains the tree of available songs broken down as Artist => Album => Song. The frame below contains the list of songs that are currently in the server's queue. A bunch of buttons occupies the bottom of GUI, they control the song position in the queue, deletion, queue refreshing and tree refreshing.
The playing queue is automatically updated whenever a change is made by that particular client. Changes made by other clients are not visible until the refresh button is pushed. This includes when songs have finished, as queue traversal is left up to the server.
To fix this a server push mechanism is needed, where each client registers as a 'listener' and is notified through a server of its own when changes have been made. This has yet to be implemented.