CD Extension Development


Got it. Will Google ever NOT deliver? apt-get install cython libdiscid0-dev

*Added - I COULD have actually read the documentation…


I got past the Mopidy log saying it couldn’t import PyGst with

sudo apt-get update
sudo apt-get install python-gst-1.0
sudo apt-get install python-gst-1.0-dbg
sudo apt-get install python-gst0.10

I’m now having trouble with _PyGObject_API. It’s installed, but Python can’t find it. This is on the “production” Pi with no virtual environments. Those are being done on the laptop, I just want to see what already exists.


It looks to my VERY untrained eye that I’m working on an earlier version that you (Tony) have already cleaned up. The Pi’s doesn’t look like the last commit you did.


OK, I’ve switched to the “Tony” version of _init…py, and Systemctl status mopidy shows that back end is started, but not the front end. Mopidy.log shows that Mopidy recognizes the cd extension, and CdBackend. The log does NOT show that it sees the CdFrontend.

added - Needless to say, I don’t get a UI in MusicBox…

added later - I restarted (possibly unnecessary) and I see “Cd” under “Browse” now, but I don’t see a track list inside of it. It could be the rest of the OS getting in the way.

Progress, none the less.


FWIW, when I insert a CD and look at the GUI through Remote Desktop, I see the message" “The name :1.15 was not provided by any .service files”. VLC can play the CD just fine.

I want to run through Mopidy because a) I want one stop shopping for the UI, b) I want to do it with the web UI, c) I want it to be routed through SnapCast the way the rest of the audio is, d) I want to know more about how this all works and how this sort of development is done.

But I did make progress today.


Hey Kraig, sorry I haven’t been keeping up. I thought I’d get a notification if you replied.

Try taking a look here at my fork of that repo where I’ve made some updates.

I’m currently working in the usability-tweaks branch, based on the develop branch from the original repo.

Try uninstalling the version of mopidy-cd you currently have and downloading that branch and running install.

As far as dependencies go, you don’t need any of that gstreamer0.10 stuff, or the libdiscid-dev. I tried to install those, too and eventually uninstalled them.

There are a couple of dependencies that you will need listed in the readme from the previous developer: python-libdiscid and python-musicbrainzngs

I’m currently using the Iris frontend.

Once you have those in, try it out. It’s listing tracks, playing CDs and putting the title on the CD in the browse menu.

I’m trying to get the title to show up on the button consistently and get a “play all” button at the top, currently.

Give it a shot and let me know if you can get it working!


Quick update, probably irrelevant, but I uninstalled Iris and I’m using Mopidy-Mobile now instead.

It has the “play all” option I’m looking for in the CD browsing side of things, refreshes the CD title more readily, and seems a bit faster.

EDIT: It’s not letting me reply again, so I’ll edit this post with my reply…

Hey, no problem! I don’t actually have all that much experience with this, but I noticed you were asking about the problem at about the same time.

Honestly, I think we’ve got it (minus some testing) thanks to those previous developers. I’m not sure why nobody has updated it in the pip install repo, but if I can get this branch cleaned up and merged, we could probably get that done and make the few of us who want to play CDs happy. :slight_smile:


Since I wanted to build up a new base image for my Mopidy servers on Stretch anyway, I’m starting from scratch to eliminate many of the missteps I made along the way and get a better starting point.

You have no idea how grateful I am for having just one other person who’s interested in this, and someone more experienced at it to boot!

Thank you VERY much!


Nope! Although I have a brand new Stretch-based image on a different Pi3 with a different CD drive and even a different CD, Mopidy-CD still doesn’t appear to see the insert notification. I’m definitely running the usability-tweaks branch now and there was only the slightest misstep in the build. I can and probably will go back to the interim image I made just before the misstep, but I doubt it will make a difference. It’s free.

I was concerned that maybe pcmanfm (the file manager in Raspbian) might be “eating” the notification, so I confirmed that I am booting to CLI. Both pcmanfm on both installations see the insert notifications when the GUI is running and the “production” machine sees the CD under VLC. When running headless and using just the MusicBox interface (no GUI shell) I don’t see the CD.

I’m not sure what’s going wrong. As I said above, I suspect that somehow the insert notification isn’t getting to Mopidy-CD, but I’m not sure how to test that.

FWIW, on the headless system, mplayer can play the CD from an SSH session.

I’m here to learn, so if any of you have an idea of where I should go next with this, please let me know.


*** added - a fresh from clean Mopidy adding SSH, mplayer, python-libdiscid, python-musicbrainzngs then Mopidy-CD (useabilty_tweaks) gives the same behavior:

In MusocBix I go to “Browse” and I see “CD: No disc” - eject, reinsert, same difference. Drilling down, “No tracks”.

If I’m going to try a different client (highly unlikely to help, IMO, since MusicBox is just reporting what Mopidy sees), I’ll need to grab an image of this, because other than not having SnapCast, this is a very good base image for me.

*** added - the linux laptop that is slated to be my development machine also displays “No Disc”, but looking inside that shows me the tracks (with names) and plays them back.


Obviously, finishing up my development environment and using a debugger would help…


