Beiträge von jol

Danke @JR, wenn ich das recht verstanden habe, ist ohne den Patch nur die Anzeige der SNR falsch, oder?

Eigentlich habe ich keine Lust auf Kernel-Module zu patchen, zumal bei Ubuntu ja sehr häufig Kernel-Updates kommen, dann müsste ich das Modul häufiger neu compileren als ich mir die Signal-Werte anschaue.

Es nervt schon am Desktop, dass ich die VMWare-Module so häufig compilieren (und signieren) muss.

Uh, Du fragst mich Sachen?

lspci gibt folgendes aus:

01:00.0 Multimedia controller: Digital Devices GmbH Octopus DVB Adapter        Subsystem: Digital Devices GmbH Cine S2 V6.5 DVB adapter        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-        Latency: 0, Cache Line Size: 64 bytes        Interrupt: pin A routed to IRQ 16        Region 0: Memory at 8b400000 (64-bit, non-prefetchable) [size=64K]        Capabilities: <access denied>        Kernel driver in use: ddbridge        Kernel modules: ddbridge

Als zugehöriges Modul finde ich nur:
/usr/lib/modules/5.15.0-89-generic/kernel/drivers/media/pci/ddbridge/ddbridge.ko

journalctl |grep ddbridge gibt folgendes aus:

Nov 23 11:39:06 gen2vdr kernel: ddbridge: Digital Devices PCIE bridge driver 0.9.33-integrated, Copyright (C) 2010-17 Digital Devices GmbHNov 23 11:39:06 gen2vdr kernel: ddbridge 0000:01:00.0: detected Digital Devices Cine S2 V6.5 DVB adapterNov 23 11:39:06 gen2vdr kernel: ddbridge 0000:01:00.0: HW 0001000d REGMAP 00010004Nov 23 11:39:06 gen2vdr kernel: ddbridge 0000:01:00.0: Port 0: Link 0, Link Port 0 (TAB 1): DUAL DVB-S2Nov 23 11:39:06 gen2vdr kernel: ddbridge 0000:01:00.0: Port 1: Link 0, Link Port 1 (TAB 2): NO MODULENov 23 11:39:06 gen2vdr kernel: ddbridge 0000:01:00.0: Port 2: Link 0, Link Port 2 (TAB 3): NO MODULENov 23 11:39:06 gen2vdr kernel: ddbridge 0000:01:00.0: Port 3: Link 0, Link Port 3 (TAB 4): NO MODULENov 23 11:39:07 gen2vdr kernel: ddbridge 0000:01:00.0: attach tuner input 0 adr 60Nov 23 11:39:07 gen2vdr kernel: ddbridge 0000:01:00.0: DVB: registering adapter 0 frontend 0 (STV090x Multistandard)...Nov 23 11:39:07 gen2vdr kernel: ddbridge 0000:01:00.0: attach tuner input 1 adr 63Nov 23 11:39:07 gen2vdr kernel: ddbridge 0000:01:00.0: DVB: registering adapter 1 frontend 0 (STV090x Multistandard)...

Zitat von SurfaceCleanerZ

Hi,

Welche Hardware hast du denn? Also DVB?

MfG Stefan

DD Cine S2 V6.5 mit 60cm Spiegel mit QuadLNB

Wie oben schon erwähnt, an der HW habe ich nichts geändert, da lief die HW einwandfrei.
Leider hatte ich einen Stromausfall, die Pufferbatterie des Mainboards war leer und der VDR wollte danach nicht mehr starten.

Da das OS schon sehr viele Jahre alt war habe ich neu installiert, anstatt den Fehler zu suchen.

Danke lnj und seahawk1986, ich werde mal etwas experimentieren.

Solange das Bild (und Ton) in Ordnung ist, lege ich gar keinen Wert auf CUVID. Bei VDPAU hat's bei der alten Installation ja funktioniert. Habe gerade nachgesehen, auch bei der neuen Installation ist VDPAU aktiv.
`AV Sync Start` stand auf `early audio + soft sync`. Habe das auf `early audio` umgestellt. Damit sind die Störungen beim Umschalten weg, die Umschaltzeit empfinde ich als total in Ordnung.

Ich vergleich' mal noch die anderen Einstellungen in der setup.conf der früheren Installation mit der aktuellen.

