Posts by M-Reimer

    Ich könnte das später als Pull-Request einstellen. Wäre mir lieber das alsbald möglich "upstream" zu haben um nicht auf Dauer selber patchen zu müssen.


    Was hat das mit diesem "FORCE" auf sich? Ist "FORCE" nicht ein leeres Target?

    Damit hatte ich gestern auch zu kämpfen.

    Ich hab mir etwas zusammengefummelt. Dein Fix kommt einer "sauberen Lösung" aber deutlich näher.


    +CFLAGS?=-Wall -Wno-switch -ggdb -fPIC $(EXTRA_CFLAGS)

    +CFLAGS += $(EXTRA_CFLAGS) @CFLAGS@

    +LDFLAGS += @LDFLAGS@ -lpthread


    Ist das nicht redundant?


    Wenn CFLAGS nicht gesetzt, dann setze auf $VORGABE +$EXTRA_CFLAGS

    Füge zu den CFLAGS dann $EXTRA_CFLAGS hinzu gefolgt von den CFLAGS aus configure.

    Kann dann das $(EXTRA_CFLAGS) in der ersten Zeile nicht entfallen? Wird ja sowieso in jedem Fall in der zweiten Zeile eingebaut.


    Wenn du die Zeit hast, dann wäre es echt gut wenn du einen sauberen Fix direkt als Pull-Request für minisatip einstellen könntest.

    Danke erstmal für die Infos.


    Wenn ich deine Befehlszeile so anschaue, dann wäre also für den Anfang das Minimum:


    -n eth1:6 -b 15640


    Unter der Annahme das direkt 0.0.0.0 als IP genommen wird. Aber das kann ich dann ja ausprobieren.


    VLAN werde ich nicht machen. Das ist ja die Idee des Raspberry Pi 4 als "Gateway". Der bekommt als einziges Gerät im ganzen Haus auf einer eigenen LAN-Karte (via USB 3.0 angebunden) den Netceiver und bietet zum LAN dann nurnoch Sat>IP an.


    Interessant, dass DiSEqC dann wieder am "Client" gemacht wird. Das macht die minisatip-Einrichtung ja übersichtlich.


    Was bietet minisatip eigentlich über das Webinterface an, das wohl mitkommt?


    PKGBUILDs für minisatip und libmcli habe ich fertig. Ich lade die aber erst hoch wenn ich weiß das sie zumindest im Groben funktionieren.

    Hallo,


    Ich habe bisher nie mit Minisatip zu tun gehabt. Da ein Bekannter aber einen voll bestückten Netceiver rumfliegen hat, möchte ich versuchen den via Minisatip auf Sat/IP zu "wandeln" um ihn wieder nutzbar zu machen.


    Was ist dabei zu beachten? Wie muss ich mir z.B. die Netceiver-Anbindung vorstellen? Erkennt Minisatip von selbst wie viele Tuner im Netceiver bestückt sind?

    Wie werden die DiSEqC Parameter eingestellt? Macht man das im Minisatip oder wird das wie gehabt im VDR gemacht?


    Wie zuverlässig ist das eigentlich? Hat jemand Minisatip (eventuell sogar mit Netceiver) schon einige Zeit im produktiven Einsatz?

    Auf alle Devices wollte ich bewusst nicht gehen. So kann ich den Power-Button gezielt vom X-Server abkoppeln. Hintergründe hier im Kommentar:

    https://projects.vdr-developer…drpbd.git/tree/vdrpbd#n83


    Und entsprechend simpel ist auch mein verbesserter Kodi-Support. Ich filtere für Kodi das "KEY_POWER" einfach nicht weg weil Kodi bereits sauber drauf reagiert. Bleibt für ein System mit Kodi also eigentlich nurnoch das "Emergency Reboot" Feature übrig. Wer das nicht braucht kann auf einem System mit Kodi eigentlich einfach auf vdrpbd verzichten.


    Ich habe vdrpbd eigentlich auch nur nochmal angepasst weil yavdr das scheinbar nutzt.

    Im Prinzip könnte man auf solche Tools ganz verzichten wenn wenigstens ein Ausgabe-Plugin so angepasst wird, dass es KEY_POWER, das wie jede ganz normale Taste im X-Server ankommt, korrekt behandelt.

    Ich habe mal etwas durch den Kernel-Source gesucht und was da mit dem Power-Button gemacht wird ist schwer zu durchschauen.

    Allerdings ist "PNP0C0C" eine valide Kennung für einen "Power Button".

    Ich hab das jetzt mal als "zweite Priorität" eingebaut. Wenn der "normale" Power Button nicht gefunden wird, dann erfolgt ein Fallback auf diesen zweiten Pfad.

    Verfügbar als "Version 2.0.0"

    Download von hier als Snapshot. Das mit der separaten Ablage in Redmine tue ich mir nicht mehr an.

    https://projects.vdr-developer.org/git/vdrpbd.git/


    Edit: "Kodi Mode" wird nochmal überarbeitet. So wie es aktuell drin ist werden Aufnahmen abgebrochen und Kodi fährt knallhart runter.

    Wenn es gar nichts liefert wurde das Modul geladen. Frage ist ob das was an den Input Devices ändert.


    Problem ist das das "Powerbutton Device", das du hast, bei mir auch existiert. Nur kommt da bei mir definitiv nicht der Powerbutton an.

    Ich frage mich ja ob der "korrekt gestartete" Service dann auch funktioniert. Was passiert denn wenn der physikalische Power-Button am Board dann gedrückt wird? Hat das Board überhaupt einen?


    Bei mir sieht das so aus:



    Der unter "LNXSYBUS" existiert bei mir also auch. Keine Ahnung wie man hier ein Event triggern kann aber mit dem Power-Button auf jeden Fall nicht.


    Bitte mal journalctl -f laufen lassen und den Power-Button drücken. Meldet denn dein modifiziertes vdrpbd einen Tastendruck?


    Da ich schonmal dabei war habe ich Kodi-Support gepusht. Liegt hier schon länger rum.


    Edit: Mach mal "modprobe button". Eventuell ist dein Kernel mit "CONFIG_ACPI_BUTTON=m" gebaut und aus irgendeinem Grund wird das Modul nicht automatisch geladen.

    Ich will in nächster Zeit mal bei Github ins Wiki eine Schritt für Schritt Anleitung reinpacken. Zumindest der reine USB-Receiver ist relativ einfach zu konfigurieren.

    Die PS2-Variante läuft übrigens jetzt schon ca. 4 Monate bei mir zuverlässig zum Steuern von Kodi und zum Starten des PC direkt über PS2.


    Besteht denn Bedarf an einer optionalen Lösung um den Power-Button-Anschluss am Mainboard anzusteuern? Im Prinzip könnte man den "aktiven Pin" vom Mainboard wieder direkt an einen Digitalpin vom Arduino bauen. Oder eben alternativ einen Optokoppler ansteuern.


    Sonst noch Vorschläge/Anforderungen?

    Thermal Pads zu löten (entlöten) ist keine große Sache, man braucht Heißluftequipment. Einen Preheater von unten mit passender Scheibe zum punktgenauen vorwärmen der PCB auf ca 150°C genau an der Stelle. Dann braucht man nur noch mit dem Heißluftstab von oben das kurzzeitig so auf 260° - 280° erhitzen und mit der Vakuum Pinzette das IC abheben. Fummelei sind eher die hauchdünnen Drähte. Die muss man leider per Hand anlöten. Bei 0,4mm Pitchabstand sollten die Drähte so 0,1 - 0,2mm dick sein, damit sie sich nicht berühren. Dafür braucht man schon eine Micro Nadel zum löten. Einfacher wäre es, wenn man die Drähte vorher mit Sekundenkleber in der Nähe an passender Stelle fixiert und unter der Lupe dann genau über den Pads positioniert. Dann etwas Lotpaste drauf mit viel Flussmittel. Bei Aufschmelzen über Heißluft "schwimmt" sich dann das Lot schön auf dem Pad ein und das Flußmittel trennt das Lot zwischen den Pads.


    Ich habe einen großen Lötkolben. Den würde ich etwas verzinnen (wegen Wärmeübertragung) und dann einige Zeit unter dem Chip auf die Massefläche halten. Sollte zum Vorwärmen eigentlich gehen. Dann von oben mit Heißluft (eher so 350°C bis 400°C. Das Zeug wird wohl bleifrei sein) möglichst punktgenau mit wenig Volumenstrom auf den IC. Umliegendes evtl. mit etwas Alufolie schirmen.


    Letztlich bestätigt die Beschreibung meine Annahme, dass die "Spannungsführenden" Pins im USB3-Stecker für anderes zweckentfremdet sind.

    Schon aus optischen Gründen würde ich beide USB-Doppelbuchsen runternehmen. Bei einer neu eingebauten einzelnen USB 3.0 Buchse dann hinten das Schirmblech abnehmen und GND und +5V nach hinten wegbiegen. So können die Pins schon am Raspberry passend verbunden werden. Ein Mod auf der PCI-Express Platine entfällt dann.

    Oh je, das erinnert mich irgendwie an die alten Athlon-Zeiten. Die USB-Controller von den VIA-Chipsätzen hatten mir mehrfach solche Überraschungen bereitet.

    Ich hoffe das ist kein substanzielles Problem und die kriegen das bald in den Griff.

    Bei mir half damals nur eine USB-Controllerkarte.

    Kann durchaus sein. Ich habe jetzt einen anderen USB3 nach SATA Adapter ausgeliehen und damit geht alles bestens...

    Ich bestelle jetzt das gleiche Modell. Den anderen Adapter behalte ich aber. JMicron ist eigentlich ein guter Chipsatz.


    Ich hoffe nur das die Auswahl von passenden USB3 nach Gigabit LAN Adaptern nicht ähnliche Probleme auftreten.

    Ich würde zumindest keinerlei Leitungen die mit "Telekommunikation" zu tun haben direkt einputzen.

    Bei meinen Eltern haben wir z.B. anfangs noch Telefonkabel verlegt und TAE-Dosen angebracht. Danke Leerrohren wurde das mittlerweile gegen LAN-Kabel und LAN-Dosen ersetzt.


    Ich würde heute sogar noch weiter gehen (aber vor allem weil ich Strom selber verlegen kann). Wenn ich nochmal bauen würde, dann wäre alles mit Leerrohr gemacht. Auch die Stromversorgung. Es zeigt sich in letzter Zeit wegen "Smart Home", dass es z.B. praktisch wäre am einen oder anderen Lichtschalter eine Ader mehr zu haben. Mit Leerrohr wäre die eine Ader schnell nachgezogen. Auch angebohrte Leitungen sind dann kein Problem mehr. Einfach die neuen Leitungen an den beschädigten ins Rohr ziehen --> Fertig.

    Komischer Fehler.

    Unterschiede an den Boards sind aber keine zu erkennen?


    Nein.


    Und auch das USB 3.0 zu SATA Problem ist zumindest für mich nicht lösbar:

    https://github.com/raspberrypi/linux/issues/3070

    Und damit ist der Punkt erreicht wo ich erstmal aufgebe und den ganzen Kram von der Werkbank in eine stabile Kiste verfrachte. Mal sehen wann die Zeit gekommen ist an der man das Thema nochmal angehen kann. Alles was ich mit dem RPi 4 vorhatte hat sich wegen irgendwelcher Bugs erstmal erledigt.

    Wie kommst du drauf? Für mich sieht das einwandfrei aus. Die Schutzerde wird direkt bei der "Stecker/Steckdose-Kombi" durchgegeben. Auf die Platine läuft die natürlich nicht. Wird dort ja nicht gebraucht.