Mpserv allows playing MP3s on a LAN or high-speed WAN through its distributed architecture.
Mpserv is an outstanding architecture designed for playing MP3s that are distributed throughout a LAN or high-speed WAN. The core of the system is the server, where a database of song titles is available through the network. Clients connect to this server and request songs to be played on the stereo system that is connected to the server machine.
To run the server, the system requires mpg123 >=0.59n, perl >=5.002. The server attaches itself to port 2600 using the TCP protocol. A rudimentary CLI is available for users to access by just telnet into the server and typing 'help' for the commandset available. The server primarily targets an external (probably GUI) client.
The server has a comprehensive database of all the mp3's available, with a playing queue holding the song currently playing and any waiting to be played. Basic set operations have been 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 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, which is equivalent to promoting the number 2 song in the queue.
On the other hand, to run the client, the system requires perl >=5.002, GTK >= 1.06, Perl/GTK >=0.5000. The client is designed as 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 Graphic User Interface (GUI) is pretty straightforward, where 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 the GUI, and they control the song position in the queue, deletion, queue refreshing, and tree refreshing.
Whenever a change is made by a specific client, the playing queue is automatically updated. Changes made by other clients are not visible until the refresh button is pushed. This includes when songs have finished, as the queue traversal is left up to the server. To fix this, a server-push mechanism is required, which enables each client to register as a 'listener' and is notified through a server of its own when changes have been made. Unfortunately, this feature has yet to be implemented.
To run the server, the system requires mpg123 >=0.59n, perl >=5.002. The server attaches itself to port 2600 using the TCP protocol. A rudimentary CLI is available for users to access by just telnet into the server and typing 'help' for the commandset available. The server primarily targets an external (probably GUI) client.
The server has a comprehensive database of all the mp3's available, with a playing queue holding the song currently playing and any waiting to be played. Basic set operations have been 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 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, which is equivalent to promoting the number 2 song in the queue.
On the other hand, to run the client, the system requires perl >=5.002, GTK >= 1.06, Perl/GTK >=0.5000. The client is designed as 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 Graphic User Interface (GUI) is pretty straightforward, where 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 the GUI, and they control the song position in the queue, deletion, queue refreshing, and tree refreshing.
Whenever a change is made by a specific client, the playing queue is automatically updated. Changes made by other clients are not visible until the refresh button is pushed. This includes when songs have finished, as the queue traversal is left up to the server. To fix this, a server-push mechanism is required, which enables each client to register as a 'listener' and is notified through a server of its own when changes have been made. Unfortunately, this feature has yet to be implemented.
What's New
Version 0.10: N/A