Posts by Benzinbruder

    Bitte sehr, hier die das Verzeichnis der Playlists


    Code
    drwxrwxrwx 2 pi pi       12288 Dec  4 18:57 playlists


    und hier die Musik


    Code
    drwxrwxrwx 4 pi pi        4096 Dec  2 12:02 audiofolders


    Sieht von den Berechtigungen her doch OK aus, oder?

    Ob ich die mpd-Konfiguration selbst verändert habe kann ich nicht mehr mit Sicherheit sagen, das ist zu lange her.

    Denke aber nicht, dass ich root selbst hinzugefügt hätte.

    Sorry, das hatte ich übersehen.


    Hier der Output aus Beitrag 11:

    Code
    total 68
    drwxr-xr-x 2 root root   4096 Feb 25  2019 music
    drwxr-xr-x 2 mpd  audio  4096 Feb 25  2019 playlists
    -rw-r--r-- 1 root root    187 Dec  5 12:29 state
    -rw-r--r-- 1 mpd  audio 12288 Apr 23  2020 sticker.sql
    -rw-r--r-- 1 root root  41838 Dec  2 12:02 tag_cache


    Edit: Da sieht man, wie lang ich da schon dran rumbastle... :-/

    So, hier endlich meine Infos dazu:


    1)

    und

    Code
    Music Player Demon 0.21.5 (0.21.5)


    2)

    Code
    groups mpd
    mpd: audio
    
    groups pi
    pi : pi adm dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio


    3)

    Code
    root       577     1  0 11:56 ?        00:00:02 /usr/bin/mpd --no-daemon

    kle Vielen Dank für deine ausführliche Anleitung!
    Das Problem bestand offenbar durch meine (wohl recht dämliche) Benennung von Ordnern und Dateien mit Sonderzeichen. Nach dieser Korrektur läuft jetzt scheinbar alles.


    Deine Punkte oben bewahre ich aber gedanklich trotzdem mal als Tutorial im Hinterkopf, daher trotzdem nochmal vielen Dank an dieser Stelle!


    Was die Berechtigungen angeht habe ich leider immer noch wenig Plan, siehe auch den Post weiter oben.

    Mein Sync-Tool scheint drwxrwxrwx zu setzen, manchmal bleiben die Daten aber auch drwxrwxr-x?


    Die Daten, die ich gestern mit dem Tool per Samba von Windows aus auf die Box B übertragen habe, waren beispielsweise drwxrwxr-x, heute mit dem gleichen Tool unter für mich gleichen Bedingungen waren sie per SSH als drwxrwxrwx zu sehen. Bei Box A sind überhaupt alle Ordner drwxrwxrwx, auch die, die ich gestern gleichzeitig mit Box B neu synchronisiert habe. :conf:


    Wie oben beschrieben konnte ich die Rechte auch nicht mehr ändern, oder kenne nicht die richtigen Befehle dafür.

    So, mittlerweile habe ich das Problem gelöst.

    Für alle Mitlesenden / zukünftigen Leserinnen und Leser:


    Gebt bloß Acht, keine Sonderzeichen wie . , ! oder ' in euren Ordner- und Dateinamen zu haben!

    Die Tags waren es bei mir offenbar nicht, aber es hatten sich noch Kandidaten der eben genannten Zeichen in den Dateinamen verborgen.

    Das hat wohl das Problem verursacht.


    Weshalb die Box A bei gleichen(!!) Dateinamen und Ordnernamen kein Problem hatte, Box B jedoch schon, würde mich dennoch sehr interessieren.

    So, es gibt eine Neuentwicklung.


    Ich hab jetzt noch einiges Herumprobiert mit Rechten, habe die Dateinamen geändert und dabei sämtliche "gefährlichen" Zeichen entfernt, und so weiter.

    Alles ohne Wirkung.


    Aber jetzt kommts:
    Nachdem ich zusätzlich die Tags der mp3-Daten entfernt hatte, spielt die Box B die Daten ab.

    Kann mir irgendjemand einen Tipp geben, wie ich das lösen kann? Wie gesagt, Box A hat mit den Tags kein Problem, und ich habe wie üblich nur Titel, Track, Album, Jahr und Genre "getagged".

    Ja, aber die können doch alle lesen, oder?

    Keine Ahnung, wie ich für others auf r-x gekommen bin!?


    Jedenfalls scheint chmod o+w shared/audiofolders nichts zu ändern.

    Kannst du mir da noch einen Tipp geben?


    Und: Die anderen Ordner sind scheinbar ebenso drwxrwxr-x - wieso gehts bei denen?

    Die "gute" Box A

    Code
    2827272 4 drwxrwxrwx 26 pi pi       4096 Nov 30 21:37 'ORDNER 1'
    2827273 4 drwxrwxrwx  2 pi pi       4096 Nov 30 21:38 'ORDNER 2'

    Die "schlechte" Box B

    Code
    2698760 4 drwxrwxr-x 26 pi www-data 4096 Dec  1 18:53 'ORDNER 1'
    2827270 4 drwxrwxr-x  2 pi www-data 4096 Dec  1 18:54 'ORDNER 2'


    Ich seh den Unterschied, aber... :denker:

    Hier noch frisches Futter aus dem mpd.log (mittels sudo tail -n 100 /var/log/mpd/mpd.log) beim Versuch, besagten Ordner abzuspielen:


    Servus!


    Ihr fragt euch sicher schon warum ich Phoniebox B schreibe.

    Nun ja, danke der Hilfe dieses Forums habe ich letztes Jahr gleich zwei nahezu baugleiche Phonieboxen fertigstellen können.


    So weit, so gut.


    Jetzt habe ich aber das Problem, dass die Phoniebox B einen Ordner partout nicht abspielen will, der auf Phoniebox A anstandslos funktioniert.

    Ich beschreibe die Boxen immer mit einem Sync-Tool per Samba und das klappt hervorragend. Gestern gab es also neues Liederfutter, aber Box B spielt zwei der neuen Ordner nicht ab.

    Andere, ebenfalls neu hinzugefügte Ordner, funktionieren.


    Mit den Rechten hab ich es schon mal versucht:

    Link zum alten Beitrag


    Diesesmal hat das leider auch nicht zum Erfolg geführt.

    Hab schon versucht, mpd mit sudo service mpd restart neu zu starten, bringt auch nichts.


    Kann es sein, dass der gefragte Ordner noch nicht indiziert ist?
    Wie kann ich das erzwingen? Habe schon einige Stunden Wartezeit und einige Reboots hinter mir.


    Woran könnte das sonst noch liegen? :conf:

    Code
    sudo chown -R pi:www-data /home/pi/RPi-Jukebox-RFID/playlists
    sudo chown -R pi:www-data /home/pi/RPi-Jukebox-RFID/shared/audiofolders/
    sudo chmod -R 775 /home/pi/RPi-Jukebox-RFID/playlists
    sudo chmod -R 775 /home/pi/RPi-Jukebox-RFID/shared/audiofolders/

    Bei mir hat das dazu geführt, dass die per ssh erstellen Ordner über die Weboberfläche befüllt werden können - danke!

    Leute, Abstand halten. Nicht nur wegen Covid-19, wir haben hier einen Tatort.

    Ein Raspberry Pi wurde... umgebracht! :-/



    Ich glaube ich weiß, was los ist: Ich habe meinen Raspberry wohl selbst geschrottet.

    Die Musikboxen haben einen Drehregler zur Lautstärkeeinstellung. Selbiger hat 3 Ausgänge und braucht 3,3 V und eine Erde. Ich hab ihn nicht direkt an den Pi angeschlossen, sondern über eine kleine Lochplatine, auf der ich alle Teile und Komponenten schön zusammenhabe (unter anderem auch eine gemeinsame Erde und eben die 3,3 V). Leider habe ich beim Zusammenbau die Reihenfolge der Jumperkabel verwechselt: Anstelle CLK - DT - SW - + - GND habe ich die Pins des KY-040 Drehreglers auf meiner Platine mit GND - + - SW - DT - CLK verbunden.


    In der Folge hatte der Drehregler Spannung auf einem Pin, der keine haben sollte und ich vermute (ohne noch im Detail darüber nachgedacht zu haben), dass ich durch Drehen des Reglers einen GPIO damit beleidigt habe.


    Bemerkt habe ich das, als ich (in meiner Verzweiflung) Pi_C angeschafft und ausprobiert habe. Alles hat sofort funktioniert, aber als ich die Lautstärke regeln wollte, war plötzlich alles aus.


    Was lerne ich daraus:

    • Immer alles sauber kontrollieren, bevor man Spannung anlegt
    • Nochmal kontrollieren
    • Die Platine drehen und nochmal kontrollieren
    • Dann erst Spannung anlegen


    Ich vermute mal, Pi_B kann ich unter der Rubrik "Lehrgeld" ablegen? :conf:
    Pi_C läuft gottseidank noch. Glück gehabt.


    An dieser Stelle vielen Dank an euch alle, dass ihr mir so rasch Hilfestellung gegeben habt.

    Ich war am Donnerstag echt schon ziemlich am Ende. Vielen Dank für die Unterstützung!

    :danke_ATDE:

    Ja sapperlot.

    Pi_B ist mir, sofern ich mich richtig erinnere, doch tatsächlich mal während eines

    Code
    apt full-upgrade

    eingegangen, sprich: Ich habe die Verbindung verloren und das CLI blieb quasi stecken. :denker:


    Wie schon von mir im ersten Beitrag verlinkt sollte doch "grüne LED blinkt (immer wieder) vier mal" aber bedeuten, dass der EEPROM korrekt ist, oder?
    RTFM scheint ja hier anderer Meinung zu sein?


    Soll ich mal versuchen den Pi mit dem Recovery Image zu retten?

    Selbst dort ist allerdings vermerkt:

    Quote

    To check, remove the SD card, disconnect the device from power, then reconnect it. If the green LED does not flash, you will need to reprogram the EEPROM

    Ja eben. Bei mir "flasht" doch die grüne LED. :conf:

    Beide Pis bekommen von mir eine feste IP. Das sollte also kein Problem sein.


    Was die SD-Karten betrifft: Ich soll also kontrollieren, ob ich in der boot-Partition Dateien mit veränderten / aktuellen Zeitstempeln sehe?

    Sprich, die Karten nach einem Bootversuch im Pi auf dem Rechner kontrollieren?

    Vielen Dank für eure Antworten!

    Folgende Informationen von meiner Seite dazu:


    Beide Pis sind identisch verbaut, versorgt, konfiguriert... was auch immer!
    Dass einer der beiden besser oder schlechter mit Strom versorgt wird wie der andere... kann ich natürlich nicht ausschließen, aber das wäre schon sehr merkwürdig, oder?


    Franjo G Was den Kartenslot auf dem Pi_B betrifft: Der fühlt sich genauso an, wie der Slot im Pi_A. Ich habe den Pi in einem Gehäuse verschraubt und kann daher aktuell keinen direkten Blick auf den Slot werfen (der ist auf der von mit abgewandten Seite), aber gefühlt wackelt da nichts. Und: Ich bekomme ja eine Reaktion, wenn eine Karte im Slot ist:

    • ohne Karte blinkt die grüne LED vier mal (und zwar immer wieder)
    • mit Karte leuchten rot und grün dauerhaft


    RTFM Ersteres ist für mich ein Hinweis, dass ich kein Problem mit dem EEPROM habe.

    Wie in meinem ersten Beitrag verlinkt heißt es:

    If the green LED blinks with a repeating four blink pattern then the bootloader is running correctly, and indicating that start.elf has not been found.

    rpi444 Nachträglich mounte ich die Karte doch nicht, wenn ich versuche, direkt von ihr zu booten, oder?
    Oder verstehe ich da etwas falsch? Ich habe auf jeden Fall immer zunächst im ausgeschalteten Zustand die Karte eingelegt, und dann Strom zugeführt.

    Das hab ich ja. Ich hab die SDX_2 im Pi_A gehabt und das komplette System neu aufgesetzt - genau so, wie ich es auch mit SDX_1 gemacht hatte.

    Damit bekomme ich eine Musikbox wie geplant.


    Wenn ich die SDX_2 jetzt in Pi_B steckt, sehe ich den nicht einmal im WLAN.

    Es passiert gar nichts - außer dass die rote und grüne LED durchgehend leuchten.

    Ja, ich habe eine SD Karte, die ich nur im Pi_B verwendet habe: Das ist SD_3. Sie war zwar ehemals in Pi_A, aber ich habe wie beschrieben buster lite neu geflasht und damit sollte ich ja wieder "zurück am Start" sein.


    Ich habe in der Zwischenzeit SDX_2 ohne Probleme in Pi_A konfiguriert (bzw. Pi_A mit eingelegter SDX_2) und bekomme damit ein voll funktionsfähiges System. Alles wie gehabt.


    Lege ich SDX_2 (vor dem Lesen eurer Beiträge) allerdings in Pi_B ein, sehe ich Pi_B nicht im WLAN. Auch das Ausschalten über den Pimoroni OnOFF SHIM, der in beiden Musikboxen verbaut ist, funktioniert nicht.


    Ich nehme daher an, dass die SD gar nicht richtig gelesen wird?

    Servus zusammen!


    Ich hab ein Problem mit einem meiner beiden Pi 4 1GB. Beide werden verwendet, um eine Musikbox für meine Kids zu betreiben (2 Kids, 2 Musikboxen, eh klar ;)).

    Leider bootet einer der beiden Pis nicht.

    Ich hab wirklich schon einige Stunden in die Fehlersuche investiert, aber jetzt bin ich echt blank.


    So ist der aktuelle Stand:

    Ich habe wie gesagt 2 Pis, nennen wir sie Pi_A und Pi_B.

    Beide werden "headless" betrieben.


    Ich habe drei microSD Karten: SDX_1, SDX_2 und SD_3

    SDX_1 und SDX_2 sind für den Betrieb in den Musikboxen gedacht, SD_3 ist zum Testen.


    SDX_1 läuft mit Pi_A ohne Probleme.

    SDX_1 läuft in Pi_B nicht (mehr): Gestern war das noch möglich, heute kann ich auch mit SDX_1 den Pi_B nicht mehr ins WLAN bekommen.


    SDX_2 läuft in Pi_B nicht: Die rote und grüne LED leuchten dauerhaft. Heute morgen konnte ich Pi_B mit einer frischen SDX_2 mit der aktuellen buster lite noch via PuTTY ansprechen.

    SD_3 läuft in Pi_B nicht: Nur die rote LED leuchtet dauerhaft. SD_3 wurde ebenfalls frisch mit Balena und dem aktuellen buster lite geflasht. SD_3 lief früher erfolgreich mit dem Pi_A, wurde aber mittlerweile durch SDX_1 mit höherer Kapazität ersetzt.


    SDX_2 läuft übrigensallerdings in Pi_A ohne Probleme. Ich installiere dort gerade die Software für die (baugleiche) Box, die eigentlich mit Pi_B betrieben werden sollte.


    Gestern habe ich Pi_B zumindest noch kurz ins WLAN gebracht, auch heute Morgen ist mir das noch kurz gelungen. Allerdings ist die Verbindung schlecht gewesen, zumindest gab es immer eine ungewohnte Verzögerung beim Durchführen von Befehlen via CLI / PuTTY. Nach ein paar Minuten war die Box dann nicht mehr per WLAN erreichbar.


    Ohne SD blinkt Pi_B übrigens 4 mal mit der grünen LED, laut Sticky auf raspberry.org sollte also eigentlich alles OK sein.


    Ich bin echt verzweifelt. Hab ich den Pi_B zerstört?

    Weiß jemand von euch noch weiter bzw. hat eine Idee?