Posts by schlizbäda

    Lokal am PC ist pishrink.sh sauschnell.

    Am RPi wird es sicherlich langsamer sein, am schnellsten wahrscheinlich noch, wenn die Images auf einer (USB-)SSD liegen und nicht auf der SD.

    Ja und NAS (Netzwerkbetrieb) kann es auch noch ausbremsen.


    Und an der ellenlangen Kommandozeile bin ich schier verzweifelt. Ein "-" mit nem "_" im Backupnamen verwechselt.

    Na ja, Gefahr erkannt, Gefahr gebannt.


    Dann das geshrinkte Image auf eine andere SD-Karte flashen und testen, ob das System davon erfolgreich startet. Erst dann ist der Vorgang wirklich abgeschlossen!

    [...] und soweit mir scheint, kann ich sogar noch funktionsfähige Images erstellen. Aber den Vorteil, dass ich es mit wenigen Clicks auch auf kleinere Datenträger übertragen könnte, sehe ich nur beim SD-Card-Copier.

    Wenn es nur ums Verkleinern von bereits erstellten Images geht, ist pishrink.sh Dein Freund.

    Hierbei handelt es sich um ein Shellskript, das die ext4-Partition eines RPi-Images auf seinen tatsächlichen Speicherbedarf (plus ein paar MBytes freier Plattenkapazität für temporäre Dateien etc.) reduziert. Außerdem kann beim Erstellen des verkleinerten Images eine "Aufblasefunktion" aktiviert werden, die beim ersten Booten die verkleinerte ext4-Partition wieder auf die Größe der (neuen) SD-Karte anpasst.

    Ich nehme das grundsätzlich für meine Imagesicherungen auf meinem Linux-PC her. Auf dem RPi selbst habe ich es noch nicht getestet. Ist halt kein Klickibunti, sondern eine Kommandozeile für's Terminalfenster.

    Zum Thema:

    Diesen sich vergrößernden Versatz von Bild und Ton hatte ich auch schon bei einer Installation von kodi direkt unter Raspberry Pi OS am RPi 3B (ohne Plus) und zwar beim Betrieb auf einem PAL-Röhrenfernseher (Zeitraum Dez. 2021, Weihnachtsferien).

    Mit dem aufspielen vom aktuellen OSMC auf die SD-Karte konnte ich das damals beseitigen. Was weiß ich, was für Einstellungen da anders waren? Ich glaube ich habe im Menüpunkt Settings von OSMC herumgespielt und die Frequenz/fps auf 50Hz gesetzt und noch so ein paar Sachen für den analogen Videoausgang an PAL angepasst.


    War auch so eine Sache, die vor ein paar Jahren bei OSMC out of the box funktioniert hat.

    Hi jar,


    bei Deinen Ausführungen muss ich Dir leider zustimmen.

    Raspberry Pi OS (aka Raspbian) : Keine Konstanz, nicht mal im Namen

    Zu dem ewig nervenden Umstellen und wieder zurück gesellt sich noch PulseAudio --> ALSA --> PulseAudio


    Meine "traurig"-Reaktion bezieht sich auf den Sachverhalt, nicht auf Deine Ausführung!

    EDIT:

    Auch meine Anleitungen sind davon betroffen und auch ich habe mittlerweile keinen Bock mehr, die aktuell zu halten... Weil: wie lange?

    Denn bei mir springt die Lautstärke hoch und runter, lässt sich nicht wirklich Steuern über den Poti.

    Lautstärkesprünge nur wenn Du am "Poti" (i.e. Rotary Encoder) drehst oder dauernd?

    Wenn das nur beim Drehen passiert, dann kann es sein, dass der Rotary Encoder (mittlerweile) verschlissen ist und die beiden Kontakte stark prellen, was der Software eine Auswertung des Drehsignals erschwert oder gar unmöglich macht.

    Lt. README-Datei sollten aber beide HDMI-Ausgänge, audio ausgeben

    können, oder?

    ja, irgendwas war da, das hatte ich auch im Hinterkopf. Hier wurde seitens der RPi-Foundation wohl mal software-/treibermäßig etwas erweitert.

    Anfangs, als der RPi4 erschien, war es tatsächlich so, dass nur HDMI0 Audio ausgeben konnte...

    ich bin diesbezüglich derzeit nicht ganz up-to-date, aber beim RPi4 läuft Audio AFAIK nur auf der Buchse HDMI-0, das ist die neben dem USB-C-Versorgungsstecker.


    Vielleicht kann man mit folgender Allzweckwaffe in der /boot/config.txt noch was drehen?

    dtoverlay=vc4-kms-v3d

    dtoverlay=vc4-fkms-v3d

    Beide Varianten testen, aber entweder-oder (XOR), nicht gleichzeitig!

    Nach kurzer Zeit ohne Aktivität an Maus und Tastatur ging der Monitor gerade aus, bis ich die Maus wieder bewegte. Ich nehme an, das war eine Standby-Abschaltung für die graphische Benutzeroberfläche? Wo stellt man die Zeiten hierfür ein?

    Das ist der Bildschirmschoner. Den kann man wie folgt deaktivieren:

    Editieren der Konfigurationsdatei lightdm.conf mit sudo nano /etc/lightdm/lightdm.conf

    Hier stehen viele Einträge (Zeilen). Im Abschnitt [SeatDefaults] den Eintrag xserver-command=... anpassen:

    Code
    [SeatDefaults]
    .
    .
    .
    xserver-command=X -s 0 -dpms
    .
    .
    .

    Ich habe den Bildschirmschoner mit obigem Eintrag bisher immer nur komplett deaktiviert. Vielleicht ist der Wert 0 hinter -s die Dauer (in Sekunden oder Minuten?) bis der Bildschrimschoner aktiv wird?


    EDIT:

    Wichtig dabei ist, das Kommentarzeichen # am Zeilenanfang beim gewünschten Eintrag ggf. zu entfernen!


    EDIT2:

    Doku siehe unter https://wiki.ubuntuusers.de/LightDM/#lightdm-conf

    Hi treasoner ,


    Mit "Original-Netzteil" meinst Du schon dieses bzw. dieses Netzteil mit der Aufschrift "Made in Cambodia"? Nur das ist das von der RPi-Foundation zertifizierte Netzteil. Nicht so ein angeblich originales (aukru oder goobay) mit "praktischem Ein-Ausschalter" -- gell hyle;)


    Die config.txt sollte auf dem RPi mit sudo nano /boot/config.txt editierbar sein. Wenn der Inhalt fehlt, ist entweder der Dateipfad falsch oder (schlimmer) die /boot/config.txt fehlt, kann nicht gelesen werden etc.

    EDIT:  rpi444 war schneller

    Hi Tobi4ever,

    willkommen im Forum!


    Ich habe mich mit RPi als Bluetooth-Lautsprecher auch mal vor einigen Jahren (damals noch unter Raspbian Stretch!) gespielt. Zumindest die Audiowiedergabe hat nach einigem Hin und Her schließlich funktioniert. Aber dann habe ich es nicht mehr weiter verfolgt. Siehe dieser Thread, Beitrag #13.


    Wichtig bei einem Bluetooth-Lautsprecher sind die beiden Bluetooth-Protokolle

    A2DP für die Audioübertragung

    AVRCP für die Fernsteuerung von anderen Geräten über Bluetooth (optional, habe ich nur recherchiert, nicht umgesetzt.)

    Dein Gerät müsste ein AVRCP-CT werden...


    Und Achtung:

    meine Beispiele beziehen sich auf Debian/Raspbian Stretch, mittlerweile sind wir zwei Major Releases weiter: Stretch --> Buster --> Bullseye


    Ach ja,
    es stört niemanden, wenn Du Deinen bisherigen Code hier samt Hinweisen zur Installation darbietest.

    Hier zieht vermutlich sogar beides Strom im abgeschalteten Zustand:

    1. Die Letos (eh klar) -- Die musst Du in Deinem Aufbau an einem zweiten Port gesondert abschalten, z.B. über ein Relais.

    2. der RPi wird ohne Zusatzelektronik (z.B. OnOffShim von Pimoroni) nicht vollständig abgeschaltet! Es fließen z.B. beim RPi3B nach wie vor 80-90mA, auch wenn der RPi heruntergefahren ist. Erst der OnOffShim schaltet den RPi komplett aus. (Bei mir machte er dann noch Zicken, die ich ihm erst abgewöhnen musste.)

    Beim RPi Zero könnte die Last nach dem Herunterfahren niedriger sein als beim RPi3, sie wird aber auch reichen, um den Akku relativ schnell zu entladen...

    Hi splitti79,


    1. Monoausgabe: nein

    Sollte theoretisch eigentlich funktionieren. Ich habe es mal kurz ausprobiert und es hat leider nicht wie erwartet funktioniert, der Grund war mir unklar. Genaueres weiß ich vom damaligen Test nicht mehr. Ich werde es aber nochmals testen und hier berichten.


    2. Wegen des Layoutfehlers an der Cinchbuchse gebe ich das Board zum Selbstkostenpreis von 30,--€ ab.

    Was mir hier besonders aufgefallen ist, dass besonders der Dateityp MPG davon betroffen ist. Ich habe hier ein Liste nun aus dem dreifachen Vergleich, wo besonders viel solche Videofiles alle in diesem Format, den gleichen HASH wert haben, zum Teil nur wenige Byte, bis einige KByte groß sind, aber bei Vergleich in der Wiedergabe offensichtlich fast den selben Inhalt haben !? :conf:

    Kann es sein, dass es sich bei den Dateien, die nur aus wenigen Bytes bestehen, um Links auf größere Dateien handelt? Ein Video, selbst ein kurzes mit geringer Auflösung ist sofort im höheren kByte-Bereich.


    Wenn es symbolische Links sind, dann musst Du aufpassen, dass der Link gelöscht wird und nicht die tatsächliche Videodatei. Und ja, symbolische Links gibt's auch in Windows bis runter zum Dateisystem VFAT: Es sind die sogenannten Verknüpfungen.


    MD5-Prüfsumme oder andere Hashalgorithmen:

    Ihnen allen gemeinsam ist, dass nur ein exakt gleicher Inhalt zum gleichen Hashwert führt. Ändert sich auch nur ein Bit in nur einem Byte der zu hashenden Datei, liefert ein (guter) Hashalgorithmus einen vollkommen anderen Hashwert. Dass Dateien unterschiedlicher Größe den gleichen Hashwert liefern, ist bei ausreichender Bitbreite des Hashalgorithmus praktisch unmöglich. (Auch wenn Google es vor ein paar Jahren geschaft hat, sogar SHA1 zu knacken, indem es zwei PDFs mit unterschiedlichem Inhalt, rotes und blaues Rechteck, so manipuliert hat, dass der gleiche Hashwert herauskommt: Es wurden unter relativ hohem Rechenaufwand entsprechende Füllbytes in beide PDFs eingefügt, so dass am Ende der Hashwert beider Dateien gleich war)


    Grundsätzlich sind für mein Dafürhalten zur Videoprüfung auf Ähnlichkeit ganz andere Algorithmen heranzuziehen. Selbst die (verlustfreie) Umwandlung in ein anderes Videoformat bedingt aus obigen Gründen abweichende Hashwerte. Das Hashen taugt nur zum Vorsortieren und Eliminieren von Duplikaten.


    EDIT1:
    Gut, den Videohash kenne ich jetzt nicht, aber ich schätze, dass sich auch der die Zähne ausbeißt, spätestens wenn sich die Videoauflösung ändert. Im Wesentlichen bleibe ich bei meiner persönlichen Einschätzung aus Beitrag #27.


    EDIT2:
    Beinhalten die Videodateien Metadaten? Dann könnte man die extrahieren und vergleichen...

    Bei den alten Dateien aus ursprünglich analogem Material sind die Metadaten wahrscheinlich leer oder immer gleich.


    EDIT3:
    noch eine Idee:

    Die Länge der Videos ermitteln und alle Dateien ausspucken, deren Länge sich um weniger als 2(?) oder 5(?) Sekunden unterscheidet


    Zu meinem großen Erstaunen, hat diese Hash- und Größenvergleichs Analyse hervorgebracht, das auf dieser Platte über 15.000 doppelte oder mehrfach vorhandene Dateien gefunden wurden. :gk1:

    An dieser Stelle würde ich mit dem Ausmisten beginnen und die 1:1-Duplikate (halbwegs automatisiert) löschen, indem Du die Logdatei aus Deinem Programm in ein Shellskript umeditierst, à la

    Bash
    rm /pfad/zu/datei1.mp4
    rm /pfad/zu/datei2.avi
    .
    .
    .
    # anschließend Löschen von leeren Verzeichnissen

    Mit etwas Glück wird der Verzeichnisbaum damit erheblich zurückgeschnitten und die Anzahl der übrigen Dateien wird überschaubar?


    -- WICHTIG --

    Eine Sicherungskopie unterstelle ich an dieser Stelle mal.