codplayerdcan now play mp3 radio streams too. The streams are configured incodplayer.conf, see the example there. Play streams by runningcodctl radio [STATIONID/NUMBER].
-
Additional libraries must be installed before updating:
apt-get install libmad0 libmad0-dev -
codrestdnow control players directly over ZeroMQ, instead of embedding the Node.js control web widget. As a result of this the format for specifying the list of players incodrest.confhas changed. The example config file shows the new format. -
The additional dependencies for
codrestdmust be installed specifically, which probably won't happen during a regular update. See for more details.
-
New command:
ejected. This is used by theon_cd_eject.shscript to avoidcodplayerdtrying to eject an already ejected disc. -
Update
codlcddependencies to handle Linux v4 kernels. You may have to update some packages for this to work:~/cod/bin/pip install -U Adafruit-GPIO Adafruit-CharLCDYou may also have to install this patched version of RPIO: https://github.com/petli/RPIO/tree/v0.10.1-petli
Some significant and breaking changes merits bumping the major version number. For this release the web control widget was moved to a separate repository to let it have its own version numbering.
To support the additional daemons (see below) and simplifying the code in general, codplayer is now fully dependent on ZeroMQ for all intra-component communication. This led to changes in the configuration file structure to make configuration of the all-important ZeroMQ endpoints easy.
The old state publishing and command factory classes used in
codplayer.conf has been removed. In its place are ZeroMQ channel
definitions in codmq.conf.
codctl now reads codmq.conf, instead of codplayer.conf.
codplayer.conf has changed format, removing the state and command
factory lists and instead just having a new parameter referencing the
codmq.conf file.
The old FIFO command interface and the state files have been removed, on the assumption that the ZeroMQ interface is much more useful. If these old interfaces are needed, they could be reimplemented as components using the the ZeroMQ API.
codrestd is now a daemon and behaves in the same way as all the
other codplayer daemons. Thus codrest.conf have additional required
configuration properties: pid_file and log_file.
An IO control board, connected to a Raspberry Pi GPIO port, is now
supported (and described in the doc directory). This board has two
corresponding daemons:
-
codlircd: read remote control events fromlircdand send keypress ZeroMQ events -
codlcd: Display player status on an LCD and status LED
The various daemons can have plugins, listed in the config files.
This release adds one such plugin for codplayerd:
codplayer.remotecontrol.RemoteControl: consumes keypress events and translates them into commands.
-
All daemons support new config parameter
initgroups. If set toTrueand the daemons are started with root and then drops privileges, they will acquire all the groups the daemon user belongs to, and not just the one specified in the config. -
codctl: new flag -q/--quiet to suppress output from action commands.
-
#37: handle multiple error alerts in the database admin web UI.
-
Eject discs in background process to avoid hanging the IO loop while the hardware spits out the disc.
Discs can be linked as an alias for another disc. An example usecase is to play a remastered CD when inserting the original release.
If a linked disc is played, the source disc ID is available in the
state.State.source_disc_id parameter.
-
#31: data file was stored as an absolute path.
-
#32: error handling broken when disc can't be read.
-
#33: highlighting broken when discs have skipped tracks.
The ripping process has been completely refactored. The old process used cdrdao to rip both audio and the full TOC in a single pass. This had a bunch of problems:
-
cdrdao isn't as good as cdparanoia to handle damaged discs, resulting in some skips and crackles on those
-
the error-correcting code in cdrdao introduces a lot of errors in the subchannel reading that the TOC depends on, so pregaps and indices on tracks are generally way off
-
it just gets confused by discs with hidden tracks before the first proper track
This refactoring solves this, by splitting the ripping process into two phases: first get the audio with cdparanoia, then an undisturbed TOC with cdrdao.
All discs in a pre-1.0 database will be reripped with the new process after deploying codplayer 1.0, but the change is backward compatible to retain any disc information and edits previously added. The result is thus that discs are reripped to a higher quality, without having to restart with a blank database.
Changes requiring action from the user:
-
The configuration in
codplayer.confhave new mandatory parameters:cdparanoia_commandandFilePublisherFactory(rip_state_path = ...) -
cdparanoia must be installed on the system
Good to know:
- Discs ripped with the old method that never had any information
added in the admin GUI (i.e. only had a
.toc, not a.cod) are no longer visible in the admin GUI. They will re-appear when reripped with the new process.
Changes affecting codplayer clients:
-
Ripping state is no longer part of
state.State, but handled in a separatestate.RipStateobject instead. The ZeroMQ state updater emitsrip_statemessages with these objects. -
Track.numbermay now be 0, indicating a "hidden" track before the nominal first track.
General:
- All scripts now have a
--versionoption - The player command
versionreturns the currently running daemon verson
Database admin GUI:
- User documentation
- Don't overwrite any existing track settings when fetching disc information from Musicbrainz
- More efficient sorting speeds up page load
Web control widget:
- Timeout of 30 seconds after the last client disconnects before stopping the state subscriptions
codplayerd:
-
Limit rip spead with new (optional) config parameter
cdrom_read_speed -
Fix #30: handle errors on pause/resume in
c_alsa_sinkcorrectly
- Fixes #28: crashed on errors before playing any packet at all, e.g. on missing USB audio device.
First fully packaged release.