Invidious: The media could not be loaded format not supported

Invidious ist eineSoftware, die es ermöglicht, Videos von YouTube anzusehen, ohne direkt die offizielle YouTube-Website, oder App zu verwenden. Die selbstgehostete Software ermöglicht eine werbefreie Nutzung von Youtube und schützt die Privatsphäre der Nutzer, indem es Tracking durch Google verhindert. Invidious bietet die weiteren Funktionen wie das Herunterladen von Videos, das Ansehen ohne Anmeldung und die Möglichkeit, nur den Audiostream abzuspielen.

Ich hatte nun etwas länger meine private Instanz auf dem Homeserver genutzt und stieß auf den Fehler
„The media could not be loaded, either because the server or network failed or because the format is not supported“.

Damit die Software wieder produktiv arbeitet, muss hier ein weiterer Container erstellt und die Datei docker-compose.yml für Euren Stack umgeschrieben werden.

Als Erstes wird ein einzelner Container via

 docker run quay.io/invidious/youtube-trusted-session-generator

gestartet und nach einem Start die Ausgabewerte des Containers für visitor_data und po_token kopiert.
Dieser Container beendet sich nach der Ausgabe von selbst und sollte nicht detached gestartet werden.

docker run quay.io/invidious/youtube-trusted-session-generator
[INFO] internally launching GUI (X11 environment)
[INFO] starting Xvfb
[INFO] launching chromium instance
[INFO] launching browser.
[INFO] waiting 10 seconds for the page to fully load.
visitor_data: TOLLERHASHWERT1
po_token: TOLLERHASHWERT2
successfully removed temp profile /tmp/uc_3aimnef0

Jene Werte habe ich, inklusive des neuen Containers, in die Datei docker-compose.yml eingepflegt.

version: "3"
services:
  invidious:
    image: quay.io/invidious/invidious:latest
    container_name: invidious
    restart: unless-stopped
    ports:
      - "4000:3000"
    environment:
      INVIDIOUS_CONFIG: |
        db:
          dbname: invidious
          user: kemal
          password: kemal
          host: invidious-db
          port: 5432
        check_tables: true
        signature_server: inv_sig_helper:12999
        visitor_data: TOLLERHASHWERT1
        po_token: TOLLERHASHWERT2
        quality: dash

        registration_enabled: false
        top_enabled: false
        related_videos: false
        comments: ["",""]
        login_enabled: false
        domain: TOLLERFQDN
        hmac_key: "BLABLABLABLABLA"

    depends_on:
      - invidious-db
    logging:
      options:
        max-size: "1G"
        max-file: "4"

  inv_sig_helper:
    image: quay.io/invidious/inv-sig-helper:latest
    init: true
    command: ["--tcp", "0.0.0.0:12999"]
    environment:
      - RUST_LOG=info
    restart: unless-stopped
    cap_drop:
      - ALL
    read_only: true
    security_opt:
      - no-new-privileges:true
  invidious-db:
    image: docker.io/library/postgres:14
    restart: unless-stopped
    container_name: invidious-db
    volumes:
      - ./postgresdata:/var/lib/postgresql/data
      - ./config/sql:/config/sql
      - ./docker/init-invidious-db.sh:/docker-entrypoint-initdb.d/init-invidious-db.sh
    environment:
      POSTGRES_DB: invidious
      POSTGRES_USER: kemal
      POSTGRES_PASSWORD: kemal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB"]
    networks:
      - default

Weiterführende Informationen bezüglich einem Fehler mit sigv_helper und kontobasierter Authentifizierung finden sich in der Issue 4947 auf Github

Viel Spaß mit Invidious.

macOS: LibreOffice nicht aus Apples App Store installieren

