Hi, my post Using mopidy for hardware all-in-one device - features compatibility? is probably too complex with too many questions. I will ask step by step.
Please, how can mpd clients be notified that a specific URI class becomes available? E.g. CD audio medium is inserted - I would like to communicate to clients that its tracks (URI class cdda://) are available - e.g. whole CD cdda:// and individual track cdda://1, cdda://2, etc.? Should my extension create a specific stored playlist and let mopidy communicate the change to other clients? Would you use MPD api or some specific Mopidy API for the playlist creation? The playlists would be created in the same python program mopidy would be part of.
How can it communicate that the CD was removed - all the cdda://x URIs are not available anymore?
Thanks a lot for your help.
Pavel.
Hi Pavel,
I did see your other post and was gearing up for a reply to it since, as you say, there’s a lot of questions there. It is probably easier if we tackle one thing at a time but if I get a chance later this weekend I’ll try and reply to that too.
Our MPD frontend supports the MPD Idle mechanism for notifying clients of changes. Of interest to you would be changes to the stored playlists and current playlist subsystems. MPD clients should use these notifications to then fetch new data from the MPD server and update their user interface I.e displaying a new playlist for the user to select.
In general, the Mopidy API doesn’t have the concept of backend availability coming and going and the backend’s URI class(es) will always be ‘available’. But just because a backend is available it doesn’t have to actually provide any tracks or playlists; so I think you can still do what you want.
Something needs to monitor the state of the CD media, personally I think would be best done in a CD backend which could then provide these playlists (or not) and use playlists_loaded to signal core of changes. Core would then forward the events to the frontends for you. Maybe we should have a similar event for backends to notify of general media database changes.
If you do the CD state monitoring outside of the backend in some other (frontend?) extension, it would want to use the Mopidy core API to manipulate the playlists.
Any CD tracks will remain in the current playlist (tracklist) even if they become unavailable. Perhaps your extension would want to listen for particular playlist_deleted events and remove these from the tracklist?
Hello Nick,
I very much appreciate your insightful response. Please excuse my poor knowledge of details of MPD (protocol) principles.
My existing code detects the medium presense and displays the availability to the user. It is up to him when he decides to play the tracks available, he can finish his currently playing music first.
I assume the playlist is the list which is being currently played, track by track. Perhaps I should create/delete stored playlists instead? I can imagine in a regular MPD client a user lists all the stored playlists, seeing Files…, Radios, CD, etc. If the medium is removed, my extension would delete the stored playlist “CD” and remove it from “main playlist” if it is just now being played. BTW what is the right term you use for “currently played playlist” vs. “stored playlist, ready to be turned into the playlist being played”?
In my “client” I could read the availability status from the corresponding backends directly (my system communicates via messages, it would be the same what I have now).
Please do you think this would make sense in Mopidy/mpd?
Do extensions have direct access to functions offered by the MPD module https://docs.mopidy.com/en/latest/modules/mpd/ ? I mean accessing directly the python structures, without having to go through the text network protocol when they are part of the same python process?
I will post other questions in separate threads if you do not mind.
Thanks a lot,
Pavel.
I tried to install mopidy in devel mode to find out python 3 is not supported yet. Why did they have to break the language with incompatible versions 
I understand it is a gargantuan effort to migrate https://github.com/mopidy/mopidy/issues/779 My existing 3.5 code uses type hints extensively which I do not want to remove in downgrading to 2.7. I will continue with separate development and try to port to mopidy later on when it gets python3 support. Sorry for wasting your time and thanks a lot.
Best regards,
Pavel.
After more studying of mopidy I decided to backport my code to python 2.7, changed all the python3.5 in-place type hints to PEP484 comments, and fought a bit with the string-unicode schism of old Python. The advantages of the very nicely structured code in mopidy prevailed, thanks for the great work.
Unfortunately that will mean many more questions 