MOC - music on console

I had set myself the goal of getting MOC 2.5-beta2 out during the month of September, but despite my best intentions real world concerns have managed to interfere once again with the MOC Master Plan.

In the run up to Christmas I thought I'd give you all a run down on how progress on MOC is running before you run away for the Christmas break.

As you'll be aware, MOC 2.5-beta1 was released in mid-October and has now been picked up by several distributions.

Several bugs have been reported. Their very existence implies that they weren't detected during pre-release testing and so it's not surprising that most cannot be reproduced locally and have to be debugged by e-mail, which is a time-consuming process.

With the new release, some new clues about old bugs have become available (particularly on screen upsets caused by the mishandling of non-ASCII characters). The major ones are now solved but the remaining ones will have to wait for the next release.

New development work has highlighted additional problem areas and these too are being worked on. Audio files exceeding 2GiB in size or having a similarly large number of samples are proving an especially fertile bug hunting ground.

Once these issues have been resolved MOC 2.5-beta2 will be released, but the progress towards it is slower than I would have hoped.

MOC's small band of developers and pre-commit testers has also grown a little with the addition of Tomasz Golinski, who has been a long-time contributor, undertaking to maintain the MOC web site content and information about MOC found on external web sites. He has in mind to make some rearrangements, so look for some web site changes in the near future. It will be good to have the web site tracking MOC developments more closely.

I'm hoping that in the coming month we will gain the services a MOC user who has volunteered to act as MOC Contributions Coordinator if and when his studies permit. This will be of significant benefit to the MOC user community as he will be able to harvest the contributions currently scattered throughout the Forum and place those still relevant in one common location where they can be kept current. Through him I am also hoping to provide pre-commit patchsets so users who wish to explore unreleased functionality will be able to do so.

Thank you to all those who have contributed to MOC in the past whether through bug reports, the discussion of ideas, testing or actual code, and I hope you will continue to do so in the future. Your support is very much appreciated.

Finally, let me wish all MOC users a very relaxing holiday season to the accompaniment of your favourite music.

John Fitzgerald.
MOC Maintainer.

User tomaszg and I have put some time into investigating the supposed tags cache corruption problem for which the accepted wisdom has been to delete the MOC tags cache. It has actually turned out to be a problem with stale database locks left over after a previous server crash, and I have today committed a patch (r2492) which I believe fixes it.

The Symptoms

• The client freezes.
• The server continues playing but does not respond to commands.
• Neither the server nor the client can be shut down gracefully.

Verification

• The client's status message indicates a server communication is in progress, usually relating to tags or playlist.
• The command db_stat -h ~/.moc/cache shows the same WRITE lock being HELD and WAITed for on the same audio file.
• This does not change significantly after the server is terminated.
• When the server is terminated the client also terminates with a fatal error about being unable to receive a value from the server.
• Setting the 'TagsCacheSize' option very low significantly increases the frequency of the problem appearing.

The Cause

• At some point the server has died while holding a database lock.
• Eventually the server attempts to acquire the lock and waits forever.
• Because it's blocked on the lock it cannot service new requests.
• The client sends a request and waits forever for the response.

Recovery Action

• kill -9 $(cat ~/.moc/pid)
• db_recover -h ~/.moc/cache
• rm -f ~/.moc/cache/log.*
• mocp

(Note that step 2 will create a 10MB log file. Step 3 deletes it, but you will still need to have sufficient space in your filesystem.)

The Solution

MOC no longer uses files (~/.moc/cache/__db.*) to back the memory in which locks are held. So when the MOC server crashes, any locks it is holding disappear along with the process's memory. This works because MOC uses single-process (though multi-threaded) access to the database holding the tags cache and it appears that losing the file-backed memory does not endanger the database's structural integrity.

Also See

node/825 (this is a textbook example of this problem)
node/599 (here the segfault is the triggering event)

I have today made a series of commits (r2383 to r2410) to SVN which represent a major overhaul of the FFmpeg/LibAV decoder. The decoder now supports a number of additional audio formats (including the requested WV and APE), and several video formats (AVI, FLV, MP4, REC and VOB) from which the audio will be played.

Seeking has also been added within the constraints of the FFmpeg/LibAV's libraries abilities to handle it. This varies by format and codec, and results in some discrepancies (e.g., WMA with MP2 is not seekable but WMA with WMAV1 or WMAV2 is seekable). The libraries are also unable to seek after reading of the input file
reaches the end, so seeking becomes disabled towards the end of the audio.

Streamed audio has not been added due to time constraints.

(I do have some ideas which may improve seeking and implementing streamed audio, but these will have to wait for another time.)

Downmixing to stereo (particularly of AC3 and DTS formats) has also been addressed.

Hopefully, more bugs have been fixed than have been introduced. For those who have unresolved issues with FFmpeg/LibAV and their related formats, it would be worthwhile investigating whether or not those issues still exist and posting the results (good or bad) on the original forum topic.

Of particular interest to developers is the new 'tools' directory which includes a test file generation tool and an MD5 checking tool. When debugging is enabled, MOC now computes the MD5 sum of the samples received from the decoders and these can be checked by the tool against an independant decoding to verify decoder fidelity. (And no, not all decoders currently pass these tests.)

A very large public thank you must go to MOC user "tomaszg" whose assistance has been invaluable throughout, and also to "zeddb" for additional testing.