MPD userinterface - usability

[martinp876]

Hi, ich habe gerade MPD auf meinem raspberry eingerichtet um webradio zu hören. FHEM eignet sich dabei für mich hervorragend als Control interface.
MPD eingerichtet - schon gehts - vielen Dank schon einmal.
Meine Anwendung ist Radio: eine Playlist mit Radiosendern. Die Anforderungen unterscheiden sich etwas von anderen Playlisten. Next und Prev sind eher nicht erforderlich.
Ich habe aber wünsche zur Usability. Die Liste der Kommandos ist sehr lang und im standard frontend chaotisch (alphabetisch) sortiert. Lässt sich wohl schlecht verbessern - ich muss also ein Frontend machen in dem für mich relevante Kommandos zu sehen sind.

Was nicht tragbar ist: in der Playlist sind URLs eingetragen. Mit "play" kann ich dann einen Sender wählen - über die Nummer
1) das Kommando "play" muss auf die Länge der Playlist begrenzt werden. Die Anzahl der Einträge steht eh schon in den Readings.
2) ich brauche Namen zu den Einträgen. Wenn ein Sender angespielt ist wird dessen Namen auch in den Readings angezeigt. Das Drop-down zu "play" könnte also das format : "Nummer: Name" haben. Das wird dann sukzessive gefüllt und gespeichert.

Um die Readings zu begrenzen scheint es schon Ansätze zu geben (no_playlistcollection). Wäre cool das richtig einzukürzen (so würde ich das machen - es gibt sicher andere Stimmen). Etliche Dinge wie Uptimes, Ids uvm interessieren mich nicht. Ich würde so etwas über "get" abfrage.

Es wäre cool wenn 1) und 2) berücksichtigt werden könnten. Ich werde MPD nutzen und muss es ggf anpassen, da ich wegen diesen Details nicht zurecht komme. Btw: ich habe so etwas schon beim Yamaha Modul eingebaut - da war es etwas komplizerter...

[martinp876]

Wie mir scheint herrscht wenig Interesse an diesem Modul. Es wurde schon seit 7 Jahren nichts mehr geändert. Entweder sind die User zufrieden oder nicht vorhanden.
Daher habe ich mit der Anpassung begonnen und werde wohl wieder einmal mit einer privaten Version des nächsten Moduls leben.
Die ersten Schritte haben sich schon gelohnt für mich.
Als Internet Radio scheint mir das Modul super geeignet. Zum Spielen von meiner Musik von Server sicher nicht. Da fehlt eine komplette Verwaltung welche für 1000 Titel machbar ist. Ein komplettes Frontend, struktur,...
Die gewählten Radiosender von nicht mehr als 30 ist hingegen absolut machbar.

[enno]

Moin Martin,

ich hatte das Modul intensiv genutzt, aber seit hier Spotify am Start ist nutze ich MPD auch nur noch für Radio. Wenn du dafür Anpassungen hast, bin ich interessiert. Ich habe mir was mit DOIF zusammengebastelt, aber richtig zufrieden bin ich damit nicht. Wäre also Potential zur Verbesserung vorhanden.

Gruss
  Enno

[schwatter]

@martinp876

Ich nutze MPD auch für Radio, daher
bin auch ich an einem Update interessiert.
Gerade dein letzter Absatz klang eher an ein Appell an den Dev.

Gruß schwatter

[martinp876]

Hi, es scheint doch User zu geben

In der Tat ist es als Appell/Anfrage/Anregung zur Diskussion gewesen. Angefangen vom unzureichenden Userinterface (meine Meinung ) dann (nach anpassen der Sourcen) Fragen zu Implementierung hätte mich eine Diskussion mit den Autor interessiert.
Mich wundern einige Details - wie schon erwähnt - der Implementierung, des coding style und insbesondere des Userinterface (UI). Es ist schon möglich, dass ich schlicht die Ideen nicht verstehe, welche dahinter stecken. DerAutor hat ja schliesslich einiges geleistet... da gibt es bei mir etliche Fragezeichen.
Ohne die Diskussion geben ich hier einmal ein paar Highlights wieder.
Das Modul schreibe ich mir um, da ich es so definitiv nicht bei mir laufen lasse - aus vielen Gründen. Da die Änderungen tiefer greifen ist es kein Update - aber hierzu meine Ausführungen im Folgenden.
Das Ergebnis stelle ich natürlich gerne zu Verfügung. Aber nicht als dieses MPD modul

