CD Extension Development

OK, I’m gearing up to write my first, well most anything.

I graduated college with a degree in computer science and for about 15 years my career was as a C/C++/Windows developer. When that career ended I went into IT supporting Windows. I am pretty new to developing anything web related.

My first project is going to be to write a CD extension for Mopidy. I want to be able to play back CDs on my system and no one is going to do this for me.

I grabbed a bought out laptop from work (yes, my boss knows I have it) and put Ubuntu on it. I’m going to use that as my development environment, which I’m just setting up.

This thread will be where I post questions and detail my progress. Since the scope if this project is fairly limited, I’m hoping it will be useful for others as well a myself.

I’m embarrassed how long it took me to connect this thing to my NAS, but that’s done and I have Mopidy installed as per the suggestions on the development pages.

I have pulled down the source for MPD (it can play back CD’s through gstreamer, so it should be useful for learning what gstreamer likes), gstreamer (for debugging purposes), Cookie Cutter, the previous CD extension attempt before the extension framework was mature and the Mopidy source code,

Q1 - I’m guessing that unlike my “production setup”, I’ll want to run Mopidy as a user, not a service. Development folks, what is your preferred set up?

Q2 - I might as well settle on a name now before it gets to be a real pain to change it. Mopidy_CD? Mopidy_CDDA? Mopidy_RemovableMedia? Mopidy_OpticalMedia? Mopidy_StopBeingAJackAssKraig?

Anyway, this should be a fun project. Don’t be impatient, life does intervene.

KO

Following these instructions to get your development environment set up.

https://docs.mopidy.com/en/latest/devenv/

Hey Kraig,

I don’t know how far you’ve gotten, but I’ve been thinking the same thing. I want to be able to provide CD playing capability along with streaming.

I’m happy to say that, thanks to some other peoples’ generous work, we’re not very far from it.

There’s an older plugin here and the development branch is very close: https://github.com/forscher21/mopidy-cd/tree/develop

It’s currently playing CDs on an external USB drive attached to my raspberry pi.

On initial install there was some brittleness in the CD titles lookup from musicbrainz, which I fixed in-place just to see if I could do it. It could use some interface tweaking, it’s just on the browser menu as a list, but it does work!

I’m thinking of getting my changes smoothed out and into a pull request or something. I’d be happy to share them with you.

Let me know what you think, but thanks to these folks we’re already close!

Tony.

I appreciate the input. I’m still setting up a development environment. It’s been nice here (Minneapolis, MN, USA) and winter is looming, so I’ve been focusing on things I need to do rather than recreational items like learning about programming for Mopidy.

Simple things take me forever. I FINALLY got Mopidy to successfully scan my library on the development machine. For some reason, even though the library was in ~/Music, I had to explicitly set local/media_dir to $XDG_MUSIC_DIR to get it scanned.

I’m planning on keeping Mopidy on the development machine running in user space, not as a service as it is on my “production” system.

I’m looking at preferred text editors/IDE’s. If anyone has one that they love, please let me know. I may be toying with C/C++ programming at some point, or at least stepping through C/C++ code to debug my own code. I know nothing of interactive debuggers for Python other than just using the command line interactively.

Anyway recommendations gratefully accepted. Progress has been made. There is much progress to be made still. It’s not unpleasant nor always frustrating, but it’s certainly not fast.

KO

I have made slow progress. I’m still setting up a development environment. There was also a painful system issue that took a day or two to get ironed out. This has been a real learning process for me, but it’s forcing me to learn Linux, which has been part of the goal.

Anyway, I’m going through the steps outlined in the docs point out by jjok - thank you kindly sir!

Tony - I’ve tried to install the existing mopidy-cd on my production server, but have had no luck with the pip installer. Is there any magic that this rank apprentice needs to know to make the mops dance and the buckets march?

KO

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 init.py doesn’t look like the last commit you did.

OK, I’ve switched to the “Tony” version of _init…py, backend.py and cdrom.py. 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 setup.py 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.

KO

*** 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.

Thanks!

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

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

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 (https://docs.mopidy.com/en/latest/config/#logging-configuration). 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.

Or

  • 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 https://docs.mopidy.com/en/latest/troubleshooting/#debug-logging applies.

Thank you VERY much for your kind and patient reply.