Betty als MPD client

[phaidros]

Das freut zu hören. Die Probleme sind registriert. Mal sehen, ob sich was machen lässt.

Ähm , meinen Beitrag obe haste gesehen?

Ja, habe ich. Ich benutze gar keine Shoutcasts (was isn das fürn neumodischer Kram?).
Kannst du mir mal eine ganz kurze Anleitung für Dummies geben, wie ich in MPD einen Shoutcast einrichte und wenn ja einen, wo das Problem auftritt?
Dann werde ich es mal testen.

Auch über die anderen Probleme muss ich erst mal nachdenken.
Bisher war ich davon ausgegangen, dass mpdtool auf halbwegs leistungsfähiger Hardware läuft und deshalb Resourcen ohne Ende nutzen kann.
Ist bei mir eine S100 und die hat keine Probleme. Die Vip1710 ist das 1 Euro Teil von Pollin, oder?
Ich weiß noch nicht, was sich da machen lässt. Irgendeiner muss die Arbeit des Aussortierens der Dateinamen und so ja machen. Entweder Betty oder mpdtool.
Und Betty ist nun wirklich nicht so leistungsfähig.
Das eigentliche Problem ist aber, dass MPD auf Suchanfragen unglaublich viel Rümpel schickt, den man gar nicht haben
will. Ich hätte am liebsten 2 Zusatz-Kommandos: count-find liefert nur die Anzahl der gefundenen Ergebnisse zurück, nicht die Ergebnisse selbst und
find-max liefert nur die ersten n Ergebnisse. Das wäre schön praktisch. Da es das nicht gibt., muss man basteln.

Ich könnte einfach bei den Suchbefehlen die Wartezeit der Betty auf 5 Sekunden (oder 10) hochsetzen, möchte das aber nicht.
Betty kann keine weiteren Befehle senden, solange sie auf Antworten des alten Befehls wartet.
Wenn also die Wartezeit zu hoch ist, wird das ganze Ding träge.
Das muss man irgendwie sauber anders lösen.

Das dauert ein Weilchen.

Gruß
Phaidros

[stevie101]

Hab mal mit der Wartezeit auf Betty und mpdtool Seite herumgespielt (aktuell bei 15sec), jetzt kommen vernünftige Ergebnisse. Muss ich aber noch weiter testen.
Ich denke, wenn man vermeidet, dass nach einer Suche und Suchmaske leer, nach "" gesucht wird,  MPD nicht unnütz belastet ist.
Eigentlich müsste dafür doch nur user_model.search_string = NULL gesetzt werden, nachdem AV gedrückt wurde (wie bei Initialisierung). Wo ist nur die Stelle im Code der Betty ?

Gruss
Stefan

[phaidros]

Eigentlich müsste dafür doch nur user_model.search_string = NULL gesetzt werden, nachdem AV gedrückt wurde (wie bei Initialisierung). Wo ist nur die Stelle im Code der Betty ?

Ich würde das an folgender Stelle machen:
File model.c, Funktion model_needs_action()

   /* Something to search ? */
   if (user_model.search_string != NULL){
      req->str = mpd_get_search_string();
      return SEARCH_CMD;
   };

erstzen durch

   /* Something to search ? */
   if ( (user_model.search_string != NULL) && (*user_model.search_string != '\0') ){
      req->str = mpd_get_search_string();
      return SEARCH_CMD;
   };

Dann sucht Betty nie nach leeren Strings.

Gruß
Phaidros

[glotzi]

Ja, habe ich. Ich benutze gar keine Shoutcasts (was isn das fürn neumodischer Kram?).
Kannst du mir mal eine ganz kurze Anleitung für Dummies geben, wie ich in MPD einen Shoutcast einrichte und wenn ja einen, wo das Problem auftritt?
Dann werde ich es mal testen.

Ich meine ganz normales Internetradio. Das Problem tritt bei allen Radiostreams auf, da der mpd ständig die Track-Infos neu schickt. Man kann das schön beim mpdtool sehen. Ich hab mal eine Playlist angehängt. Internet-radio geht beim mpd nur via Playlist.

Ich hätte am liebsten 2 Zusatz-Kommandos: count-find liefert nur die Anzahl der gefundenen Ergebnisse zurück, nicht die Ergebnisse selbst und
find-max liefert nur die ersten n Ergebnisse. Das wäre schön praktisch. Da es das nicht gibt., muss man basteln.

