Posts by Dr. Seltsam

    Die tar enthält ja wie das img sowohl Kernel als auch das Dateisystem. Ich weiss, dass der ssh-Fehler nach einem update auftritt. Jetzt wäre interessant zu wissen, ob es am Kernel oder am Dateisystem liegt. Ich würde ja gerne die /usr/sbin/sshd eines funktionierenden images in das neue image verpflanzen, aber wie mache ich das? In einer ssh-Sitzung flash mounten kann ich ja nicht, weil ich gar keine ssh-Sitzung herstellen kann...

    Boah, Alter... ist das lange her. Wir waren noch jung 8)

    Ich meine mich zu erinnern, dass nie jemand das analogtv-Plugin mit den analogen Teilen der FF-Karten zum Laufen gekriegt hatte. Neben der FuSi hatte wohl auch die Technotrend 2300 irgendeine Art analogen Teil, der aber nur nutzbar war, wenn man das analoge Signal direkt an den Ausgang durchgeroutet hat. Und eventuell kamen die Analogteile bei der Tonausgabe, sofern nicht per SPDIF realisiert, zum Einsatz.

    Das was Hans Verkuil zum Analogteil getestet haben möchte war nach erstem Überfliegen VBI-Code. Ich kann mich nicht erinnern, dass der für vdr je genutzt wurde. Oder erfolgte darüber doch die 16:9-Umschaltung?

    Das ist einfach alles zu lange her.

    Auch mit einem aktuell neu erzeugten image bleibt das Problem bestehen:



    Mit 20.1-Nexus_devel_20230311020349 (Amlogic-ng.arm) geht es noch.

    Ich habe jetzt mal das stable 20.1 image von CoreELEC runtergeladen. Damit tritt das Problem nicht auf. Dann habe ich die am 26.03. erzeugte Datei CoreELEC-Amlogic-ng.arm-20.1-Nexus_devel_20230326133437.kernel in /storage/.update gelegt und dachte, dass diese beim Neustart erkannt wird. Da passiert aber nichts. Wird dann mit der auf .system endenden Datei wahrscheinlich auch nicht gehen? Oder muss ich die umbenennen?

    Ich kann mich ganz dunkel erinnern mal etwas über ssh Probleme gelesen zu haben. Allerdings weiß ich nicht mehr in welchen Zusammenhang. Soweit ich mich erinnere, konnte per samba ein update tar eingespielt werden. Aber wie gesagt: Dunkelste Erinnerungen und ich finde den Beitrag nicht mehr.


    Wenn sshd läuft, reagiert und dann die Verbindung (nach dem Login?) gekappt wird.... Da fällt mir nichts zu ein.

    Auch mit einem aktuell neu erzeugten image bleibt das Problem bestehen:



    Mit 20.1-Nexus_devel_20230311020349 (Amlogic-ng.arm) geht es noch.

    Ich habe mir angewöhnt, meine Sticks direkt auf die Ausgänge meiner Verteiler zu stecken. Dafür habe ich eine Reihe von festen Adaptern, z.B. F auf Koax - alles ohne Kabel. Die Sticks sitzen dann bombenfest. Die einzige Verbindung ist dann ein USB-Kabel zum Gerät - mehr als 1m brauche ich nicht. Wenn die Dose natürlich weit vom VDR weg ist, sind lange USB-Kabel wohl nicht so gut.

    Moin Zabrimus,

    seit gestern ist der Server tntnet.org nicht mehr erreichbar. Deshalb scheitert das Bauen der cxxtools:

    Auf dem Mirror von libreelec liegt irritierenderweise nur eine Version 2.2.1

    Die 3.0 findet man z.B. hier:

    Index of /repo/pkgs/cxxtools/cxxtools-3.0.tar.gz


    Ebenfalls scheitern dürfte als nächstes tntnet:

    was man z.B. hier findet:

    http://slackware.uk/sbosrcarch/by-name/network/tntnet/tntnet-3.0.tar.gz


    Wie das mit den Patches funktioniert habe ich noch nicht verstanden. Und woher kommt der Zugriffsversuch auf den mirror von sources.libreelec.tv? Die URL ist im package.mk gar nicht vorhanden.

    Du meinst ne, denn ng läuft heute.


    Hast Du andere Informationen als CoreELEC?


    Ich sehe heute, dass sich die Namen der Konfigurationen für CoreELRC geändert haben:

    Available configs:

    CoreELEC-19

    CoreELEC-20-ng

    CoreELEC-19.4-Matrix

    CoreELEC-21-ne

    CoreELEC-20-ne

    CoreELEC-21-ng


    Ich weiss, dass ne für new era steht, d.h. mainline-Kernel und ohne Support für S905X3 und S922. Somit brauche ich für den Odroid N2 und die Tanix TX3 die ng-Version. Aber welche? Stable ist glaube ich 20.1. Das wäre dann CoreELEC-20-ng ?

    Über eine CoreELEC-Version 21 finde ich in deren Forum überhaupt keinen Hinweis, nichtmal im Developer-Forum. Das ist dann also eine bleeding-edge Entwicklerversion ohne Empfehlung für den Produktiveinsatz?


    Oder ist die 21 etwa nur eine Abkürzung für 20.1?

    ("battery_status: dead" obwohl sie gut ist)

    wie hast Du ermittelt, dass sie gut ist? Ich habe schon öfters den Fall gehabt, dass ein Voltmeter noch 3V anzeigt, aber im Ampere-Messmodus dann so gut wie kein Strom mehr floss. Bei anderen Lithium-Batterien geht die Spannung hingegen deutlich runter, wenn sie alt werden. Im Zweifel einfach mal austauschen. Wie sehen denn die Elkos auf dem Board aus? Gibt es gewölbte Deckel oder Spuren ausgelaufenen Elektrolyts?

    Hiernach ist die Firmware für Dein Modell richtig. Aber warum funktioniert sie nicht?

    Lass Dir mit modinfo si2157 bzw. si2168 mal alle Firmwaredateien anzeigen, die von den Treibern je nach Karte geladen werden können. Ich würde die dann alle in /lib/firmware packen und dann mal schauen, ob eine davon zusätzlich geladen wird, auch wenn ihr Fehlen bis jetzt nicht angemeckert wird.

    Dann vielleicht nochmal eine Linux Live-CD mit einem ganz neuen Kernel testen. Im schlimmsten Fall fehlt im Treiber noch die Unterstützung für diese neue Revision.


    Vergleich auch mal Deine vollständige dmesg-Ausgabe hiermit.

    Es ist möglich, dass sich die benötigte Firmware im Laufe der Kernelentwicklung für bestimmte Hardwarerevisionen geändert hat und die ursprünglich von Dir verwendete Datei für Deinen Kernel doch richtig ist. Andererseits - ich habe ja auch 5.15 (in Ubuntu 20.04) und dort wird -wie auch in CoreELEC- die 40er-Firmware geladen. Es muss dann wohl an unterschiedlichen Hardwarerevisionen liegen. Poste mal ein Foto vom Aufkleber auf dem Stick.


    Hast Du originale, unverfälschte Ubuntu-Kernel, oder die media-Treiber durch selbst kompilierte Treiber von linuxtv media_build ersetzt? Oder Treiberpakete von Drittanbietern wie TBS?


    Es gibt unter Umständen auch unterschiedliche Firmwarestände trotz gleichem Dateinamen.

    Probier mal, ob die hier eine andere ist:

    Index of /linux/v4l-dvb/firmware/Si2168/Si2168-D60/6.0.1


    Und last not least: vielleicht hättest Du ja schon längst Empfang mit einer für Deinen Wohnort passenden channels.conf. Wer ist der Kabelanbieter? Probier doch mal

    Code
    Das Erste HD;ARD:330000:C0M256:C:6900:5101=27:0;5102=deu@106,5103=mis@106,5107=qks@106:5104;5105=deu:0:10301:1:1051:0
    ZDF HD;ZDFvision:450000:C0M256:C:6900:6110=27:0;6120=deu@106,6121=mis@106,6123=mul@106:6130;6131=deu:0:11110:1:1079:0
    NDR FS HH HD;ARD:458000:C0M256:C:6900:5241=27:0;5242=deu@106,5243=mis@106,5247=qks@106:5244;5245=deu:0:10329:1:1073:0

    Ich habe auch zwei WinTV dualHD mit ID 2040:8265 im System. Zumindest sagt lsusb das. Beide werden als model 204109, rev B3I6 erkannt.

    Kernel ist 5.15. Die dmesg-Ausgabe sieht etwas merkwürdig aus, da verschiedene Firmware-Versionen für immer die gleiche fw-Datei protokolliert werden:

    Auf alle Fälle habe ich nicht dvb-demod-si2168-d60-01.fw, sondern dvb-demod-si2168-b40-01.fw

    Ich hatte das manuell eingebaut und es hat kompiliert. Keine Ahnung, ob es damit zu tun hat, aber mit dem image hatte ich dann folgendes Phänomen:

    ssh-Verbindung wird erfolgreich aufgebaut - CoreELEC meldet sich mit den Daten der Box - und die Verbindung wird sofort ohne Angabe eines Fehlergrundes wieder geschlossen.

    vdr kann ja leider immer noch nicht Fernbedienungen direkt über die Kernelschnittstelle /dev/input/eventX ansprechen. Stattdessen wird auf LIRC gesetzt. Mir bekannte Lösungen:



    a) vdr-plugin-remote

    Bei meinem letzten Test funktionierte alles bis auf die repeat-Funktion. Damit leider nicht verwendbar. In den Sourcen heisst es auch etwas einschränkend, dass das nie vom Entwickler getestet wurde:

    Code
    DVB and dvb-kernel driver (version 1.0.x "DVB", version 1.1.x "dvb-kernel") 
    ---------------------------------------------------------------------------
    Remote control events are passed through '/device/input/eventX'.
    (Since the /dev/input protocol is standardized in the kernel, there is a
    chance that this plugin will work with other /dev/input devices, too.
    However, this has not been tested yet...)
    The -i option allows you to specify the name of the /dev/input device.


    b) eventlircd

    wird von yavdr benutzt: https://www.yavdr.org/document…mentation.html#eventlircd


    c) lirc mit devinput-driver

    LIRC - Linux Infrared Remote Control

    ?? keine Ahnung, ob und wie das funktioniert.


    Nun bin ich beim Googeln noch auf dieses Plugin gestoßen:


    d) vdr-plugin-inputdev

    GitHub - ensc/vdr-plugin-inputdev: Plugin for VDR to handle /dev/input devices dynamically (mirror of vdr-developer repository).
    Plugin for VDR to handle /dev/input devices dynamically (mirror of vdr-developer repository). - GitHub - ensc/vdr-plugin-inputdev: Plugin for VDR to handle…
    github.com

    Der mageren Beschreibung im vdr-wiki zufolge liest es " input events von /dev/input/eventX (KBD, IR, Maus)".

    Ich muss gestehen, dass mich das README etwas überfordert...


    Hat dieses Plugin jemand am Laufen? Lohnt es sich, da Zeit zu investieren?

    Dr. Seltsam : Zwar ungetestet, aber baut: https://github.com/rellla/VDRS…cc457d45cb368f9822583d134


    Das Problem ist, dass es bei den CoreELEC Builds wohl auch ein Cache gibt, aus dem die Quellen gezogen werden, und es erst dann auffällt, wenn es jemand meldet.

    Bisher scheint es bei CoreELEC nicht aufgefallen zu sein:

    CoreELEC/projects/Amlogic-ce/packages/linux-drivers/RTL8821CU at coreelec-20 · CoreELEC/CoreELEC
    A lightweight OS for KODI. Contribute to CoreELEC/CoreELEC development by creating an account on GitHub.
    github.com


    Zabrimus: Vielleicht kannst Du einstweilen den Patch von rell übernehmen?


    Nachtrag: Habe mal einen Hinweis im CoreELEC-Foum gepostet.

    Es bleibt nur noch nachzutragen, dass Jacob mir den vollen Kaufpreis für die defekte Samsung SSD EVO 870 ersetzt hat. Der Reklamationsprozess hat zwar etwas lange gedauert hat, aber das Ergebnis ist nicht selbstverständlich, denn eine Ersatzlieferung hätte ich akzeptieren müssen.


    Ich brauchte kaum etwas drauflegen, um nun eine doppelt so große Crucial MX500 kaufen zu können.