Einmal wollte ich faul sein und gleichzeitig einem FOSS-Projekt etwas Gutes tun. Anstelle mich immer selbst um ein Update von LibreOffice zu kümmern, wollte ich es aus dem Apple App Store installieren, via selbigen an das Projekt spenden und die Downloadzahlen im Store um eine Wertigkeit erhöhen. Automatische Updates im Hintergrund sollten hier die Wahl sein. Als gewissenhafter Verbraucher beobachte ich, die von mir installieren Pakete und deren Projekte auf Neuigkeiten und vor allem auf Sicherheitsmeldungen. Im Falle von LibreOffice gab es hier ein Sicherheitsproblem in der Version 7.6.6, welche mit der Version 7.6.7 relativ zügig behoben wurde.
Das Sicherheitsrelease ist bis heute nicht in Apples App Store angekommen.

Weiterlesen

Neues Theme in WordPress neue Darkmode CSS

Im Frontend ändert sich mein Blog nur noch marginal. Jedoch musste ich mich aufgrund von Änderungen im Sourcecode von WordPress für ein anderes Theme entscheiden. Zuvor hatte ich ein Theme von einem deutschen bekannten Entwicklerpaar gekauft, aber leider endet hier der Support doch recht schnell. Auch Bugfixes, welche ich einmal auf Github eingereicht hatte, wurden erst nach zwei Jahren (🦉really?!?!) eingepflegt. Es ist eher ein „Aus den Augen, aus dem Sinn“-Coding und ich würde hier kein Geld mehr investieren.

Weiterlesen

Entfernen des gist-Plugins und YouTube aus WordPress

Ich habe nun das nächste Plugin aus WordPress entfernt. Auch habe ich mir nochmals Gedanken über dieses Plugin gemacht und es ist definitiv nicht Datenschutz konform, wenn ich Daten aus Github nachgeladen habe. Ich hatte zwar somit immer die neueste Version des Codes eingebunden, aber es war eigentlich eine Faulheit auf Kosten der Lesenden.

Im Moment suche nun Shortcodes mit der Bezeichnung gist id=“ und kopiere den Inhalt dieser Gists in den Fließtext. Die richtige Aufgabe während meiner Krankmeldung. Falls ich mich mit etwas anderem als im Bett liegen und Hörbuch hören befassen möchte. Für das Teilen von Code habe ich mir noch keine Gedanken gemacht, aber es wird definitiv selbst gehostet und sollte keinen großen Pflegebedarf haben. Bis jetzt habe ich hier leider noch nichts gefunden. Gitlab und ähnliche Projekte wären mit Kanonen auf Spatzen geschossen. Gitweb wäre ein Lösung, habe ich noch nicht im shared Hosting noch nicht getestet.

Vor sehr langer Zeit war es einmal in der Blogosphäre gang und gebe die Videos der Plattform YouTube einzubinden. Damit ich hier nicht mit den Daten der Lesenden hausieren gehe, hatte ich das Plugin „Lazy Load for Videos“ installiert. Diese direkten Links wurden nun gegen normale ausgetauscht

Ich konnte mir viel Handarbeit wieder zwei Plugins deaktivieren und entfernen.
Mittlerweile sind nun 9 Plugins deaktiviert bzw entfernt worden.

Plugin WP-Appbox für WordPress deaktiviert

WP-Appbox ist ein wunderbares Plugin, welches vielfältige Darstellungsmöglichkeiten für die Verlinkung verschiedener Apps bietet. Das Plugin war bei mir seit 2013 in Benutzung. Ich habe es erstmals bei dem Blogbeitrag Ownstagram ein eigenes Instagram verwendet. Das Plugin bindet verschiedene Stores anhand eines Shortcodes ein und zieht sich hier die gewünschten Daten aus dem Shop. Ein verlässliches Plugin, welches ich immer empfehlen würde. Aber ich habe es nicht wirklich gebraucht.

Da ich WordPress gerade auf ein exportierbares Minimum migriere, war es für mich klar, dass auch dieses Plugin aus meiner Installation verschwindet. Leichter gesagt als getan. Der Shortcode der App beinhaltet appbox und dieser befindet sich in 32 Blogeinträgen und dort als mehrmaliger Eintrag.

Beispielcode von WP-Appbox. Einträge 1,2 verweisen auf Apples Store , Einträge 3 und 4 auf den Google Playstore
[appbox appstore id654810212]
[appbox appstore id1062526415]
[appbox googleplay com.freeletics.lite]
[appbox googleplay com.freeletics.android.running]