Bei Empfangsstörungen (Gewitter oder Schneefall) hatte ich immer Störungen, die sich über mehrere Frames verteilt haben. Das sieht hier ganz anders aus. Der Gerätestatus sagt, dass ich eine Signalstärke von 73 und einen Rauschabstand von 23% hätte. Ich kann mich nicht erinnern wie das bei der alten Installation war. Da ich an der HW nichts verändert habe fände ich das überraschend.

Darf ich das etwas ältere Thema nochmal aufgreifen?

Bisher hatte ich auf einer älteren HW mit GeForce GT 630 Rev. 2 gen2vdr, was offensichtlich VDPAU zur Ausgabe auf einem HD-TV nutzte.

Letzte Woche habe ich dann yaVDR 0.7 (ansible) unter Ubuntu 22.04 installiert. Das System läuft auch soweit, allerdings habe ich immer wieder Fehler in einzelnen Frames und beim Umschalten hängt der VDR manchmal für kurze Zeit und gibt dabei einen Brummton von sich. Das fängt sich schnell wieder, also alles kein Showstopper aber halt ned schön.

Als Ausgabe nutzt der VDR softhddevice mit `vdr-plugin-softhddevice/jammy 2.0.6+git20231113-18-6e82ac9-0yavdr0~jammy`
Das Journal sagt, das der VDR offensichtlich ebenfalls VDPAU nutzt. Dabei sagt es auch, dass es immer wieder einzelne Frames verliert, was anscheinend der Grund für die auftretenden Bildfehler ist.

Macht es Sinn von softhddevice zu softhddevice-cuvid zu wechseln?
Wie mach' ich das?
Ich schätze es muss vdr-plugin-softhddevice-cuvid per apt installiert werden. Was muss ich an der Config ändern?
Muss/soll ich vdr-plugin-softhddevice gleichzeitig deinstallieren?

Habe in einem anderen Thread den Tipp gesehen in der Datei /etc/vdr/setup.conf die Variable softhddevice.MakePrimary = 1 zu setzen.

Damit tut's.

Danke rüsseltier für die Hilfestellung, anscheinend ist das Problem mit der obigen Änderung behoben.

Zur Abrundung `aplay -L` gibt folgendes zurück (wenn der Ton läuft):

jo@yavdr:~$ aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
samplerate
    Rate Converter Plugin Using Samplerate Library
speexrate
    Rate Converter Plugin Using Speex Resampler
jack
    JACK Audio Connection Kit
oss
    Open Sound System
pulse
    PulseAudio Sound Server
upmix
    Plugin for channel upmix (4,6,8)
vdownmix
    Plugin for channel downmix (stereo) with a simple spacialization
default
    Playback/recording through the PulseAudio sound server

Hallo,

heute habe ich mir auf einem alten ASRock Q1900M mit interne DUAL DVB-S2 Karte und NVidia Grafikkarte yaVDR gestartet.

Ich habe jetzt das Problem, dass beim Start des VDR nach dem Boot kein Audio am Fernseher ankommt. Starte ich den Dienst VDR über das Menü oder die Shell neu kommt ein Ton.

Die wesentliche Zeile im Log scheint diese zu sein:

Nov 16 18:34:22 yavdr vdr[1006]: audio/alsa: playback open 'hw:NVidia,7' error: Das Gerät oder die Ressource ist belegt

So ein Eintrag ist beim ersten Start nach dem Boot vorhanden, bei einem Neustart des vdr.service nicht.

Die softhddevice.conf sieht so aus:

Zitat

[softhddevice]
-a hw:NVidia,7
#-p hw:NVidia,7
-D

Alles anzeigen

Könnt Ihr mir sagen was da schief läuft?

Zur Vollständigkeit habe ich das gesamte Log als Datei angehängt

Hab' mir jetzt einen Atric USB bestellt. Mal sehen wie's damit klappt.

Ich hoffe damit sogar meine uralte Conrad-Universal-FB vom alten VDR nutzten zu können. Die ist zwar nicht schön und inzwischen ziemlich abgenutzt aber super ergonimisch.

Tschüss Jo