MPD patchen und einen Feature Request einreichen?

[phaidros]

Ich hab mal eine Playlist angehängt.

Ja, danke. Jetzt kann ich es nachvollziehen. Das Problem ist, dass MPD eine Gesamtlänge von 0 schickt. Das soll wohl soviel heißen wie unbekannt.
Außerdem werden Titel und Artist nicht getrennt geschickt. Sehr seltsam. Statt dessen gibt es einen "Name:" Eintrag, der wohl der Radiosender ist.
Bei einer Gesamtlänge von 0 denkt Betty immer, der Song ist gleich zu Ende und es kommt ein neuer. Da werden dann ständig Anfragen hin- und hergeschickt und der
Bildschirmtext wird aktualisiert. Das werde ich bei Gelegenheit ändern!

MPD patchen und einen Feature Request einreichen?

Im Prinzip völlig richtig. Ich habe nur etwas Schiss, da eine neue Baustelle aufzumachen. Bei MPD gäbe es meiner Meinung nach einiges zu patchen (damit es eben auf so
schwachen Clients wie Betty rund läuft), das könnte ein Fass ohne Boden werden. Vielleicht macht es ja jemand anders?

Gruß
Phaidros

[stevie101]

Code: [Auswählen]

if ( (user_model.search_string != NULL) && (*user_model.search_string != '\0') ){

Danke, hatte es ohne "*" vor user_model... implementiert - jetzt geht's.

Übrigens sehr cool, dass der code so schön kommentiert ist. Selbst jemand wie ich, der nicht C programmieren kann, bekommt ne Idee.

Gruss
Stefan

[phaidros]

Danke, hatte es ohne "*" vor user_model... implementiert - jetzt geht's.

Ist jetzt auch in der neuesten git-hub Version drin. Es macht ja wirklich nur selten Sinn, nach gar nichts (bzw. allem) zu suchen.
Hatte das nur so reingenommen, weil Amarok das auch so macht und es da wirklich funktioniert. Wenn man die Suchmaske löscht,
bekommt man einfach die komplette Musiksammlung zu sehen und kann darin rumscrollen. Nur Betty wird es nie schaffen, die ganze Sammlung anzuzeigen.
Ich hatte ursprünglich mal über eine Art "browse" Modus nachgedacht, wo man Ordner sieht, die man öffnen kann, aber letztendlich ist das Suchen doch
schneller zu implementieren. Und wenn man nur irgendwie Teile des Gesuchten kennt, findet man es ja auch ganz gut.

Gruß
Phaidros

[glotzi]

Ist jetzt auch in der neuesten git-hub Version drin.

Danke für die neue Version, der Refresh des Displays ist nun auch bei RadioStreams ok.

Ich habe aber immer noch das Problem, dass die OK Taste nicht funktioniert. Ich habe sogar die Betty gewechselt, um einen Hardware Defekt auszuschliessen.
Wenn ich in Ansicht Nr 1. "Current Playlists" zu einer Playlist navigiere und dort OK drücke, sollte doch der laufende Song abgebrochen, die aktuelle Playlist gelöscht, die ausgewählte geladen und Play ausgeführt werden. So stehts zumindest im Sourcecode.

Bei mir passiert nichts. 

Zum Thema Performance an der Vip 1710: mpdtool hat normalerweise ein Sysload von 8-10%, bei Suchen max. 30%, also eigentlich ausreichend. Bei mir läuft aber der mpd nicht auf der Vip, sondern auf meinem Debian-Server und der liefert den Sound via EsoundD an die VIP. Evtl. ist das für den ein oder anderen auch eine Option.

@phaidros: wieso hast du eigentlich nicht die libmpdclient benutzt für die Kommunikation mit dem mpd?

[phaidros]

@phaidros: wieso hast du eigentlich nicht die libmpdclient benutzt für die Kommunikation mit dem mpd?

Die kannte ich nicht. 
Werde ich mir gleich mal anschauen. Ist aber jetzt vielleicht schon zu spät.

Bei mir läuft aber der mpd nicht auf der Vip, sondern auf meinem Debian-Server und der liefert den Sound via EsoundD an die VIP.

Bin erleichtert das zu hören. Weil mpd auch noch auf der Kiste könnte knapp werden. Bei mir läuft MPD auf einem NAS-Server, wodurch sich manchmal
arge Verzögerungen ergeben, weil das NAS erst seine Platten hochfahren muss um Anfragen zu beantworten. MPD hält wohl seine Datenbank nicht im RAM.
Überhaupt, wieso braucht MPD ein paar Sekunden um seine Datenbank nach einem einfachen String zu durchsuchen ? Ein paar Millisekunden vielleicht, aber mehr nicht.
Na ja, es ist wie es ist.
Ich werde mal kucken, ob man noch an der Kommunikation etwas drehen kann, so dass die Last von mpdtool etwas zurück geht.

Wenn ich in Ansicht Nr 1. "Current Playlists" zu einer Playlist navigiere und dort OK drücke, sollte doch der laufende Song abgebrochen, die aktuelle Playlist gelöscht, die ausgewählte geladen und Play ausgeführt werden. So stehts zumindest im Sourcecode.

"Current Playlists" gibt es nicht. Entweder "Current Playlist" oder "All playlists".
Das von dir beschriebene Verhalten sollte bei "All Playlists" gegeben sein. Bei mir tut es das auch. Das könnte auch ein Timing-Problem sein. Kannst du mal die Ausgabe von Betty auf der seriellen Schnittstelle mitlesen, während das passiert? Sendet Betty überhaupt irgendwas?
Und vielleicht parallel auch die Ausgabe von mpdtool (via stderr auf der Konsole) anschauen.

Die Bezeichnung der beiden Ansichten ist sicherlich noch zu ähnlich. Vielleicht "Current Playlist" in "Current Tracks" oder so ändern ?

Gruß
Phaidros

[glotzi]

Die kannte ich nicht. 
Werde ich mir gleich mal anschauen. Ist aber jetzt vielleicht schon zu spät.

Evtl. macht es die Wartung aber einfacher. Man muss ja nicht geleich alles umstellen, evtl nach und nach.

"Current Playlists" gibt es nicht. Entweder "Current Playlist" oder "All playlists".
Das von dir beschriebene Verhalten sollte bei "All Playlists" gegeben sein. Bei mir tut es das auch. Das könnte auch ein Timing-Problem sein.

Sorry hatte die Namen der Screens nicht so genau im Kopf: ich meinte All playlists.

Was meinst Du mit Timing Problem? Das die Vip zu langsam ist? Ich habe den Scart auch mal an den Debian-Server gehangen, keine Veränderung.

Kannst du mal die Ausgabe von Betty auf der seriellen Schnittstelle mitlesen, während das passiert? Sendet Betty überhaupt irgendwas?
Und vielleicht parallel auch die Ausgabe von mpdtool (via stderr auf der Konsole) anschauen.

Ich wusste gar nicht, dass auf seriellen Schnittstelle was rausgeschrieben wird. Guter Hinweis. Mit welchen Paramtern muss die konfiguriert werden? Mit 115200 8N1 sehe ich nur Müll.

[jannis]

Bin erleichtert das zu hören. Weil mpd auch noch auf der Kiste könnte knapp werden. Bei mir läuft MPD auf einem NAS-Server, wodurch sich manchmal
arge Verzögerungen ergeben, weil das NAS erst seine Platten hochfahren muss um Anfragen zu beantworten. MPD hält wohl seine Datenbank nicht im RAM.
Überhaupt, wieso braucht MPD ein paar Sekunden um seine Datenbank nach einem einfachen String zu durchsuchen ? Ein paar Millisekunden vielleicht, aber mehr nicht.

MPD muss die Datenbank nicht cachen, das macht schon der linux kernel in seinem filesystem cache. Aber so groß ist diese Datei ja eh nicht.

Auch bei mir läuft mpd momentan auf ner S100, da ich den spdif ausgang von der vip immer noch nicht ans laufen bekommen hab. Ist wohl noch Neuland.

Obwohl ich über das Netzwerk auf meine Datenbank zugreife wird jegliche Operation nahezu ohne spürbare Verzögerung ausgeführt.
Auf dem Server (Dockstar mit USB platte) sind ca 150GB Musik und die Suchergebnisse kommen trotzdem immer sofort.

Wie siehts mit deinem RAM aus, biste vielleicht schon am swappen?

[phaidros]

Ich wusste gar nicht, dass auf seriellen Schnittstelle was rausgeschrieben wird. Guter Hinweis. Mit welchen Paramtern muss die konfiguriert werden? Mit 115200 8N1 sehe ich nur Müll.

38400 8N1
Bei mir brauche ich nichts machen. Im Makefile gibt es das Target "resident". Ich rufe make resident auf, das flasht die Betty, macht einen Betty-Reset und zeigt anschließend die
Ausgaben der seriellen Schnittstelle an. Also nach dem Flashen Betty einfach am Programmer dran lassen.
Früher gab es tatsächlich keine Ausgaben auf der Seriellen, da ist ein Flag drin was die Ausgaben bei Release-Versionen unterdrückt,
aber ich habe es schon länger ausgeschaltet. Jetzt sollte jede Menge auf der Seriellen zu sehen sein.

Gruß
Phaidros

[glotzi]

Auch bei mir läuft mpd momentan auf ner S100, da ich den spdif ausgang von der vip immer noch nicht ans laufen bekommen hab. Ist wohl noch Neuland.

Nee, kein Neuland guck mal hier
http://meta-lab.de/index.php/Musik_im_bytewerk

38400 8N1
Bei mir brauche ich nichts machen. Im Makefile gibt es das Target "resident". Ich rufe make resident auf, das flasht die Betty, macht einen Betty-Reset und zeigt anschließend die
Ausgaben der seriellen Schnittstelle an. Also nach dem Flashen Betty einfach am Programmer dran lassen.

Danke für den Hinweis, ich habe die Kabel nach dem flashen immer abgezogen. Wann öffnest Du dann EINT wieder?

[stevie101]

Zum Thema vip1710.
Aktuell läuft bei mir mpd, mpdtool, vdr und pyload auf dem Teil. Der Speicher ist mehr als am Anschlag, daher wird auf USB HD geswapped. Bezüglich CPU Auslastung sieht es gar nicht so dramatisch aus, da entweder nur MPD oder VDR etwas aktiv ausgeben. Dockstar als Server wäre eine Alternative, habe ich aber noch nicht, daher läuft die VIP 24hrs/d. MPD hat ca. 500 GB an Daten zu verwalten.

Alles in allem läuft das Ganze relativ gut, auf Suchanfragen muss man halt etwas warten. Um die Anfragen etwas gezielter auszulösen, hab ich versucht die Betty sw dahingehend zu modifizieren, erst nach dem dritten Zeichen die Anfrage an MPD zu schicken. Ist wohl nicht korrekt umgesetzt (Anfragen werden geschickt, allerdings inkorrekte bis zum 4ten Zeichen), hilft aber. Für low power Systeme wäre es aus meiner Sicht am besten, die Suchfunktion so zu ändern, dass erst auf "OK" die Suche Richtung MPD geschickt würde ("D" könnte die add Funktion übernehmen). Hatte jetzt häufiger den Fall, dass die Suche bereits ausgeführt wurde, obwohl die Eingabe noch nicht vollständig war (bin kein SMS Tipper). Workaround : raus dem Suchmenu, wieder rein, dann wurde umgehend der vollständige String geschickt.
Wenn die aktuelle Implementierung bei euch zuverlässlich und schnell funktioniert, muss ich selbst schauen, wie das umzusetzen wäre.

Desweiteren fiel mir auf, wenn sehr viele Resultate zurückgegeben werden (MPD schickt auch immer "OK"), die Suchanfrage ständig erneut herausgeschickt wird (kein timeout), trotzdem keine Resultate übernommen werden.

Gruss

Stefan

[glotzi]

Ich habe aber immer noch das Problem, dass die OK Taste nicht funktioniert. Ich habe sogar die Betty gewechselt, um einen Hardware Defekt auszuschliessen.
Wenn ich in Ansicht Nr 1. "Current Playlists" zu einer Playlist navigiere und dort OK drücke, sollte doch der laufende Song abgebrochen, die aktuelle Playlist gelöscht, die ausgewählte geladen und Play ausgeführt werden. So stehts zumindest im Sourcecode.

Bei mir passiert nichts. 

So, habe das Problem gefunden: es liegt an der Toolchain. Ich habe die ganze Zeit CodeSourcery Fall2010 Lite benutzt (gcc 4.5.1). Mit boop hatte ich auch ganz komische Probleme. Daher hatte ich die hier probiert:

https://github.com/esden/summon-arm-toolchain

Seitdem sind die Probleme mit der OK Taste weg.

Nur der Build klappt nicht mehr out-of-the-box. In fonty.c wird wohl types.h nicht gefunden und dann fehlt u_int16_t. Habe den typedef als Workaround dann selber gemacht. Dann läuft er durch.