Coding style
das ist viel Philosophie und Geschmackssache. Allerdings wäre eine Stringenz schon wünschenwert. Ich reagiere allergisch auf zufalls-einrücken.... Weitere Details übergehe ich jetzt

Coading
Beim Auswerten des Codes und dem allmählichen Verstehen frage ich mich, warum ein statusRequest immer 2-mal ausgeführt wird - einmal um die Readings zu füllen und dann um die anderen Ausgaben zu bedienen. Jedes mal wird ein Socket aufgemacht und eine IPC gestartet. Das kann man aber schon effizienter gestalten. Sogar der Code zur Auswertung ist dann fast nahezu doppelt erstellt.

Von der Idee elegant ist, "MPD Idle" als subprozess laufen zu lassen. dieser Prozess informiert dann FHEM, dass es Veränderungen gibt und ein Request gestartet werden sollte. Nun verhält es sich aber so, dass der Sub-Prozess ein Forken mittels Blocking ist. Alle Nase lang schlägt der timeout zu, der Prozess wird geschlossen und muss neu geöffnet werden. Was "forken" bedeutet sollte klar sein - eine vollständige Kopie des gesamten Prozesses - für nur einen Trigger für einen Status-Update. Das ist mir zu viel Performance für fast nichts - es gibt mehrere Alternativen.  Interessant aber, dass die Funktion "informParent" hier genutzt wird - die findet sich leider nicht in der Dokumentation.

Usecases
Hier sehe ich
-Eigene Musik-Konserven abspielen
- MPD beobachten
- Radio/streamen

Eigene Musik-Konserven abspielen
hier sprechen wir von über 200 Files, gerne über 1000. Das macht nur Spass mit Filtern, Suchoptionen, TAGs, Strukturen. Nichts davon kann ich hier sehen oder implementieren.
Eine Anwendung reduziert sich demnach auf sehr kleine Mengen Files oder das Abspielen von Playlisten welche extern erstellt wurden. Ein Frontedn welches Spass macht kann ich nicht erkennen.

MPD beobachten
ist möglich. Die Frage ist, was man erkennen will. Da ich die Readings begrenzen und strukturieren werde (evtl auch zuschaltbar machen werde)ist das hier kein Problem. ggf muss man am Polling tunen.

Radio/streamen
das ist nun eine Sache, welche man sehr gut steuern kann. Wie vom MPD empfohlen werden die Radiosender in einer Playlist abgelegt (extern). FHEM liest diese Liste und befüllt die Sendernamen automatisch beim ersten Anhören. Die Senderauswahl wird selbstredend command-dropdown eingefüllt.
Kommandos wir "repeat/random" sind obsolet.

Hierzu werde ich mir ein lean-interface schaffen. ggf umschaltbar auf "full command" - mal sehen.

Das Ergebnis kann ich natürlich zu Verfügung stellen - ein Update zu MPD ist das nicht - eher ein MPDradioplayer

[Wzut]

hätte mich eine Diskussion mit den Autor interessiert.

Du kannst MPD gerne haben und auf den Kopf stellen , wie ich hier -> https://forum.fhem.de/index.php?msg=1255637 schon schrieb, ich habe es selbst nicht mehr in Gebrauch.

Das Modul war 2014 mein Einstieg in FHEM und gleichzeitig auch meine ersten Gehversuche in Perl.
Klar heute würde ich mit Sicherheit das eine oder andere so nicht mehr machen, aber damals wusste ich es halt nicht besser und solange ich es benutzte machte es auch was es sollte.

[martinp876]

Es tut mir weh, MPD auf den Kopf zu stellen... auch wenn ich es nicht benutzen kann in dieser Form. Ich werden mir in jeden Fall ein MPDlite oder MPDradio bauen (bin schon dabei) - welches andere Ziele hat. Da dies zwar auch MPD nutzt - und vieles vom original nutzen wird - ist es doch etwas anderes...
MPD hat kein Frontend (es gibt viele Verweise auf TabletUI - das habe ich aber noch nicht gefunden).

MPDradio ist von mir als "direkt nutzbar" gedacht (so sehe ich dies). Ich plane jetzt erst einmal nicht, es in fhem zu veröffentlichen...