Ooops, irgendwie haben mich die Benachrichtigungen über Eure Antworten nicht erreicht. Für mich liest sich das so als würde ich die HAMA-MCE am besten komplett versenken und einen anderen Empfänger verwenden.

Seltsam, dass ich so viel Empfehlungen für die HAMA-MCE wahrgenommen habe. Die Fernbedienung selbst finde ich nicht wirklich nutzerfreundlich: Falsche Anordnung der Farbtasten, Tastenlayout unglücklich (einhändige Bedienung fast unmöglich), Tasten zu klein, schlechte Ergonomie. Dazu taugt der Empfänger nicht viel (nicht kompatibel mit programierbaren Fernbedienungen, kein Wakeup) Also ein Griff ins Klo. Das Geld kann ich verkraften aber ich ärgere mich über die verlorene Zeit.

Tschüss Jo

Hallo,

habe an meinem yaVDR 0.5 einen HAMA-MCE Empfänger. Mit der Hama-Fernbedienung klappt das soweit auch gut, bis auf das, dass uns die HAMA-FB überhaupt nicht gefällt. Jetzt habe ich die Universalfenbedienung OneForAll 7960 gekauft.
Soweit ich das bisher innerhalb von yaVDR gesehen habe ist der Empfänger als USBHID eingebunden, demnach wird LIRC ja nach meinem Kenntnisstand ned verwendet, oder?

In diversen Threads habe ich gesehen, dass man als Game den Code 1972 einstellen soll. Allerdings blinkt der Empfänger nicht auf wenn dieser Code eingestellt ist. Daraus würde ich interpretieren, dass der Empfänger mit dem eingestellten Code überhaupt nichts anfangen kann.
Anlernen der FB funktioniert, d.h. die FB funktioniert, allerdings ist das aber nicht wirklich zuverlässig.

Wie kann ich dem Empfänger beibringen, dass er auf die Universalfernbedienung reagieren soll?

Tschüss Jol

Hallo,

habe eine USB-Festplatte an meinem VDR hängen. Die Festplatte ist per /etc/fstab auf /srv/vdr/video.01 eingebunden.

Jetzt habe ich damit zwei Probleme:
1. Problem:
Der VDR legt neue Aufnamen nicht auf der externen Platte ab, obwohl dort mehr Platz ist als auf der internen (video.00).
Wird die VDR-SW neu gestartet ohne den PC neu zu startetn werden die neuen Aufnahmen auf der externen Platte abgelegt.

Ich vermute, dass die Platte beim Start des VDR noch nicht eingebunden ist und der VDR im laufenden Betrieb nicht mehr überprüft ob da was neues hinzugekommen ist.
Ist das die Ursache? Wie kann ich dem VDR sagen, dass er eine neue Platte bekommen hat?

2. Problem:
Selbst wenn der VDR die Aufnahmen auf der externen Platte ablegt findet er die alten Aufnahmen nicht.
Auch ein .update hilft nicht.

Füge ich einen Link ein video.01 -> video.00/extern werden die Aufnahmen unter extern gefunden, aber das ist ja hässlich.

Habt Ihr dafür eine Erklärung?

root@yavdr:/etc# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sda1 during installation
UUID=7d496e30-c7c0-4f88-a768-7cd314b4e918 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=f451585a-99de-40df-93c1-6469d7e12236 none            swap    sw              0       0


UUID=4a63200d-02fc-4fb8-9f83-210eef12e1bf       /srv/vdr/video.01       xfs     defaults        0       0
#/dev/sdb1      /srv/vdr/video.01       xfs     defaults        0       0

root@yavdr:/etc# blkid /dev/sdb1
/dev/sdb1: UUID="4a63200d-02fc-4fb8-9f83-210eef12e1bf" TYPE="xfs" 
root@yavdr:/etc# mount
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/dev/sdb1 on /srv/vdr/video.01 type xfs (rw)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw)
/srv/vdr/video.01;/srv/vdr/video.00 on /srv/share/vdr type fuse.mhddfs (rw,nosuid,nodev)
nfsd on /proc/fs/nfsd type nfsd (rw)

Danke für Eure Tipps
Tschüss JoL

Zitat von Argus

falls es Dich weiterhin interessiert , die Sache mit dem lückenden Strom ist hier ganz anschaulich erklärt --> http://www.sprut.de/electronic/switch/schalt.html (ganz unten, GAP Zeit)

