Ein IR-Sensorkabel am integrierten Empfänger einer DVBSky S952 von anno 2013.
Posts by rüsseltier
-
-
irw zeigt mir keine Fernbedienungseingaben.
Ich habe mal ein paar weitere Ausgaben durchgetestet, vielleicht hilft das ja bei der Fehlersuche - ich bin momentan ratlos:
Code- vdr:~# ir-keytable
- Couldn't find any node at /sys/class/rc/rc*.
- vdr:~# cat /proc/bus/input/devices
- I: Bus=0000 Vendor=0000 Product=0000 Version=0000
- N: Name="lircd-uinput"
- P: Phys=
- S: Sysfs=/devices/virtual/input/input15
- U: Uniq=
- H: Handlers=sysrq kbd rfkill event12
- B: PROP=0
- B: EV=100003
- B: KEY=ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe
- vdr:~# fuser -vu /var/run/lirc/lircd
- BEN. PID ZUGR. BEFEHL
- /run/lirc/lircd: root 553 F.... (root)lircd
Edit: Das sieht auch komisch aus:
Code- vdr:~# systemctl status lircd-setup.service
- Loaded: loaded (/lib/systemd/system/lircd-setup.service; enabled; vendor preset: enabled)
- Active: failed (Result: start-limit-hit) since Tue 2020-07-14 13:23:06 CEST; 39s ago
- Docs: man:lircd-setup(8)
- Process: 819 ExecStart=/usr/sbin/lircd-setup (code=exited, status=0/SUCCESS)
- Main PID: 819 (code=exited, status=0/SUCCESS)
- Jul 14 13:23:06 vdr systemd[1]: Starting lircd(8) initialization helper tool...
- Jul 14 13:23:06 vdr systemd[1]: Started lircd(8) initialization helper tool.
- Jul 14 13:23:06 vdr systemd[1]: lircd-setup.service: Start request repeated too quickly.
- Jul 14 13:23:06 vdr systemd[1]: Failed to start lircd(8) initialization helper tool.
- Jul 14 13:23:06 vdr systemd[1]: lircd-setup.service: Unit entered failed state.
- Jul 14 13:23:06 vdr systemd[1]: lircd-setup.service: Failed with result 'start-limit-hit'.
/etc/lirc/hardware.conf
Code- # /etc/lirc/hardware.conf
- #
- # Arguments which will be used when launching lircd
- LIRCD_ARGS=""
- #Don't start lircmd even if there seems to be a good config file
- #START_LIRCMD=false
- #Don't start irexec, even if a good config file seems to exist.
- #START_IREXEC=false
- #Try to load appropriate kernel modules
- LOAD_MODULES=true
- # Run "lircd --driver=help" for a list of supported drivers.
- DRIVER="default"
- # usually /dev/lirc0 is the correct setting for systems using udev
- DEVICE="/dev/lirc0"
- MODULES=""
- # Default configuration files for your hardware if any
- LIRCD_CONF="/etc/lirc/lircd.conf"
- LIRCMD_CONF=""
/etc/lirc/lirc_options.conf
Code- # These are the default options to lircd, if installed as
- # /etc/lirc/lirc_options.conf. See the lircd(8) and lircmd(8)
- # manpages for info on the different options.
- #
- # Some tools including mode2 and irw uses values such as
- # driver, device, plugindir and loglevel as fallback values
- # in not defined elsewhere.
- [lircd]
- nodaemon = False
- driver = devinput
- device = auto
- output = /var/run/lirc/lircd
- pidfile = /var/run/lirc/lircd.pid
- plugindir = /usr/lib/i386-linux-gnu/lirc/plugins
- permission = 666
- allow-simulate = No
- repeat-max = 600
- #effective-user =
- #listen = [address:]port
- #connect = host[:port]
- #loglevel = 6
- #uinput = ...
- #release = ...
- #logfile = ...
- [lircmd]
- uinput = False
- nodaemon = False
- # [modinit]
- # code = /usr/sbin/modprobe lirc_serial
- # code1 = /usr/bin/setfacl -m g:lirc:rw /dev/uinput
- # code2 = ...
- # [lircd-uinput]
- # release-timeout = 200
-
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:
Code- Jul 14 11:00:01 vdr vdr: [553] remote control LIRC - keys known
- Jul 14 11:00:01 vdr vdr: [854] LIRC remote control thread started (pid=553, tid=854, prio=high)
- Jul 14 11:25:27 vdr lircd-0.9.4c[560]: Info: lircd-uinput: Opening log, level: Info
- Jul 14 11:25:27 vdr lircd-0.9.4c[560]: Info: Reading data from /var/run/lirc/lircd, writing to /dev/uinput
- Jul 14 11:25:27 vdr lircd-0.9.4c[560]: Info: Using "_UP" as release suffix
- Jul 14 11:25:27 vdr vmunix: [ 4.741784] input: lircd-uinput as /devices/virtual/input/input15
- Jul 14 11:25:27 vdr lircd-0.9.4c[559]: Info: Initial device: auto
- Jul 14 11:25:27 vdr lircd-0.9.4c[559]: Info: Initial device: auto
- Jul 14 11:25:27 vdr lircd-0.9.4c[559]: Info: lircd: Opening log, level: Info
- Jul 14 11:25:27 vdr lircd-0.9.4c[719]: Info: lircd: Opening log, level: Info
- Jul 14 11:25:27 vdr vmunix: [ 4.876969] random: crng init done
- Jul 14 11:25:27 vdr vmunix: [ 4.876973] random: 7 urandom warning(s) missed due to ratelimiting
- Jul 14 11:25:27 vdr lircd-0.9.4c[719]: Info: Initial device: auto
- Jul 14 11:25:27 vdr lircd-0.9.4c[719]: Info: Initial device: auto
- Jul 14 11:25:27 vdr lircd-0.9.4c[719]: Info: lircd: Opening log, level: Info
- Jul 14 11:25:27 vdr vmunix: [ 4.995507] m88ds3103 2-0068: found a 'Montage Technology M88DS3103' in cold state
- Jul 14 11:25:27 vdr vmunix: [ 4.995909] m88ds3103 2-0068: firmware: direct-loading firmware dvb-demod-m88ds3103.fw
- Jul 14 11:25:27 vdr vmunix: [ 4.995915] m88ds3103 2-0068: downloading firmware from file 'dvb-demod-m88ds3103.fw'
- Jul 14 11:25:27 vdr lircd-0.9.4c[808]: Info: lircd: Opening log, level: Info
- Jul 14 11:25:27 vdr lircd-0.9.4c[808]: Info: Initial device: auto
- Jul 14 11:25:27 vdr lircd-0.9.4c[808]: Info: Initial device: auto
- Jul 14 11:25:27 vdr lircd-0.9.4c[808]: Info: lircd: Opening log, level: Info
- Jul 14 11:25:27 vdr lircd-0.9.4c[815]: Info: lircd: Opening log, level: Info
- Jul 14 11:25:27 vdr lircd-0.9.4c[815]: Info: Initial device: auto
- Jul 14 11:25:27 vdr lircd-0.9.4c[815]: Info: Initial device: auto
- Jul 14 11:25:27 vdr lircd-0.9.4c[815]: Info: lircd: Opening log, level: Info
- Jul 14 11:25:27 vdr lircd-0.9.4c[821]: Info: lircd: Opening log, level: Info
- Jul 14 11:25:27 vdr lircd-0.9.4c[821]: Info: Initial device: auto
- Jul 14 11:25:27 vdr lircd-0.9.4c[821]: Info: Initial device: auto
- Jul 14 11:25:27 vdr lircd-0.9.4c[821]: Info: lircd: Opening log, level: Info
Hier noch meine /etc/lirc/lircd.conf
Code- #
- # this config file was automatically generated
- # using lirc-0.7.0pre4(serial) on Sun Oct 2 00:24:32 2005
- #
- # contributed by anton|ganthaler.at and juergen.wilhelm|aon.at
- # members of linux user group Vorarlberg www.lugv.at
- #
- # for ir remote controler from Hauppauge WinTV Nexus-S
- # most of the keys are supported
- #
- # brand: Hauppauge
- # model no. of remote control: WinTV Nexus-S
- # devices being controlled by this remote:
- #
- begin remote
- name Hauppauge_WinTV_Nexus-S
- bits 13
- flags RC5|CONST_LENGTH
- eps 30
- aeps 100
- one 944 828
- zero 944 828
- plead 980
- gap 113932
- min_repeat 1
- toggle_bit 2
- begin codes
- Up 0x0000000000001794
- Down 0x0000000000001795
- Left 0x0000000000001796
- Right 0x0000000000001797
- Power 0x00000000000017BD
- Ok 0x00000000000017A5
- Menu 0x000000000000178D
- Back 0x000000000000179F
- Red 0x000000000000178B
- Green 0x00000000000017AE
- Yellow 0x00000000000017B8
- Blue 0x00000000000017A9
- 0 0x0000000000001780
- 1 0x0000000000001781
- 2 0x0000000000001782
- 3 0x0000000000001783
- 4 0x0000000000001784
- 5 0x0000000000001785
- 6 0x0000000000001786
- 7 0x0000000000001787
- 8 0x0000000000001788
- 9 0x0000000000001789
- Play 0x00000000000017B5
- Pause 0x00000000000017B0
- Stop 0x00000000000017B6
- Record 0x00000000000017B7
- FastFwd 0x00000000000017B4
- FastRwd 0x00000000000017B2
- Channel+ 0x00000000000017A0
- Channel- 0x00000000000017A1
- # Volume+ 0x0000000000001790
- # Volume- 0x0000000000001791
- Mute 0x000000000000178F
- Timers 0x000000000000178A
- Recordings 0x000000000000178E
- Back 0x000000000000179F
- end codes
- end remote
Außerdem ist mir im syslog noch ein "invalid lock sequence report" aufgefallen.
Edit: Ursache für invalid lock sequence report bei Skinelchi gefunden
-
Hmm, vielleicht hast Du recht und ich sollte der MLD nochmal eine Chance geben.
Hatte es vor 1 1/2 zuletzt probiert und damals Probleme mit meiner nVidia-Karte.
-
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.
-
Danke für die Erklärungen und Richtigstellungen - werde am WE mal noch prüfen, ob sich nicht doch noch ein verwinkelte Route für das PCI-E-Kabel findet.
-
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.
-
Müssen aktuelle Tower-Gehäuse wie das Bequiet Pure Base 500 mit untenliegendem Netzteil noch mit einem Zusatzlüfter betrieben werden oder reicht in diesen der Kamin-Effekt durch die perforierten Deckel oben?
Ich denke dabei nur an ein Office-System mit 65W TDP und IGP ohne zusätzliche Grafikkarte.Bislang hatte ich in dieser Konfiguration einen Tower, bei dem das Netzteil noch über dem Mainboard montiert wurde und der Netzteillüfter die warme Luft aus dem Gehäuse rausschaufelte.
Sorry, wenn die Frage etwas dämlich ist, aber ich aus dem Gehäusethema mindestens 15 Jahre raus.
-
Ich habe einen ganz interessanten Weg gefunden:
Es gibt eine App names Termux, die eine Shell samt Paketmanager zur Verfügung stellt.
Darin habe ich dann kurzerhand ein SH-Skript zusammengestrickt, was für meine Zwecke vollkommen reicht.
-
Ich habe eine Liste von URLs mit ZIP-Dateien, die ich regelmäßig downloaden und entpacken möchte.
Normalerweise würde man ja ein simples SH-Skript mit wget und unzip anlegen, aber die Möglichkeit gibt es meines Wissens unter ungerootem Android so ja nicht.
Kennt jemand einen Weg, wie man so eine Aufgabe unter Android lösen kann?
-
Seit gestern sendet der Sender tatsächlich auch in nativem, kaltgepressten HD.
-
Danke für die Erklärungen, das hat mir sehr weitergeholfen.
Nachdem mein TV auch Unicable-tauglich ist, könnte ich im Prinzip auch auf Legacy-Ausgänge verzichten, denn Ausmessen über einen SAT-Finder muss ich nicht mehr.
Wer empfiehlt sich denn als LNB-Hersteller? So wie ich es sehe, gibt es ja neben Inverto noch Dura-Sat, TechniSat, Mega-Sat und Fuba als Anbieter von UnicableII-LNBs.
Der_Pit : Ja, die V2 hat auch Dual-Tuner.