Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

MPD userinterface - usability

Begonnen von martinp876, 20 Dezember 2023, 11:24:17

Vorheriges Thema - Nächstes Thema

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
Einfacher FHEM Anwender auf Intel®NUC

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

#4
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

Zitat von: martinp876 am 28 Dezember 2023, 12:14:50hä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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

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



martinp876

Jetzt will ich das Thema endlich zum Abschluss bringen.
Das MPD Modul und dessen Intention habe ich nun hoffentlich verstanden. Es ist definitv gut geschrieben und sehr gut dokumentiert.
Dennoch habe ich es umgeschrieben. Warum?Images
MPD
ist implementiert sehr viele (wenn nicht alle) Funktionen des ...MPD eben. Darunter sind Optionen zum Anzeigen von Images, multi-controller Betrieb und dessen Überwachung mit blocking, etliche Readings und Kommandos,... Musiklisten,...

MPDradio
hingegen ist eher schlank.
fehlenden Funktionen war in erster Linie die Verwaltung der radio-stations. Da es Streams sind braucht es
- polling nach dem aktuellen Lied
- Station Namen verwaltung remanent
- kommandoliste mit Station-namen zum Abspielen

Schlank heisst für mich
- entfernen (m.E.) sinnloser Readings - Darstellung des wesentlichen. Damit auch weniger Last beim FHEM Eventhandler
- entfernen unnötiger kommandos wie seek, ff,...
- vereinfachte interne Strukturen
- kein blocking sub-prozess, da nur ein controller relevant ist
- fhem standard kommandos wie on, on-for-timer,...
  on-for-timer ist sowieso relevant, da ich den Radio gerne auf mute  laufen lasse und das Zimmer verlasse. Dann streamt er tagelang wenn es sein muss. Auto-off ist zwingend.
- deutlich weniger Attribute

natürlich nutze ich (mein) standart-UI welches Kommandos systematisch parsed, Standardkommandos zu Verfügung stellt usw.

Die beiden Module sind also ähnlich aber am Ende nicht kompatibel. Eine Verwaltung einer Musik-DB brauche ich nicht, eben nur einen Radio im Büro aus der Himbeere (hier ist kein Funk-Empfang :) ).

Das Modul werde ich nicht in den "Pool" stellen. Da stehen jede Menge spezielle Module herum. Sollte interesse bestehen stelle ich es gerne zu Verfügung - geheim ist hier nichts. Ich will eben nur keinen Müll einstellen. Dann muss ich die Pflege intensivieren...

enno

Moin Martin,

ich nutze MPD wie du auch fast nur für Radiosender. Wäre also interessiert an deiner Version. Magst du sie mir zur Verfügung stellen?

Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC

martinp876

wie besprochen ist es "schon öffentlich" - aber breit verteilt nur, wenn es interesse gibt. Da bin ich nicht immer so sicher....

Ich muss dir 2 Module geben:
- MPDradio. Die Beschreibung hat nicht den Level des MPD - wenn Interesse besteht werde ich nachbessern.
 
- SAO (SystemAddOn). Ich verwalte Kommandos in Module welche ich anfasse nur noch darüber
  + du musst eine Instanz "define sao SAO" erstellen und kannst diese danch verstecken wo du willst
  + SAO stellt Funktionen und "globale Kommandos" zu Verfügung welche von MPDradio (auch) genutzt werden.

zu MPDradio
.du musst eine "Playlist" erstellen wie "üblich" in welcher deine Radiosender sind (hast du sicher schon).
.set update lädt alle playlisten (nicht den Inhalt).
    Refresh (F5) damit die Auswahllisten updated werden
- set playlistSel <liste aus drop-down> lädt dann denInhalt der selektierten liste (ich habe eigentlich nur eine Liste... habe es aber offen gelassen)
   Refresh (F5) damit die Auswahllisten updated werden
. set play <station from drop-down>


Dei Liste der Stationen wird erst nur als Nummernliste angezeigt. Wenn die station gewählt ist kommt irgendwann deren Name. Den  merkt sich MPDradio - wenn man ein save macht remanent.

==> ich bin auf kommentare und Anregungen gespannt.

SAO Hintergrund
muss dich nicht interessieren. Wenn aber, hier ein Überblick:
alle Kommandos der Module (welche es nutzen) werden syntaktisch beschrieben. SAO ist dann verantwortlich die Parameter zu parsen.
ein get cmdList zeigt die Dfinition der Kommandos incl Bereiche und Optionen.
Globale Kommandos wie "list" habe ich eingebaut da ich so etwas immer wieder nutze, will ich sehen das in der Entity intern vorgeht. Fellows halte ich für hilfreich, da es mit eine (bessere) Darstellung aller Elemente gibt, welche mit "mir" verbandelt sind. SAO sind kommandos welche ich mir vom Kernel erwarte - aber dort leider nicht implementiert sind. Da musste ich zut Sebsthilfe greifen.

==>alles lässt sich rückstandsfrei entfernen. Einfach die Entites löschen.