generell sollten SNTs ab etwa 10% der Nennleistung betrieben werden. Darunter wird mow. jedes SNT dann Geräusche machen. Ob die dann aber störend wirken , ist eine andere Sache. Ich kenne kaum ein aktuelles, was im Stb oder Leerlauf wirklich nervt (ausgenommen einige wenige Pollin NTs).
Ist es das von fnu empfohlene 90Watt NT? Da sollte es doch Erfahrungen hier im Forum geben und dann dürfte das wohl ein Ausreißer sein.

Hallo,

danke für den Hinweis mit dem 'lückenden Strom'.
Es ist das von fnu empfohlene Netzteil. Da sich nieman anderes beklagt ist es vermutlich ein Ausreiser.
Habe mal alles abgezogen und da sind die Geräuche gering, Wenn ich allerdings die PicoPSU anstecke fängt's an zu Pfeifen, wobei die Geräuche deutlich vom Netzteil und nicht von der PicoPSU kommen.

Der Lieferant (elpro) bietet mir zwar an das Netzteil zurück zu schicken, damit er es prüfen kann, allerdings bin ich dann mindestens eine Woche ohne Netzteil.
Ich schätze, dass Elpro dann auch keinen Fehler anerkennt wenn das NT ganz ohne Last kaum hörbar ist.

Tschüss JoL

Zitat von Argus

jo, ist verständlich und auch erklärbar.
So ein Schaltnetzteil sind quasi zwei Schalter die wechselweise eine Spule umpolen. Diese Spule wird aufgeladen umgepolt und gibt dann Leistung ab. Das geschieht mit einigen hundert Khz und ist somit unhörbar. Wenn nun keine Energie abgenommen wird, dann verbleibt die Spannung in der Spule, das Regelverhalten zum Spannungserhalt wird schlechter und das reicht dann runter bis in den hörbaren Bereich.

wird es auch, wird aber an den lärmenden Spulen nichts ändern. Hinten am Netzteil kommt eine Gleichspannung mit einer gewissen Menge Ripple and Noise heraus. Ein Kondensator versucht das zwar zu glätten, aber durch die scharfen Flanken vom Ripple fließen recht hohe Ströme, die dann vom Ri des Kondensators in Wärme umgesetzt werden und schaltfeste Kondensatoren mit geringem ESR voraussetzen. Recht große Elkos können den Überlastschutz des NTs schon ansprechen. Manchmal findet man in den Datenblättern auch Angaben über die maximale Ausgangskapazität

Schaltnetzteile sollten auch nicht unbelastet betrieben werden. Jedoch nerven die meisten Tischnetzteile auch nicht. Das typische "Leerlauftackern" hört man meist nur, wenn man ein Ohr direkt drauf legt. Kann aber auch ein Transportschaden sein. Meist sind die Spulendrähte auf der Spule mit Silikon "schwingungsgedämpft" und da hat sich so eine Silikonwurst gelöst.

Danke für die gute Erklärung, hilft zwar nicht weiter aber es fühlt sich besser an.
Hab den Lieferanten mal angschrieben und hoffe dass er es austauscht.

Bei einem Betrieb mit PicoPSU sehe ich kaum eine Möglichkeit als einen 24/7-Betrieb oder ausgiebige Leerlauf-Zeiten.

Tschüss JoL

Zitat von 3PO

Das Pfeifen kommt von den verbauten billig Drosseln. Du kannst mal versuchen, mit entsprechend geeigneter Vergussmasse diese zu vergießen, oder die Billigdinger durch qualitativ höherwertige zu ersetzten. Aber vermutlich ist der Aufwand ungleich größer, als sich nach einer geeigneten wertigen PSU umzuschauen.

Das ist ein Tischnetzteil, also, alles vergossen und ich komme nicht dran ohne es kaputt zu machen.
Ich dachte MeanWell ist eine renommierte Marke und so richtig billig war das Teil nicht, ok das schützt einen nicht davor, dass billige Teile verbaut werden.

Tschüss Jol

Zitat von 3PO

Kondensatoren an einem Schaltnetzteil?? Das ist wohl keine gute Idee!

Rein Interessehalber, warum ist die Idee ned gut?