Zu den Inhalten meiner lite Version:
MPD nutzt "idle" um "relevante" Änderungen zu notifizieren, was dann einen Status-update der Readings zur folge hat. Da Änderungen der Songs im Stream nicht relevant sind ist es noch einmal nicht hinreichend. Idle triggert auch bei sonstigen Änderungen des MPD - das ist bei multi-controller steuerung hilfreich. Trifft bei mir nicht zu - FHEM ist der contoller, alles andere ist nicht relevant.
=> der gesamte "Idle" Komplex incl Blocking ist obsolet.

da ich nun also pollen muss (timer überwachung) muss dies "schlank" erfolgen. Zum Einen habe ich sowieso die Readings ausgeblendet/abgeschlatet welche mir nicht gefallen (über ein Attribut kann man alles wieder einschalten - per drop-down). Zum 2. werden nur Änderungen notifiziert. Effizient ist es, wenn bei einem Poll garkein Reading erneuert wird. Readings wie playtime sind also a) kaum hilfreich und b) erzwingen immer einen Update.

Bookmarks werden wohl als nächstes fallen. Um den player zu starten kann man ein musikstück wählen, eine Playlist starten - oder bei Radio eine Playlist starten und daraus den entsprechenden Stream wählen. Diese werden automatisch mit Namen hinterlegt so dass man mit dropdown einen Sender namentlich auswählt.

Es gibt  noch einige Feinheiten einzubauen - grudnsätzlich geht es schon (war ja schon sehr viel Vorhanden!!)

[Wernieman]

Wobei ich es gut finde, das das MPD Modul eben nicht pollt. Hatte es "damals" in einem eigenen Modul umgesetzt, bis Wzut seines "non Blocking" rausgebracht hatte. Verwende es seit dem.

Wzut: Hatten wir "damals" nicht sogar zusammen hier im Forum darüber diskutiert?

[martinp876]

nun, ich habe die Basisversion des players bei mir am laufen.
Grundsätzlich muss ich feststellen, dass MPD von Design her ein Modul ist, welches MPD mit allen Optionen zu Verfügung stellt. Viele Interfaces und Rädchen, keine Spezielfälle. Das ist ok, aber nicht was ich will. Hier ein paar Unterschiede:
- MPD geht davon aus, dss es mehrere controller gibt und sich der Zustand des Players somit einfach ändern kann(stop, anderer Song,...). Mein design geht davon aus, dass FHEM der controller ist. Damit kann ich auf das blocking komplett verzichten.
- Playlisten sind oft Listen Songs. Beim Radioplayer sind es streams. Der unterschied ist a) die Länge (playlisten können unendlich lange sein, die Liste der Raiostations ist beutlich begrenzt). Playlisten will man zusammenstellen - radiolisten sind statisch. Definition ist ausserhalb von FHEM. b) die Songs einer playlist werden von MPD erkannt (next-song). bei Streams ist dies nicht der Fall. Es muss gepollt werden um das aktuelle Lied (Beitrag) anzuzeigen.

Grundsätzlich will ich den Player schlank designen, komfortabel mit dynamischen Dropdowns und selbstkonfigurierend bestmöglich. Ich sehe es als Nachteil an, möglichst viele Kommandos anzubieten - besser ist, eine begrenzte Menge der richtigen Kommandos anzubieten.

Musik abspielen werde ich noch einbauen. Also eine endliche Liste semi-fixer Songs. Anwendung ist (die Spielerei) radiowecker. Der Timer hat im Modul nichts zu suchen - "at" liefer hier mehr als ausreichend Optionen.

==> ich habe das Modul also "MPDradio" genannt.
Das Interface ist schon rudimentär an FHEM angepasst. So gibt es ein "on/off/on-for-timer".

Grundsätzlich kann ich das unfertige Modul zum testen (mit etwas nacharbeit) zu Verfügung stellen. Gerne Anregungen, wie ein User-interface aussehen sollten und welche fertures man haben sollte.

bei mir läuft der Büro-Radion schon stabil. Da ich es ohne Bildschirm bedienen möchte habe ich mein altes HM-whitepaper display als interface genutzt. Damit kann ich: ein/aus schalten, Mute setzen (notifys), ich sehe den status (on/off), sender, artist, und Song. Damit sind alle primär funktionen für mich erschlagen.

Freue mich auf Feedback und Interesse