You’d think that if it’s important to write logging files in Python it would be equally as good to be able to actually read them. Sadly after about two hours of Googling it seems that nobody really much gives a damn about that.

The Snickers Bar challenge:

Find a geeky, non-Python programmer teenager.

Bring a bag of “Fun Sized” Snickers bars.

For each Google query submitted to find out how to READ the Python log files, they get a Snickers bar.

Upon finding a successful post, they get the entire bag and they can go back to doing whatever it is that the kids these days do.

I submit that they will have to earn the Snickers bars the hard way.

Where do I find/read the Mopidy-CD log files?


I don’t understand this question. There is no one magical place on your system where all programs written in python write log files to. In the same way that doesn’t exist (or make sense) for programs written in other languages.

If mopidy-cd has any logging (I have no idea) then it’ll be output along with all other mopidy logging to the console or to a mopidy-debug.log file in the current directory (or /var/log/mopidy/mopidy.log if running as a service). Exactly where and what depends on how you run mopidy. If you specify the verbose option then you’ll get DEBUG level messages. This should be in our documentation.



From the reading I did, this seems to be pretty much the accepted way to do logging:

logger = logging.getLogger(name)
self.disc =
logger.debug(“Cdrom: Unable to read cd”)

I’m running as a service, although it might be a good idea to run regularly and see what the console spits out. I’m not seeing a log file in /usr/local/lib/python2.7/dist-packages/Mopidy_Cd-0.1-py2.7.egg/mopidy_cd, but that might not be the CWD when it’s running. It’s not in /etc/mopidy nor in /var/log/mopidy/mopidy.log. /var/log/mopidy/mopidy-debug.log does not exist.

I assumed (incorrectly, it appears) that since it wasn’t anyplace obvious, that there must be some standard place that the above snippet would place it.


Mopidy’s logging is configurable ( The default service configuration file (/etc/mopidy/mopidy.conf) points to a logging configuration file (/etc/mopidy/logging.conf) which will output INFO level messages to /var/log/mopidy/mopidy.log. Your example code logs a DEBUG level message which by default will not be output. If you wanted to see (all) DEBUG level messages when running as a service then you’d need to:

  • Change level = INFO to level = DEBUG in the handler_fileHandler section of /etc/mopidy/logging.conf to see DEBUG messages in /var/log/mopidy/mopidy.log.


  • Modify the service to invoke mopidy with the --save-debug-log option to see DEBUG messages in /var/log/mopidy/mopidy-debug.log.

Additionally, the current working directory probably isn’t what you think it is and doesn’t really make sense in the context of a service anyway.

All of this is more hassle then it needs to be while developing which is why the development environment advocates running mopidy in your console, ideally within a virtualenv. In this case, the more straightforward applies.


Thank you VERY much for your kind and patient reply.


Hi all,

as this thread is quite old, I am wondering if any progress has been made on this module and if it has been tested with pimusicbox.



I’ll have to try to find the other thread. Someone else had used the original source and perhaps branched it, but made it his (or her) own. I have successfully installed his, but while it works fine on an Ubuntu laptop I’ve been toying with, I have never been able to make it work with a Pi and a USB CD drive. I’ve done clean builds and I’m using two heterogeneous CD drives.

I just build up a Pi, put on Mopidy, then either MusicBox or Iris (not much luck with Iris, probably because I’m using SnapCast and I don’t know what I’m doing) then SnapCast. Maybe I should give PiMusicBox another chance. It’s been a few years.

In my case, in the GUI (when using full Raspbian) the system sees CD insertions. In MusicBox, it sees the extension, but never finds the CD. On the Ubuntu box it plays back correctly.

Let me see if I can find the other thread. It was more promising than what I achieved here, with no disrespect at all to the people who contributed. I’m the weakest link in this whole thing - I am not a strong Linux user.


Added: Of course, afpeluso was the other developer and his (or her) replies above are what have gotten me the closest to being able to play back a CD using my Pi based system.

I’ve sort of let it rest for quite a long time. I may play with it some more tonight.


I was reading another thread (Solved - No audio as service but sudo -u mopidy works (DietPi)) and it made me think that maybe it was just a permissions issue for the mopidy user.

My test bed system is now seeing the CD just fine. I’m going to be a little more judicious with my “production” system (I added mopidy to the video group as well as the cdrom group - I think just cdrom will do.

I’m very excited about this. Thanks to everyone, especially afpeluso, for the input. Now if I can get Iris to give me control routing audio from different snapservers to different snapclients (another issue that I’m sure is user error on my part) I’ll be absolutely thrilled rather than just happy.

Added: “sudo adduser mopidy cdrom” fixed it. The “production” server can now play back a CD, which isn’t necessarily a huge deal for a lot of people, but it allows a bit of spontaneity to the whole thing.


Oddly, Iris is suddenly working as well. It used to not playback audio, I think there was something not configured right with SnapCast. FWIW, Iris is supposed to have a front end for SnapCast, so if I understand this correctly, I should be able to, via the Iris interface, have multiple servers and dynamically connect to clients on the fly.


I’m not really finding that. It may have been pulled. Iris works (now) and I’m not seeing any SnapCast UI in Iris (which I’m sure I saw earlier). I know, I should probably look at Iris’s changelog.