Schneller Vor-/Rücklauf durch when_held auf next/prev-Buttons & Buttons beim Streaming

  • Guten Morgen zusammen,


    1. hat sich schon jemand mit einem schnellen Vor-/Rücklauf des aktuellen Tracks beschäftigt?

    Ich würde das gerne durch when_held auf den next/prev-Buttons realisieren, aber befürchte,

    dass sich das

    a) mit dem when_pressed beißt (müsste sowas wie when_held_but_not_just_pressed geben :/)

    und

    b) kenne ich die Funktion für die playout_controls.ph dazu nicht (nicht vorgesehen?)


    2. Weiterhin habe ich bei Livestreams (z.B. http://stream.laut.fm/kinderlieder-123) das Problem, dass der Prev-Button den Stream stoppt (aber nicht wieder startet)

    und der Next-Button bewirkt einen kurzen Aussetzer.

    Sinnvoll wäre doch hier die Buttons ohne Funktion zu haben. Hat jemand eine Idee wie das zu realisieren wäre?


    Viele Grüße,

    RhineFire

  • Hallo,


    hm, schade, scheint sich keiner für zu interessieren oder mit auseinandersetzen zu wollen.


    Trotzdem hänge ich noch eine weitere Frage an:

    Idee wie man es umsetzen könnte, dass der Rotary (KY-040) nur dann die Lautstärke regulieren lässt,

    wenn man ihn zuvor gedrückt hat?

    Also beim Drücken die Dreh-Funktion ein-/auszuschalten.


    Viele Grüße,
    RhineFire

  • Hi RhineFire: Also Interesse an dem Thema habe ich auf jeden Fall auch, aber ich habe leider ebenso keine Ahnung wie das geht. Bin auch nicht gerade der Software-/Linux-Experte, von daher hoffe ich mal, dass sich jemand zu deiner Frage meldet und pushe es hiermit noch einmal etwas...

  • Oh ja ich auch schliesse mich dazu. Bei Spotify oder youtube streaming sind die Schalter aber notwendig.

    Ich glaube das wird schwer zum realisieren. Danke RhineFire für das link. Habe gleich bei mir implantiert.

    Gruss

  • Jein, damit lässt sich FastForward/Rewind umsetzen (soweit schonmal super), aber leider nicht auf den next/prev-Tastern, da diese beim when_held erstmal natürlich ihr when_pressed ausführen und erst anschließend die when_held Funktion.

    Selbst ein when_released hilft nicht, denn dann würde ja wieder nach dem held gesprungen.

    Kann man nicht irgendwie die when_released-Funktion nur ausführen wenn zuvor kein when_held ausgelöst wurde?

  • Kann man nicht irgendwie die when_released-Funktion nur ausführen wenn zuvor kein when_held ausgelöst wurde?

    Doch, klar. Ich sehe auf Anhieb drei Möglichkeiten:


    1. Soweit ich weiß bieten die diversen GPIO-Bibliotheken die Möglichkeit, abzufragen, wie lang ein Button bereits gedrückt ist. Wie das genau geht und ob die Information auch noch nach Loslassen des Buttons in when_released zur Verfügung steht, müsstest Du in der Dokumentation nachschlagen.


    2. Du implementierst das selbst, indem Du in when_pressed die aktuelle Zeit abspeicherst und daraus in when_released berechnest, wie lang der Button gedrückt war. Damit könntest Du dann auch noch unterschiedliches Verhalten bei unterschiedlichem langem Drücken implementieren.


    3. Du merkst Dir in when_pressed einfach, das noch was zu erledigen ist, markierst das in when_held als erledigt und fragst in when_released ab, ob es bereits erledigt ist. Das könnte etwa so aussehen:

    Code
    def when_pressed(self):
        self.handled = False
    
    def when_held(self):
        self.handled = True
        # restlicher code...
    
    def when_released(self):
        if not self.handled:
            # restlicher code...
    • Official Post

    Ich sehe nachher mal zu Hause in meiner Codeschnipselnotizdatei nach, wie ich die Doppelbelegung der Taster umgesetzt hatte. Irgendwo im Forum hatte ich auch schon mal Beispielcode gepostet, finde den allerdings gerade nicht.


    //Edit


    Gefunden: Taster funktion unter gpiozero

  • Ich sehe nachher mal zu Hause in meiner Codeschnipselnotizdatei nach, wie ich die Doppelbelegung der Taster umgesetzt hatte. Irgendwo im Forum hatte ich auch schon mal Beispielcode gepostet, finde den allerdings gerade nicht.


    //Edit


    Gefunden: Taster funktion unter gpiozero

    Wow, klingt super, danke!


    Ich habe es implementiert und ein bisschen angepasst, leider scheine ich doch noch irgendwo einen Hänger drin zu haben,

    denn die normalen Funktionen next und prev funktionieren jetzt gar nicht mehr, auf prev geht auch kein fastrewind,

    aber auf next funktioniert bei hold das fastforward (immerhin ein Anfang :D)


    pull_up=False und pull_up=True getestet

    released() und pressed() getestet

    Div. if Kombinationen.

    Teilweise mit kuriosen Ergebnissen wie, dass fastforward dann immer weiter läuft, ohne Tastendruck usw...

    • Official Post

    Getestet habe ich jetzt erstmal noch nichts, aber sieh Dir mal die Reihenfolge der Funktionen (und das was in deren Klammern steht) in meinem Link an und behalte dabei im Hinterkopf, dass ein Programm von oben nach unten abgearbeitet wird!

  • So, ich habe mich mal der Thematik angenommen und die Skripte von MiczFlor für meine Phoniebox so angepasst, dass die Tasten "vor" und "zurück" bei kurzem Druck (bzw. eigentlich beim Loslassen) zum vorherigen bzw. nächsten Titel springen ("skip"). Wenn man die Taste länger gedrückt hält, wird innerhalb der Audiodatei vor- bzw. zurückgespult ("seek").


    Dazu werden im Pythonskript gpio-buttons.py für diese beiden GPIOs die Ereignishandler when_pressed, when_held und when_released definiert, um die richtige Zuordnung für die gewünschte Funktion bestimmen zu können:


    when_pressed -- def_reset_dur:
    Hier wird noch keine Aktion ausgeführt, sondern nur ein Zähler namens cls_seekbuttons.gl_button_seekduration zurückgesetzt, der die Länge des Tastendrucks speichert. Der RPi kann an dieser Stelle noch nichts Konkretes tun, denn der RPi ist ja nur ein turingvollständiger Computer und keine Glaskugel ;)


    when_pressed when_held -- def_fast_forward bzw. def_rewind:

    Der Zähler wird um 1 hochgezählt. Solange der Taster gedrückt gehalten wird, wird diese Funktion wiederholt aufgerufen. Nach etlichen Aufrufen (cls_seekbuttons.GL_SEEKSLOW) wird der Suchlauf gestartet und nach noch ein paar Aufrufen (cls_seekbuttons.GL_SEEKFAST) wird der Suchlauf schneller.


    when_released -- def_next bzw. def_prev:

    Diese bereits vorhandenen Funktionen wurden so erweitert, dass der Zähler überprüft wird: Der Titelsprung ("skip") wird nur ausgeführt, wenn aufgrund des Zählerstandes noch kein Suchlauf gestartet wurde. Anschließend wird der Zähler wieder auf 0 gesetzt.


    Jetzt würde es eigentlich funktionieren und für die Vorwärtsrichtung tut es das auch. Es wird das Shellskript playout_controls.sh mit dem Parameter playerseek aufgerufen und dort das Kommando mpc seekthrough +-2 abgesetzt. Aber entgegen der Dokumentation von mpc (manpages) beißen negative Werte weder bei seek noch bei seekthrough an.

    Wenn's oafach waar, kannt's a Depp aa :baeh2:

  • Am PC funktioniert mpc seek -5 ganz normal, am RPi nicht.

    Ich habe testweise das neue Raspbian (sorry RaspberryPi OS heißt das ja jetzt) vom 27.05.2020 auf eine andere SD-Karte aufgespielt. Der leifert folgende Systeminformationen:

    Die mpd-Versionen sind am Linux-PC und am RPi gleich und trotzdem funzt es zwar am PC aber nicht am RPi :wallbash:

  • Auf einem jungfräulichen Raspbian vom 27.05.2020 auf einer 16GB-SD konnte ich den MPD gemäß https://www.musicpd.org/doc/ht…tml#compiling-from-source kompilieren und mit ein paar Tricksereien tatsächlich zum Laufen bringen. Damit funktioniert dann auch ein negativer mpd seek -5, also Suchlauf rückwärts. Dann habe ich den neuen MPD (v0.22) auf die Phoniebox-Karte rüberkopiert, aber das läuft nicht, weil da ein paar *.so-Dateien fehlen. Das ist das Linux-Pendant zu den Windows-DLLs.

    Dann wollte ich das Phoniebox-system nochmals neu auf einer 4GB-SD aufsetzen, aber da lief der Speicher voll:
    sudo ninja -C output/release install # and install (at /usr/local/bin)

    Ja Greimfetzn, gottsvareckter! :baeh2: Gäht då ächt da Speicha aus...


    Da werde ich morgen(?) nochmals die Phoniebox-Softwaregaudi laut meinem Pamphlet auf der 16GB-Karte von vorne aufziehen (ist dann gleichzeitig ein Test mit dem Raspbian-Stand vom 27.05.) und dann das Ganze im Pamphlet ergänzen, so mit schrägen Kommentaren, was das alles für ein Rotz ist...

    Da hilft es nicht einmal etwas, wenn der mpd testweise das Album Constrictor von Alice Cooper abspielt.

    • Official Post

    Obwohl ich Dir in solchen Sachen eigentlich vertraue, wollte ich das nicht so recht glauben. Aber bei Deinem Glück hätte ich es wissen müssen. Du findest mit Sicherheit auch jede Nadel in allen Heuhafen dieser Welt. Da brauchst Du nur reingreifen und schon steckt die in Deinem Finger. Das ist echt irre! :no_sad:


    Jedenfalls kann ich bestätigen, dass seek von der aktuellen Position im Song nicht relativ zu den angegebenen Sekunden rückwärts springt. Was aber funktioniert sind absolute Angaben:


    mpc seek 30% - springt zum 30% Punkt des Titels

    mpc seek 70 - springt zu 70 Sekunden oder 1 Minute und 10 Sekunden

    mpc seek 0:2:20 - ist klar.


    (Getestet mit Grave Digger - Rebellion :cool:)


    Nun suche ich mir gerade nen Wolf, wie man an die aktuelle Position im Track kommt um damit evtl. einen Würgarround zu bauen. Mit status noch "rumgrepen" wäre ja auch extra noch... Gelle?!


    Ja Greimfetzn, gottsvareckter! :baeh2:

    Dem ist nichts hinzuzufügen!

  • Servus hyle,


    das waren auch meine beiden Ideen:

    1. Dein Vorschlag:

    Nun suche ich mir gerade nen Wolf, wie man an die aktuelle Position im Track kommt um damit evtl. einen Würgarround zu bauen. Mit status noch "rumgrepen" wäre ja auch extra noch... Gelle?!

    Hat eben den Nachteil, dass man das Phoniebox-Skript gpio-buttons.py nochmals aufbohren muss. Ist halt nur eine Behandlung von Syptomen, die eigentliche Ursache wird nicht behoben.


    2. mpd-Quellcode kompilieren (und anpassen):

    Das hat auch nach der Anleitung auf https://www.musicpd.org/doc/ht…tml#compiling-from-source funktioniert. Das Beste war, ich musste den Quellcode gar nicht bearbeiten, da mpc seek -5 mit meinem Kompilat einwandfrei funktioniert. Das sollte man vielleicht der RPi-Foundation als issue melden? EDIT 16.08.2020: Das habe ich hiermit getan.

    Allerdings wird das Binärprogramm (beinahe hätte ich "die EXE" gesagt ;)) über den Aufruf sudo ninja -C output/release install (siehe Spoiler unten) unter /usr/local/bin/mpd abgelegt und nicht unter /usr/bin/mpd. Und als Linux-Dauernoob habe ich jetzt massive Probleme, mein kompiliertes mpd so einzubinden, dass das System nicht merkt, dass ich es ausgetauscht habe. Mit Umbenennen des Originals und ln -s /usr/local/bin/mpd war's nicht getan. Ein daraufhin versuchtes

    Code
    sudo apt purge mpd
    reboot
    sudo apt install mpd # hier gab's viele blöde Fehler, System vermutlich "zerschossen"
    sudo cp /usr/local/bin/mpd /usr/bin # dazu bin ich gar nicht mehr gekommen

    schlug richtig fehl, so dass ich glaube, das System auf dieser SD mpd-mäßig "zerschossen" zu haben. Ich werde es morgen(?) nochmals aufziehen...

    Das Kompilieren hat gefunzt.


    Fortsetzung folgt...

  • Lange hat's gedauert! :X


    ...aber jetzt habe ich endlich die ganze Sache mit dem Kompilieren des mpd und Einbinden in systemd so hinbekommen, dass es funzt wie zuvor, nur mit Suchlauf "vorwärts" und "rückwärts". Im Pamphlet wurde das Kapitel 3.4 entsprechend erweitert.


    Was war das Problem?

    Zuerst hatte ich gemäß dieser Anleitung den Quellcode des mpd auf den RPi heruntergeladen und kompiliert. Das gesamte mpd-Projekt besteht in Version 0.21.25 aus 632 Einzelmodulen(?) und der Kompiliervorgang dauert auf einem RPi 3B+ ca. 15-20 Minuten. Er läuft aber problemlos durch, wenn die SD-Karte genügend freie Speicherkapazität aufweist. :bravo2:


    Mit dem Installationsskript des für mpd verwendeten Meson-buildsystems (sudo ninja -C output/release install) wird die Binärdatei nach /usr/local/bin kopiert. Da sah ich als Linuxnoob schon wieder das Problem, wie soll systemd dort die neue Programmversion finden? Also habe ich die Binary nach /usr/bin verschoben, so mit Beibehaltung beider Varianten des mpd und symbolischem Link auf die von mir kompilierte Variante. Das hätte es letztlich gar nicht gebraucht, denn in der Datei /etc/systemd/system/mpd.service steht im Eintrag ExecStart=...eh der vollständige Pfad drin. Habe ich aber erst später gemerkt :baeh2:


    Ich musste dann ohnehin an die systemd-Servicedatei ran, denn meine neu kompilierte Variante des mpd kann die Shellvariable $MPDCONF nicht auswerten. Keine Ahnung warum?!?? Mit dem fehlerhaften Originalprogramm aus Raspbian funktioniert dies aber komischerweise. :fies:

    In bester quick+dirty-Manier habe ich diese Variable einfach durch den Standardpfad /etc/mpd.conf ersetzt. Und siehe da: es läuft! :thumbup:


    Ich weiß schon, das ist keine wirklich saubere Lösung. Aber auf der Phoniebox ist mir das jetzt wurscht. :stumm:


    Vorschau:

    Morgen (Achtung: dehnbarer Begriff! :lol:) werde ich in der LaTeX-Bedienungsanleitung (Pamphlet) in Kapitel 3.9 noch die drei Punkte ergänzen, die man bearbeiten muss, um eine neue RFID-Karte manuell einem Audioverzeichnis (Hörspiel bzw. Musikalbum) zuzuordnen:
    * Audiodateien in neuem Unterverzeichnis in /home/pi/RPi-Jukebox-RFID/shared/audiofolders abspeichern

    * m3u-Playlist mit allen Audiodateien (vollständiger Pfad!) unter /home/pi/RPi-Jukebox-RFID/playlists/<Verzeichnisname>.m3u ablegen

    * Zuordnung der RFID-Karte zum Audioverzeichnis in Textdatei unter /home/pi/RPi-Jukebox-RFID/shared/shortcuts eintragen

    ==> erledigt