Hier habe ich nun jeweils den Code gelöscht, die echten URLs herausgesucht und in den Text eingepflegt. Dabei ist mir aufgefallen, dass das Plugin auf viele Leichen verwiesen hatte. Diese gebrochenen Links sind auch dem WordPress-Plugin Link Checker nicht aufgefallen und gemeldet worden. Von diesem nutze ich noch die alte lokale funktionale Version. Auch dieses Plugin drückt es langsam in die Cloud und falls eine lokale Verifizierung der Links nicht mehr möglich ist, muss ich mich um eine Alternative kümmern.

Es ist ein wenig Arbeit, um einfach nur aus der Insellösung zu kommen. Bei den Galerien hatte ich aufgepasst, hier wurde FooGallery bei mir installiert. Auch diese besitzt Shortcodes, baut aber auf der Mediengalerie von WordPress auf. Wie bei anderen Plugins erfolgt hier kein Aufbau einer eigenen Mediengalerie wie bei anderen Plugins. Die Galerien müsste ich händisch nachbauen.

Cookieless WordPress seit heute

Ich habe nun meine Bannermeldung nach dem Telekommunikation-Telemedien-Datenschutz-Gesetz (TTDSG) abgeschaltet.
Siehe hierzu auch das Urteil des Bundesgerichtshofs vom 28. Mai 2020, Aktenzeichen I ZR 7/16.
Ich betrieb meine Installation von Matomo schon so, dass seitens Matomo keine Cookies gesetzt wurden. Durch das Abschalten der Kommentarefunktion in WordPress konnten auch hier auf Cookies verzichtet werden.

Weiterlesen

Auf ein Minimum in WordPress

Nach über 14 Jahren Gebrauch ist WordPress eine Art von Hassliebe. Es ist nicht so, dass ich nicht andere Plattform für das Schreiben im Netz ausprobiert hatte. Ich startete mit WordPress, besuchte Drupal,Octopress und Serendpity, um am Ende doch wieder bei WordPress zu landen.

Somit sitze ich im Moment vor meinem, doch in die Jahre gekommen Blog, und beginne aufzuräumen. Ausgeschaltet habe ich die Kommentarfunktion und konnte hierdurch nun zwei Plugins schon abschalten. Des Weiteren löse ich ein Plugin aus, welches mit Shortcodes eine eine bessere Verlinkung in verschiedene Appstore ermöglichte. Anhand der ID in Shops ließen sich hier automatisch QR-Codes und Screenshots in den Beitrag einbinden. Es dreht sich hier nicht Affiliate-Links. Etwas Arbeit, aber ich brauche es wirklich nicht mehr.

Nach einigen Hin und Her war ich kurz davor eine Migration in Jekyll für das Blog vorzunehmen. Ein statisches Blog hat Vorteile, wie auch Nachteile. Ich hätte serverseitig ein gutes Gefühl, aber betreffend der Arbeit an einem Blog bin ich mir nicht sicher, ob ich dies alles so möchte. Ich bin diesen Weg schon einmal gegangen. Wobei mein Ablauf für ein statisches Blog prädestiniert wäre.

Mein jetziger Ablauf für einen Artikel sieht so aus, dass ich unter Linux, oder macOS, mit Typora meine Posts in Markdown verfasse und dann in WordPress nochmals neu formatiere. Mit Jekyll würde ich hier mir mehr als einen Weg sparen. Aber ich müsste hier zum Beispiel auf zwei bei gute Plugins verzichten müssen, sowie auf den Import der alten Kommentare. Einmal schnell im Web weiterzuarbeiten ist hier keine Option, obwohl diese bei mir nie eigentlich eine Rolle spielt.

Vorerst also bei WordPress auf das nötige Beschränken an Plugins beschränken und dann sehe ich einmal weiter. Es besteht ja die Möglichkeit auch einmal zweigleisig zu fahren und bei Bedarf umzuschalten. In WordPress gibt es die Möglichkeit, Dateien im Format Markdown in WordPress zu importieren. Ich muss auf jeden Fall raus aus den Insellösungen der Shortcodes durch Plugins. Dann wäre das Migrieren und vielleicht auch der Rückweg eine Sache von Minuten. Der Import in Jekyll lokal hat mir hier ein kleines Grauen offenbart.

