Posts by kls

  • Empfehlung für GIT-Server

    Ich bin gerade dabei, ein Script zu schreiben, welches mein RCS in ein GIT verwandelt. Das Ergebnis möchte ich dann auf meinem Server (tvdr.de) mit einem eigenen GIT-Server zur Verfügung stellen, damit es künftig keine "Beschwerden" mehr wegen eines fehlenden "offiziellen" GIT-Archivs oder "Patch-Orgien" gibt ;-).


    Ich selber werde weiterhin mit meinem guten alten RCS arbeiten und meine Änderungen fallweise automatisiert ins GIT übertragen. Das GIT wird als quasi ein read-only Abbild meines RCS sein.

  • Empfehlung für GIT-Server

    Welche Software eignet sich denn am besten, um einen GIT-Server zu betreiben?

    Er sollte ein Web-Interface haben, mit dem man alle Tags und Branches anzeigen lassen und Versionsstände auschecken kann (auch als Archiv).

    Was es nicht braucht sind Pull-Requests oder Issue-Tracker (sollte, falls vorhanden, abschaltbar sein).

  • Raspberry Pi 4B Unterstützung

    Das Problem hatte ich auch, auf drei verschiedenen RasPis. Damals hatte ich 8GB SD-Karten von Kingston in Verwendung, die regelmäßig kaputtgingen. Seit ich auf 4GB-Karten von Transcend umgestiegen bin, laufen sie problemlos und stabil. Wobei ich nicht sagen kann, ob es am Hersteller liegt oder daran, dass die neuen Karten 4 statt 8GB haben.

  • I2C Timeouts mit ddbridge

    SHF wrote:

    Naja, die CorrErr+ hatte die DD-Karte auf dem Board doch auch?

    Aber nur auf der "Gegenseite":

  • I2C Timeouts mit ddbridge

    Sorry, hat etwas gedauert, weil ich erst die Freigabe von DD für die angehängten Bilder erfragen musste.

    Die aktuelle Aussage von DD ist, dass es sicher am HW-Design des ASRock J3455M Motherboards liegt, wie die angehängten Screenshots ihres PCIe-Analyzers zeigen sollen.

    Die Erklärung von DD dazu:

    "Asrock_Crash zeigt ein "Nak" bei dem zuvor keine Datenpakete unterwegs waren. Danach werden Pakete nicht mehr acknowledged " ak" was dann nach kurzer Zeit zum crash führt. Das Zweite Bild Zeit weiter "Naks" die nicht zum Crash führten aber nicht vorkommen dürften. Dem Hersteller muß das Problem bekannt sein, da er das Problem von der 1.4 Firmware bis zur 1.6er Firmware deutlich verbessert hat, aber offensichtlich geht die Lösung nicht weit genug. Wir versuchen gerade herauszufinden was der Hersteller hier geändert hat. Wir nutzen mit der gleiche CPU ein Board von Faytech ( FAY003 gefertigt von ASUS) das ein solches Verhalten nicht aufzeigt."


    Man ist wohl mit ASRock in Kontakt, aber ob sich von deren Seite was tut, ist ungewiss.


    Mit dem J4105M läuft die DD-Hardware dagegen soweit stabil.

  • [2.4.1] Skincurses zeigt keine Ausgabe auf SSH-Konsole

    Kann ich bestätigen :-(.

    Mit der skincurses.c aus Version 2.4.0 funktioniert es.

    Ulrich Eckhardt : kannst du dazu was sagen? Von dir stammt ja der Patch, den ich (bis auf eingefügte Blanks, wobei ich jetzt sehe, dass ich noch zwei Stellen übersehen hatte) 1:1 übernommen habe. Allerdings habe ich es wohl aus Zeitgründen nicht selber getestet, sondern mich darauf verlassen, dass es bei dir funktioniert hat...

  • Patches für VDR 2.4

    In der endgültigen Version 2.4.1, die ich soeben freigegeben habe, ist in recording.c noch eine Änderung mit drin, die das .update-File auch nach dem Entfernen gelöschter Aufnahmen getoucht wird, so dass andere VDRs, die das selbe Video-Directory verwenden, nicht zu viel freien Plattenplatz anzeigen.


    In vdr.c wurde an einer Stelle die Einrückung korrigiert. Also nicht wundern, wenn es einen Unterschied zu den hier geposteten Patches gibt.

  • 06-fix-channel-switch Patch verursacht OSD Fehler

    Das Problem ist inzwischen geklärt. Es liegt an einem Fehler in der DrawText() Funktion von rpihddevice für den Fall, dass der String leer ist. In VDRs DrawDeviceData() (skinlcars.c) ist DeviceType wegen des mit vdr-2.4.0-06-fix-channel-switch.diff eingeführten cControl::Shutdown() leer, was den Fehler triggert.


    Thomas weiß Bescheid und hat vor, das am Wochenende zu fixen.

  • Compiler warning

    Da hat er recht.

    Es muss heissen:


    esyslog("ERROR: can't copy file name '%s'", FileName);


    (fileName -> FileName)


    Wobei, wenn er an diese Stelle kommt, ist eh alles aus... ;-).

  • Patches für VDR 2.4

    Der Patch http://ftp.tvdr.de/Developer/P…dex-vs-device-number.diff behebt inkonsistentes Verhalten bei Verwendung der Option '-D' um nur bestimmte Devices auszuwählen. In einem solchen Fall stimmten z.B. die im "Edit channel" Menü unter CA eingegebenen Nummern für die feste Zuweisung eines Kanals an ein Device nicht mit den im Hauptmenü und der Kanalanzeige (bei der LCARS-Skin) angezeigten Device-Nummern überein. Auch bei Log-Meldungen gab es einige Irritationen, welches Device denn nun gemeint war. Ich habe das jetzt so geändert, dass der bisher an vielen Stellen verwendete CardIndex() durch DeviceNumber() ersetzt wurde. CardIndex() wird jetzt nur noch im Zusammenhang mit der Option '-D' verwendet. Wann immer ansonsten von einer "Device Nummer" die Rede ist, ist es eine Nummer von 1...N, wie sie im LCARS-Hauptmenü angezeigt werden.


    Genau genommen ist der Returnwert der Funktion cDevice::DeviceNumber() unlogisch, denn "Nummern" sollten immer von 1 losgehen. Wenn etwas bei 0 startet, ist es eher ein Index. Da aber vermutlich etliche Plugins diese Funktion so wie bisher definiert verwenden, kann ich das schlecht ändern. Ich werde daher wohl später eine neue Funktion cDevice::DeviceNum() (oder vielleicht einfach cDevice::Number()) einführen, die direkt die Nummer des Devices (ab '1') liefert, so dass an allen Aufrufstellen das '+ 1' entfallen kann.