Posts by rüsseltier

    So, Lösung gefunden: die Maintainer haben aus unerfindlichen Gründen im Kernel-Modul den RC-Support für die DVBSky S952 per Default abgeschalten:

    https://forum.kodi.tv/showthread.php?tid=220265

    Mann muss eine /etc/modprobe.d/cx23885.conf erstellen und dort

    options cx23885 enable_885_ir=1

    reinschreiben.

    Reboot und man hat wieder das:

    Code
    Jul 15 12:12:17 vdr vmunix: [    4.354199] Registered IR keymap rc-dvbsky
    Jul 15 12:12:17 vdr vmunix: [    4.354443] input: cx23885 IR (DVBSky S952) as /devices/pci0000:00/0000:00:1c.0/0000:01:00.0/rc/rc0/input15
    Jul 15 12:12:17 vdr vmunix: [    4.358358] rc rc0: cx23885 IR (DVBSky S952) as /devices/pci0000:00/0000:00:1c.0/0000:01:00.0/rc/rc0
    Jul 15 12:12:17 vdr vmunix: [    4.362521] lirc_dev: IR Remote Control driver registered, major 245
    Jul 15 12:12:17 vdr vmunix: [    4.363148] IR RC5(x/sz) protocol handler initialized
    Jul 15 12:12:17 vdr vmunix: [    4.364703] rc rc0: lirc_dev: driver ir-lirc-codec (cx23885) registered at minor = 0
    Jul 15 12:12:17 vdr vmunix: [    4.364708] IR LIRC bridge handler initialized

    So sah es in den Logs zuvor mit Jessie aus, da wurde der DVBSky RC-Port einwandfrei erkannt und registriert:

    Jetzt auf Stretch kommt nach cx23885[0]/0: found at 0000:01:00.0, rev: 4, irq: 16, latency: 0, mmio: 0xbb200000 nichts mehr.

    Sollte jemand nach einem Jessie->Stretch-Upgrade auch mal noch das Problem haben, dass Samba nicht mehr geht:

    man muss manuell den Ordner /var/lib/samba/private anlegen, ansonsten scheitert es daran

    Code
    [2020/07/15 07:42:52.536457,  0] ../lib/util/util.c:216(directory_create_or_exist)
      mkdir failed on directory /var/lib/samba/private/msg.sock: Datei oder Verzeichnis nicht gefunden

    Ebenso sollte man prüfen, ob der Ordner /var/cache/samba/msg auf 0755 ist.

    Beides Dinge, die nach dem Upgrade von Samba von 4.2.14 auf 4.5.16 vorausgesetzt werden, aber seitens des Debian-Updateprozesses nicht durchgeführt werden.

    Habe jetzt mal noch ein systemctl mask lircd-uinput ausgeführt, brachte aber außer einem

    Code
    Jul 14 16:05:38 vdr vmunix: [    2.676346] systemd[1]: lircd-uinput.service: Cannot add dependency job, ignoring: Unit lircd-uinput.service is masked.

    im Log keine Änderung nach einem Neustart.

    Ich hoffe, das Maskieren war nicht kontraproduktiv?

    Firmware von DVBSky ist installiert, TV-Bild und Ton sind da, Tastatur-Bedienung klappt auch.


    dmesg meint

    irw zeigt mir keine Fernbedienungseingaben.

    Ich habe mal ein paar weitere Ausgaben durchgetestet, vielleicht hilft das ja bei der Fehlersuche - ich bin momentan ratlos:

    Edit: Das sieht auch komisch aus:

    /etc/lirc/hardware.conf

    /etc/lirc/lirc_options.conf

    Ich habe die MLD heute früh mal wieder angetestet, es ist wirklich eine "smoothe" Lösung und was die Maintainer da leisten, ist mehr als respektabel.

    Aber mir fehlen halt doch ein paar Kleinigkeiten, die man bei einer vollwertigen Distribution als Freiheiten ab Werk mit dabei hat.

    Beispielsweise würde ich gerne ein Win10-Dualboot über Grub beibehalten. Mit der MLD ist das zwar laut Foreneinträgen auch möglich, erfordert aber einige Klimmzüge.

    So, ich exhumier den Thread mal.

    Nach bald 2 Jahren war ich doch noch so bekloppt mal das alte Jessie-System auf Stretch zu hieven.


    Und das Upgrade lief erstaunlich reibungslos durch: ich habe noch nicht lange testen können, aber was ich bislang sehen konnte, läuft vdr-sxfe wie unter Jessie, von Umschaltproblemen habe bei meiner Kombination noch nichts bemerkt.


    Das einzige, was mir auf Stretch Schwierigkeiten bereitet und wo ich eure Hilfe brauchen könnte, ist lirc.

    Der VDR reagiert nicht mehr auf Fernbedienungseingaben. Hat sich da was geändert von Jessie auf Stretch?


    Hier mal ein Auszug aus dem syslog:


    Hier noch meine /etc/lirc/lircd.conf


    Außerdem ist mir im syslog noch ein "invalid lock sequence report" aufgefallen.

    Edit: Ursache für invalid lock sequence report bei Skinelchi gefunden

    Ich will nun doch mal meinen alten VDR auf Debian-Jessie-Basis neu aufsetzen.

    Ursprünglich wollte ich wieder Debian (Buster) mit e-Tobi Repo nehmen, dann fiel mir aber auf, dass man da erst bei Kernel 4.19 startet - außer man fängt direkt wieder mit Backports an.


    Nun bin ich nach etwas Recherche auf Ubuntu 20.04 mit yaVDR PPAs gestoßen.

    Ist das eine gute Idee oder gibt es dazu noch sinnvollere Alternativen?


    Ich hatte mir auch mal die MLD angesehn, ich lege aber auf Dinge wie Kodi keinen Wert und möchte ein eher minimalistisches System.

    Vdpau läuft auch in Ubuntu 20.04 problemlos, wenn man den richtigen softhddevice-Fork verwendet.

    Ich nutzte bislang immer noch vdr-sfxe/xineliboutput, da scheint sich wohl im Januar nach längerer Pause auch mal wieder was getan zu haben:

    https://sourceforge.net/projec…/vdr-xineliboutput-2.2.0/

    Muss wirklich mal einen aktuelles Test-System auf einem schnellen USB-Stick einrichten, um auch mal selbst zu sehen, wie der aktuelle Stand bei den ganzen Varianten ist.

    Was ist denn momentan der richtige softhddevice-Fork?

    Darf ich den Thread noch mal ausgraben?

    Wenn ich es richtig verstehe, hat die Graphikeinheit eines BayTrail J1800 nicht genügend Dampf um 1080i qualitativ zu deinterlacen.


    Bin aktuell noch mit einem J1800 und einer GT610 unterwegs. Da aber neuere Distribution Probleme mit FFMPEG/VDPAU haben, bin ich jetzt am Überlegen was ich mache.

    4K interessiert mich nicht, aber Ruckler oder Kämme bei HD möchte ich auch mit Intel nicht sehen.

    Gilt da nach wie vor die Empfehlung auf ein Board mit J4105 upzugraden?


    Von AMD sollen ja demnächst auch neue APUs kommen, aber was man so liest, ist (oder war?) AMD ja von der Videoqualität nicht so gut unter Linux wie Intel und Nvidia.

    Also, der 6-polige PCI-E-Stecker nimmt sowieso nur die 12V-Leitungen in Empfang und die Netzteilkabel schaffen bei AWG18 wenn ich es recht verstehe max. 9,5A. Soviel verbraucht der ganze VDR nicht, sollte also passen wenn alles am Molex-Strang hängt - korrigier(t) mich, wenn ich einen Denkfehler habe.


    Die Spannungen generell sollten sauberer denn je sein. Das neue NT hat z.B. eine DC-DC-Schiene und gilt auch sonst als ebenbürtig mit modernen ATX-Netzteilen im Vollformat: Corsair SF450 im Test: Ein Meilenstein für SFX

    Davor hatte ich ein 7 Jahre altes Seasonic SS-300SFD 80+ (ebenfalls SFX, aber designed anno 2005), das ich wg. defekter 5VSB-Leitung ersetzen musste nachdem deswegen kein WOL mehr ging.

    Ich habe eine DVBSky S952 von anno 2013 (also nicht die aktuelle Rev. V3).

    Die Karte hat eine 6-poligen PCI-E-Strombuchse und es lag ein Y-Kabel von 6-polig PCI-E-Stecker auf 2x Molex-Buchse bei.


    Meine Fragen:

    Muss man die Buchsen normalerweise beide anstöpseln und müssen die aus unterschiedlichen Strom-Schienen kommen?

    Und wieviel Ampere nimmt die Karte da überhaupt maximal aus dem 6-poligen Anschluss?

    Die DVBSky-Website schweigt sich leider zu beiden Infos komplett aus.


    Hintergrund: Ich habe auf ein kleineres Gehäuse samt neuem Netzteil gewechselt (Corsair SF450 mit modularen Stromkabeln, die durchweg AWG18 haben) .

    Das neue NT hätte auch ein dezidiertes PCI-E-Stromkabel, allerdings wird es mit diesem noch enger als eh schon.

    Deswegen dachte ich, ich lass das weg und verbinde 2 Stecker vom Molex-Kabel, dass ich eh dort vorbeiläuft.

    An dem Molex-Strang hängt ausserdem noch ein DVD-Laufwerk und der Stromversorgung-Anschluss einer Firewire-PCI-E-Karte.


    Ich muss dazu sagen, dass ich eh nur einen Tuner nutze und bislang am alten 300W-Netzteil nur einen Molex überhaupt angeschlossen hatte, was problemlos lief.


    Edit: So wie ich es sehe, hat die aktuelle Rev. V3 nur mehr ein einfaches Kabel mit 6-pol. PCI-E auf eine einfache SATA-Strombuchse beiliegen. Verbraucht die weniger Strom?

    Ich boote im good ol' BIOS/CSM-Modus.

    Im Anhang ein Screenshot von gparted.


    Alternativ habe ich mir auch überlegt ein aktuelles Mint in /dev/sdb2 zu installieren und dort Windows 10 in VirtualBox laufen zu lassen. Aber ich glaube das ist noch komplizierter, weil sich dann ja der update-grub von Debian und Mint bei Kernelupdates sich gegenseitig die Bootblöcke überschreiben, oder kann man das irgendwie umgehen?

    Megal: Das ist gut zu wissen, danke!


    M-Reimer: Du meinst je eine extra SSD für Win10 und Linux oder verstehe ich das falsch? Ich kann im BIOS meines Boardes nur Devices auswählen, keine Partitionen.

    Ich haben neben dem Gitarren-Ding noch ein paar andere Kuriositäten, u.a. Teamviewer, das sich unter Linux nicht mit zwei verschiedenen Android-Smartphones verbinden kann, während es unter Windows geht (kein Scherz, ist seit einem Jahr bei Teamviewer bekannt).

    Ich habe aktuell auf dem VDR noch neben Debian ein Windows 7 laufen.

    Das möchte ich jetzt mit Windows 10 neu installieren, da ich doch noch ein paar Windows-only-Dinge nutze (z.B. einen virtuellen Gitarren-Amp).

    Mir ist bewusst, dass hinterher der Grub weg ist und ich diesen mit einem Reparatur-Linux auf einem USB-Stick wiederherstellen muss.


    Meine Frage ist jetzt nur, da bei Windows 10 ja 2x pro Jahr komplette Update-Images eingespielt werden: muss ich dann jedes mal wieder den Grub reparieren oder wie verhält sich W10 in dem Fall?

    wirbel: Das genannte Gehäuse hat einen Staubfilter im Boden unter dem Netzteil, sollte als theoretisch da keine Flusen ansaugen.


    Mein Verdacht war halt, dass diese aktuellen Tower-Designs mit untetliegendem Netzteil ja eigentlich ein Rückschritt für sparsame Systeme sind, weil man eben nicht mehr den Netzteillüfter zum Absaugen nutzen kann, sondern wohl auf 1-2 lärmende Zusatzlüfter angewiesen ist.

    Ich verstehe, dass dieses Konzept besser ist bei viel Abwärme (hohe CPU-TDP, leistungshungrige Graka), aber wenns um möglichst wenig Lautstärke geht, ist das irgendwie kontraproduktiv.