Fork: Grafischer Git-Client für macOS

Ich habe mich nach einer kleinen Testphase gegen GitKraken und für Fork als grafischen Client für Git unter macOS entschieden.
Gitkraken mag ein hervorragendes Werkzeug sein, aber das Abomodell hat mich abgeschreckt. Ich möchte noch erwähnen, dass GitKraken ein Studenten- und Universitätspaket anbietet. Ich werde vielleicht GitKraken Kollegen:innen an meinem Arbeitsplatz für einen Test vorschlagen. Dann können wir einmal nochmal einen direkten Vergleich vornehmen.

Für mich kam dieses Paket nicht infrage, da ich aus meinem Arbeitsplatz nicht einen Vorteil ziehen will. Die Lizenz möchte ich auch Privat nutzen und meine Frau würde sich auch über einen besseren Client freuen. Fork bietet mit hier die Möglichkeiten für 3 Installationen auf verschiedenen Systemen. Hiermit kann meine Frau unter Windows Fork nutzen. Leider bietet Ihr Arbeitgeber nur dieses Betriebssystem und keine Alternativen.

Natürlich könnten viele Aufgaben direkt in der Entwicklungsumgebung, oder via Shell gelöst werden. Ich will auch die Möglichkeiten einer besseren Visualisierung benutzen können. Diese sind dort nicht immer gegeben, beziehungsweise haben nicht dieses Aussehen wie in Fork. Neben den typischen Aufgaben eines Clients für git, bietet Fork noch Unterstützung für zum Beispiel git-flow und git LFS.

Als Haken könnte ich den Preis von 55,34 € für eine Lizenz erwähnen. Diese Lizenz beinhaltet drei gleichzeitige Installation für eine:n Entwickler:in. Ein Blick in die rege Entwicklung von Fork durch die Entwickler Tanya und Dan Pristupova, lässt mich positiv in Zukunft schauen. Hier möchte ich auch nochmals auf das Blog der Entwickler hinweisen.

Eine Sache ist mir noch sehr wichtig. Die Wahl wäre eher auf GitKraken gefallen, wenn ich für meine Arbeit und Privat nicht macOS nutzen würde. GitKraken unterstützt Linux deb,tar.gz,rpm und Snap. Sowie auch Mac mit Apple Silicon/Intel und Windows.
Aber hier bleibt der für mich der noch etwas freche, und mehr als bittere, Beigeschmack der Anzahl der Verbindungen zu einer Instanz für 4 € monatlich. Sie beträgt 1 Verbindung, siehe Screenshot. Das bedeutet, ich muss das Paket für 12 € monatlich abonnieren, um meinen Bedarf abzudecken.

Umzug zu von TinyTinyRSS zu FreshRSS

Ich bin nun nach einigen Dekaden von TinyTinyRSS komplett zu FreshRSS umgezogen. Der zwei Hinderungsgründe des verspäteten waren das Theme und die Tastenkürzel. Bei TinyTinyRSS war mir das Theme Feedly-Theme doch sehr an das Herz gewachsen und eine Alternative ist leider unter FreshRSS nicht zu finden. Auch empfand ich die Tastenkürzel unter TinyTinyRSS doch ein wenig besser, da hier jeder Befehl erst einmal mit dem Drücken der Taste F eingeleitet wurde. Das Backend mit seinen Funktionen gefällt mir sehr. Hier hätte sich TinyTinyRSS noch einiges anschauen können.

Die OPML-Datei ließ sich schnell und einfach, inklusive der Ordnerstruktur, importieren. Ich musste nur noch einen Timer für den systemD Service, welcher zu jeder Stunde zur vierzigsten Minute läuft, erstellen.

Als Clients nutze ich unter iOS Unread, unter iPadOS und macOS ist FieryFeeds. Insofern ich Zeit finde, werde ich mich um ein Theme für FreshRSS kümmern. Ich ziehe einen einen Webclient für meinen RSS-Feeds vor.