Ich schätze da kommt hinten eine gepulste Gleichspannung raus, mit ziemlich harten Kanten der Pulse, oder? Habe mi das bisher noch nicht auf dem Oszi angeschaut.
Eigentlich müsste so ein Netzteil doch mit dem Kondensator zurecht kommen, und dem Kondensator sollte es doch egal sein, solange die Spannung passt.

Tschüss JoL
- Während meiner Lehre und Studium gab's noch keine Schaltnetzteile.

Hallo,

inspiriert durch diesen Thread [Review] ASRock Q1900M (Intel Bay Trail-D) habe ich mir das 90W-Netzteil von MeanWell gekauft.

Leider fällt mir auf, dass das Netzteil im Leerlauf unangenehm pfeift und piept.
Wenn ich die PicoPSU vom Main Board abziehe verändert sich der Ton, ebenso wenn das Netzteil ganz ohne Last ist.
Im Betrieb des Rechners ist der Ton weg.

Ist dieses Piepen ein Defekt bzw Reklamationsgrund?

Kann man durch eventuell durch einen Kondensator in der PicoPSU das Pfeifen bekämpfen? Welche Kapazitäten sind da ggf wirksam/sinnvoll?

Tschüss JoL

Zitat von fnu

USB Tastatur? Wenn ja, nimm mal bitte eine PS2 Tastatur ...

Von diesem Problem habe ich schon gelesen. Nein es ist eine PS2-Tastatur, die funktioniert auch problemlos.

Habe mir jetzt mal in der Not ein DVD-Laufwerk gekauft, in der Hoffnung, dass das funktioniert. Vielleicht bekomme ich ja schneller eine Lösung für mein USB-Problem als dass die CCD gebrannt ist.

Tschüss JoL

Hallo,

heute kam mein neues Mainboard -ASRock Q1900M (Intel Bay Trail-D)- und ich versuche per USB-Installation yaVDR drauf zu bekommen.

Habe das Hybrid-Image gezogen und per "sudo dd if=yavdr64-0.5.0a.hybrid.iso of=/dev/sdc" auf den USB-Stick kopiert.
Der Stick wird erkannt, Grub wird ausgeführt und der Installationsprozess beginnt mit Sprach-, Location- und Tastaturauswahl.

Im Anschluss versucht die Installation das CD-Rom zu mounten, was fehl schlägt.
Wenn ich mit Alt-F2 auf die Console wechsle und dmesg aufrufe bekomme ich auch folgende Nachrichten:

usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb 1-1: device not accepting address 2, error -110
usb 1-1: new high-speed USB device number 3 using ehci_hcd
usb 1-1: device not accepting address 3, error -110
usb 1-1: new high-speed USB device number 4 using ehci_hcd
usb 1-1: device not accepting address 4, error -110
usb 1-1: new high-speed USB device number 5 using ehci_hcd
usb 1-1: device not accepting address 5, error -110
hub 1-0:1.0: unable to enumerate USB device on port 1

Es scheint als kann Linux aus irgend einem Grund den USB-Stick nicht einbinden.

Leider habe ich kein SATA-CD-Laufwerk um von dem zu installieren

Könnt Ihr mir einen Tipp geben wie ich yaVDR auf die Kiste bekomme.
Tschüss Jo

Hallo,

habe gerade das gleiche Problem, allerdings versuche ich per USB-Stick zu installieren. Das System bootet vom USB-Stick ich gehe durch die ersten Dialoge wie Sprach und Tastatureinstellung, allerdings schlägt er dann fehl beim Versuch die CD einzubinden.
Habe auch mit Alt-F2 auf eine Console gewechselt finde aber kein Device /dev/sdX.

Der Memest des GRUB läuft ohne Fehler.

Habt Ihre eine Idee was ich tun kann?

Tschüss JoL

Zitat von benilo

Also in das im Zusammenstellungsthread beschriebene Gehäuse passt alles perfekt rein, das ist kein Problem.

Mag schon sein, dass alles rein passt, leider passt das Gehäuse nicht in unser Wohnzimmer. Nebenan steht ein silberner Audioverstärker, da muss das VDR-Gehäuse auch Silber sein. Leider gibt Dein Gehäuse nur in schwarz.

Tschüss Jol