Posts by schlizbäda

Registriere dich jetzt, um exklusive Vorteile zu genießen! Als registriertes Mitglied kannst du Inhalte herunterladen und profitierst von einem werbefreien Forum.
Mach mit und werde Teil unserer Community!

    Servus Euromaster82 , willkommen im Forum!


    Das Pythonskript kann so nicht funktionieren. Es fehlen die Einrückungen des Codes in der Funktion def hello():.

    Bitte zukünftig Code immer in einen Codeblock einfügen. Sonst löscht die Forensoftware vermeintlich unnütze Leerzeichen.


    Was mir sonst noch spontan einfällt:

    * Audioeinstellungen in der /boot/config.txt

    * Probehalber mal mit einer MP3-Datei anstelle von WAV testen.

    Wenn Bildschirm und Tastatur am RPi hängen ein Terminalfenster öffnen und dort das Kommando ip addr eintippen. In der Ausgabe stehen alle Netzwerkschnittstellen samt ihrer IP-Adressen. Interessant ist eth0, die LAN-Schnittstelle.

    Wenn dort eine gültige Adresse angezeigt wird (an der Fritzbox meist etwas wie 192.168.178.xxx), kann man ja nochmals von einem anderen PC aus ebenfalls über das Terminalfenster (oder auf einem Windows-PC mit cmd.exe oder PowerShell) einen Ping auf den RPi ausführen:

    ping 192.168.178.xxx


    Wenn seinerzeit auf dem RPi eine feste IP-Adresse vergeben wurde anstelle von DHCP, kann es natürlich sein, dass Du damals eine IP abweichend von 192.168.178... vergeben hast. Die ist dann (ohne Anpassungen) von der Fritzbox nicht mehr so ohne Weiteres erreichbar.

    Hi DJ1NG ,


    die softwaremäßige Auswertung der GPIO-Pins hat Dir ja __blackjack__ schon skizziert.


    Da es sich hier um ein Audioprojekt handelt, empfehle ich Dir dringend, die I2S-Pins nicht zu verwenden:
    Pin 12 (GPIO18) = PCM_CLK

    Pin 35 (GPIO19) = PCM_FS

    Pin 38 (GPIO20) = PCM_DIN

    Pin 40 (GPIO21) = PCM_DOUT

    Diese Pins sind für eine Audiowiedergabe per I2S (PWM) durch den RPi notwendig. Werden diese Pins anderweitig verwendet, so stehen sie nicht mehr für I2S zur Verfügung und man sperrt damit für dieses Projekt alle DAC-Soundkarten für den RPi wie z.B. den Hifiberry DAC+ grundsätzlich aus!

    Wenn es nicht der brutale Wumms sein muss, empfehle ich ganz klar den Hifiberry MiniAmp. Der hat die gleiche Platinengröße wie der RPi Zero. ClassD-Verstärker mit 2x3W


    Werbung:

    Ich kann Dir auch mein RPi400ExtBrd anbieten. Es hat aber die Größe eines RPiHAT für RPi1,2,3,4 plus Buchsenleiste für den RPi400. Hierbei handelt es sich um einen ClassAB-Verstärker mit 2x2W.


    Der andere Unterschied ist, dass beim MiniAmp der etwas einfachere DAC PCM5101A verbaut ist und bei meinem Board der DAC PCM5122 vom Hifiberry DAC+.


    Nur so nebenbei:

    Ich habe seinerzeit auch die beiden Hifiberry-Baugruppen durchgemessen und davon die Stromlaufpläne gezeichnet:

    Stromlaufplan HifiBerry DAC+

    Stromlaufplan HifiBerry MiniAmp 1.0


    Stromlaufplan RPi400extBrd_2022_01_schematic.pdf

    * Wie lange wartest Du bei der Meldung "init: running system"? Sowas kann bei den diversen kodi-Betriebssystemen tatsächlich länger dauern (mitunter 30min?) . Die Geschwindigkeit hängt auch von der verwendeten SD-Karte ab. Ich rate nur noch zur Sandisk Extreme. Siehe Meine Tipps und Mitwirkungen, Teilüberschrift "SD-Karten für den RPi" --> bitte runterscrollen!


    * Nur nochmals nachgefragt: Du verwendest schon das richtige Image für den RPi4?
    Achtung: es ist noch im beta-Stadium, d.h. es kann noch zu Problemen kommen...


    * Flashen der SD-Karte mit dem RPi-Imager (Download hier)

    Dort den letzten Menüpunkt "benutzerspezifisches Image" (oder so ähnlich und auf englisch) wählen, die xbian-Imagedatei wählen und die SD wird geflasht.


    * Bitte nicht PINN zum Flashen der SD-Karte verwenden, das ist nämlich ein Ableger von diesem unsäglichen NOOBS!

    Eine SD-Karte zur Aktualisierung des RPi4-Bootloaders kann man doch mit dem RPi-Installer der Foundation erstellen:
    * SD-Karte mit dem entsprechenden Menüpunkt erstellen (Wortlaut kenne ich gerade nicht, ist aber selbsterklärend)

    * RPi4 mit dieser SD-Karte einmal booten. Am besten mit angeschlossenem HDMI-Bildschirm...

    Diese Anleitung ist ja gar nicht mal soo schlecht...


    Ich würde für ein "Zurück" wie folgt vorgehen:

    1. Trotz allem ein dd-Backup oder ein raspibackup (d.h. einen Klon) Deiner kompromittierten Installation machen, bevor noch mehr kaputt geht...
    (EDIT: Eine Sache, die eigentlich in Deiner verlinkten Anleitung steht)

    2. Zunächst mal auf einer anderen SD-Karte das aktuelle RaspberryPi-OS der RPi-Foundation aufspielen und zwar die ursprüngliche Variante (lite, with desktop, with desktop and recommended software), die auch auf Deiner kompromittierten Karte ist.

    3. von dem soeben erstellten jungfräulichen System die /etc/apt/sources.list auf das kompromittierte System übertragen. Wichtig: Dabei die kompromittierte Version nicht löschen/überschreiben, falls man sie noch braucht...

    4. Deine Anleitung abgewandelt in Form eines Downgrades von bookworm nach bullseye auf dem kompromittierten System durchführen:
    - ersten Teil mit sudo apt-mark showhold etc. wie beschrieben durchführen (ich weiß nicht, was das genau macht/bewirkt)

    - zweiten Teil in Form von "auf bullseye umstellen" durchführen. Dabei anstelle der Editierungen von /etc/apt/sources.list die vorhin geholte jungfräuliche Dateiversion einspielen und die Dateirechte entsprechend setzen:

    Bash
    ls -l /etc/apt/sources.list                             # Ausführliche Ausgabe u.a. mit Dateizugriffsrechten
    sudo mv /etc/apt/sources.list /etc/apt/sources.list.bak # Sicherungskopie erstellen
    sudo cp /Quelle/der/gesicherten/jungfräulichen/sources.list /etc/apt/sources.list
    ls -l /etc/apt/sources.list*                            # Ausführliche Ausgabe der neuen Variante anzeigen
    sudo chmod 644 /etc/apt/sources.list                    # Setzen der Dateizugriffsrechte der neuen Variante 

    Die chmod-Zugriffsrechte (644) sollten gemäß der tatsächlichen Flags angepasst werden, wenn sie nicht eh schon stimmen. Aber 644 ist für eine nicht-ausführbare Datei nicht ganz verkehrt.


    5. auch die non-free-Teile sollten mit der unberührten /etc/apt/sources.list bereits richtig sein

    6. Dann die "Aktualisierung in zwei Schritten" durchführen. Hier vermute ich, dass sudo apt-upgrade --without-new-pkgs wegen des Downgrades gar nicht nötig ist, aber ich weiß es nicht!


    Viel Glück!


    EDIT:

    ...und wenn Du Dich damit verzettelst, würde ich versuchen, die Installation von kodi, nextcloud und pihole gemäß deren Anleitungen auf der aktuellen RaspberryPi-OS-Version zu installieren. Das geht evtl. sogar schneller und ist vor allem eine saubere Sache.

    Wahrscheinlich wird es Dir leider nicht viel helfen, aber ein Release-Update z.B. von Buster auf Bullseye ist gerade bei RPi-OS meist mit Problemen verbunden. Ich gehe immer wie folgt vor:
    * Neues Release jungfräulich auf RPi installieren (z.B. auf einer anderen SD-Karte)

    * Meine manuellen Installationen auf dem neuen Release nachziehen (von denen ich mir zumindest immer Notizen mache)


    PS: laut RPi-Foundation gibt es doch von RPi-OS das Bookworm-Release noch gar nicht? Oder ist mir da etwas durch die Lappen gegangen?

    Gerade bei Updates auf solche unstable-Varianten ist die Gefahr eines Datenverlusts doppelt groß.

    Ich hoffe Du hast nicht rpi-update verwendet

    ich verweise mal auf meinen Raspiblaster mit all seinen Irrwegen :)


    Ich habe mich damals für audacious entschieden wegen grafischer Oberfläche für meine Kinder,

    ansonsten MPlayer (war eher ein Reinfall)

    oder der Alsaplayer mit Geschwindigkeitsanpassung (pitch)


    oder evtl. mit kodi (OSMC, libreElec, xbian)

    Als echter Linux-Dauernoob mache ich mir bei allen Installationen immer Notizen, wie ich es gemacht habe, mit welchen bash-Befehlen im Terminalfenster etc. Dies schreibe ich mir tatsächlich so auf, wie ich es später in der Doku für meine öffentlichen Projekte auf github niederschreibe (z.B. Anleitung Raspiblaster, Kapitel 3 und Kapitel 4).


    Bei einem Release-Update (buster-->bullseye) erstelle ich grundsätzlich eine neue SD-Karte mit dem aktuellen OS und ziehe dann die Installation gemäß meiner Notizen durch. Wenn's uferlos wird, wie z.B. bei meinem yamuplay (mittlerweile leider veraltet wegen omxplayer), erstelle ich auch bash-Skripte (yamuplay-setup.sh) für die notwendigen Installationsschritte.


    Bei fremden, mitunter chaotischen Projekten (z.B. Phoniebox) konnte ich mich schließlich zu never touch a running system durchringen. :)


    Und grundsätzlich mache ich von meinen Projekten eine dd-Sicherung mit piShrink, um sie jederzeit wieder (Achtung: Unwort!) schnell in Betrieb nehmen zu können. Denn: Kein Backup, kein Mitleid!

    Laut RPi-Foundation kann am RPi 3B nur der USB Host Boot Mode aktiviert werden. Dazu muss ich sagen, dass ich USB Boot selbst noch nie ausprobiert habe, aber ich würde anfangs strikt nach der verlinkten Beschreibung vorgehen.


    Von der 16GB SD-Karte würde ich per dd ein Image ziehen und dieses anschließend auf die USB-SSD flashen, d.h. mit dd auf die SSD draufkopieren. Alternativ mit dem RPi-Imager arbeiten. Der ist eigentlich nix Anderes als ein grafisches dd, aufgemotzt mit ein paar RPi-spezifischen Optionen.

    Durchschlagender Erfolg -- jetzt auch für Telegram


    Hier die Download-Seite für die Telegram-Äpp als APK-Paket:
    https://telegram.org/android (68,8 MB)


    Die Installation werde ich mir morgen zu Gemüte führen...


    Auch bei Telegram war's jetzt einfach:
    Mit der heruntergeladenen Äpp vom Hersteller war's jetzt auch hier babyleicht.


    ...und damit tue ich mich jetzt leicht mit Zähneputzen, pullern und ab ins Bett!