Mopidy client with Vacuum Fluorescent Display

PeterWurmsdobler · March 16, 2021, 5:38pm

Hello,

First, I would like to say that I am quite impressed with the entire project, the design, the code, its extensibility, etc. In this vein, I would like to add some kind of client/extension that does the following:

listen to some entity to get the current state, and if applicable get notified on metadata or tag information, track duration and elapsed time on whatever is currently playing,
display this information appropriately on a Noritake-Itron Vacuum Fluorescent Display connected to a RaspberryPI4 (device driver on GitHub - PeterWurmsdobler/noritake: Noritake Display Driver).

As for the first part, I have read some documentation on the architecture, the APIs of various components (or actors). But I do not quite know where to start with the listening part, as it appears information could be gathered from various parts. What is the recommendation, and would there be a good example I could replicate?

Any help and hints most appreciated.
Cheers, peter.

jjok · March 16, 2021, 11:17pm

I think this Pimoroni extension might do a similar thing to what you want to do.

github.com

pimoroni/mopidy-pidi/blob/master/mopidy_pidi/frontend.py

import logging
import os
import threading
import time

import pykka
import requests
from mopidy import core

import netifaces

from . import Extension
from .brainz import Brainz

logger = logging.getLogger(__name__)


class PiDiConfig:
    def __init__(self, config=None):
        self.rotation = config.get("rotation", 90)

This file has been truncated. show original

PeterWurmsdobler · March 17, 2021, 9:22am

Hello @jjok , thanks a lot for the link; this is about what I was looking for.

Just a small but important question: how would I get hold of information on performer or composer, aka albumartist and artist, respectively, for classical music? One reason among others I intend to move to Mopidy is that I have the impression that would be a better basis for classical music.

Of course, the question remains: how does Mopidy obtain the tags for performer or composer? I would hope that if could at least extract them from VORBIS comments if my music collection is made up of flac files?

Kind regards, peter.

PeterWurmsdobler · March 17, 2021, 9:53am

@jjok , another small question: if a class inherits from mopidy.core.CoreListener and implements event handlers such as track_playback_started, in which context are they being executed? In some thread context of the mopidy core? Consequently, if I want to pass data into an object running a different thread, I would need some thread-safe queue?
Cheers, peter.

PeterWurmsdobler · March 17, 2021, 6:05pm

Thanks again @jjok , based on the link you shared and Extension development — Mopidy 3.1.1 documentation I was able to make the first version of mopidy client and VFD controller:
GitHub - PeterWurmsdobler/mopidy-vfd

Since I am on Ubuntu 16.04 I could not yet run mopidy successfully to test all, Gstreamer bindings not working for python3.7, but will install it on a RaspberryPi soon.

Regards, peter

jjok · March 19, 2021, 12:39am

Looks like you got the composer information you wanted.
Did you find an answer to your threading questions? I don’t really know anything about threads in Python, sorry.

PeterWurmsdobler · March 20, 2021, 11:51am

Hello @jjok , provided that the composer is set in the track information, all should be fine. The only question for me is now how can I make sure that the meta information is indeed retrieved and put into the track structure. That I can only answer once I get modipy to work with my local flac collection; see related thread https://discourse.mopidy.com/t/problem-scanning-local-flac-files/.

Talking of threads, at the moment, as I am still learning about modipy, I assume that extension code such as core-listeners is executed in the core thread context, .e.g. the on_start method or all event handlers such as track_playback_started. To be on the safe side, I have the latter put the data into a thread-safe queue and consume it in a different thread.

That being said, the question is anyway to what extend multi-threading is real in a python programme; I have not much experience here either. I used to use QThreads for a while which has a very neat concept of thread affinity and thread-safe object passing between objects.

Cheers, peter.

system · March 22, 2021, 9:22am

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.