Massive Bild- und Tonstörungen

Hallo!

Leider komme ich nicht mehr weiter, meine Kenntnisse von VDR, XBMC und yaVDR sind doch zu begrenzt. Durch einige Probleme habe ich mich schon durchgebissen, aber jetzt weiss ich nicht weiter.

Ich habe einen neuen PC mit yaVDR 0.5 aufgesetzt. Weil ich SAT>IP benutzen will (Octopus NET C/T-4), habe ich auf die "testing" Repos umgestellt und ein dist-upgrade gemacht.

Im Prinzip laeuft wohl alles. Aber ich bekomme ueber XBMC und ueber vdr-sxfe massifve Bildstörungen wie bei schlechtem Empfang. Die Fehler im syslog sind allerdings verschieden, bei XBMC:
May 19 15:34:11 yabba vdr: [2471] XVDR: sync found at offset 1016 (streamtype: AC3 / 4218 bytes in buffer / framesize: 1792 bytes)
May 19 15:34:11 yabba vdr: [2471] XVDR: sync found at offset 1560 (streamtype: AC3 / 4170 bytes in buffer / framesize: 1792 bytes)
May 19 15:34:11 yabba vdr: [2471] XVDR: sync found at offset 416 (streamtype: MPEG2AUDIO / 2058 bytes in buffer / framesize: 576 bytes)
May 19 15:34:11 yabba vdr: [2471] XVDR: sync found at offset 232 (streamtype: MPEG2AUDIO / 2146 bytes in buffer / framesize: 576 bytes)

und bei sxfe:
May 19 15:48:31 yabba vdr: [3222] ERROR: 109 ring buffer overflows (111296 bytes dropped)
May 19 15:48:37 yabba vdr: [3222] ERROR: 117 ring buffer overflows (115432 bytes dropped)
May 19 15:48:43 yabba vdr: [3222] ERROR: 108 ring buffer overflows (109228 bytes dropped)
May 19 15:48:49 yabba vdr: [3222] ERROR: 113 ring buffer overflows (115432 bytes dropped)

Die Hardware ist eine GeForce GT 630, i3-4130, 4 GB, 80 GB msata-"Platte", sollte also nicht zu schwach sein.

Wegen der XBMC-Fehlermeldungen (die aber vom vdr-Prozess kamen), habe ich intensiv an der Audio-Konfig gefummelt, aber keine Aenderung gesehen. Ich habe in /etc/vdr-sxfe/config_xineliboutput das Audio-Device auf Onboard analog umgeschaltet, jetzt ist der Ton zwar weg, aber die Bildstoerungen sind immer noch da.

Aenderungen an der Audio-Synchronisation bringen's auch nicht. Mal abgesehen davon, dass ich da nur was twiddeln kann, weil ich nicht weiss, was die Einstellungen bewirken.

Ich werde erstmal XBMC aus der Gleichung rauslassen, weil das die Fehlerursachen halbiert.

Hiiiiiilfe!!!
Lupe Christoph

Noch was vielleicht wichtiges - wegen der Graphikkarte, die in nvidia-304 nicht unterstuetzt wird, habe ich nvidia-331 installiert. Leider habe ich kein aelteres Modell, das ich mal einbauen koennte. Nur das Onboard Video.

Zitat von DocViper

WLAN, LAN oder noch schlimmer über Powerline?

Powerline. Wenn 93 Mbit/sec ein Problem machen...

Zitat

Sat-Ausrichtung ist definitiv korrekt. Schon mit anderen Geräten probiert ob der Empfang okay ist?

Das Kabel ist korrekt ausgerichtet (Octopus NET C/T ist ein DVB-C/DVB-T/DVB-T2-Modell, daher der Name. Sorry, haette ich erklaeren sollen. Kabel-Empfang ist mit der Reelbox, die ich ersetzen will, und mit dem DD-TV-Programm OK. Ausser, dass das program SD-Sender nicht mag. Egal, VDR nimmt beide, mit denselben Problemen. Wenn es Probleme mit dem Empfang waeren, wuerde ich hier nicht fragen.

Zitat

Größerern Ausschnitt vom syslog posten sonst fehlt der Zusammenhang.

Ich nehme mal nur dem vdr-sxfe-Teil und kuerze ihn. Wird aber nicht viel bringen.

/var/log/syslog ist angehaengt.

/var/log/upstart/vdr.log:
INFO: validating live server ip '0.0.0.0'
2014-05-19 16:34:52.95689 [2310.139679272773376] INFO tntnet.listener - listen ip=0.0.0.0 port=8008
2014-05-19 16:34:52.95697 [2310.139679272773376] INFO tntnet.tntnet - create 5 worker threads

vdr-sxfe 2.0.0-cvs (build with xine-lib 1.2.2, using xine-lib 1.2.2)

Post plugins: tvtime:method=use_vo_driver
Automatic reconnection enabled
Audio driver: alsa
vo_vdpau: Use lock display synchronization for some vdpau calls
vo_vdpau: vdpau API version : 1
vo_vdpau: vdpau implementation description : NVIDIA VDPAU Driver Shared Library 331.20 Wed Oct 30 17:39:35 PDT 2013
vo_vdpau: maximum video surface size for chroma type 4:2:2 is 4096x4096
vo_vdpau: maximum video surface size for chroma type 4:2:0 is 4096x4096
vo_vdpau: maximum output surface size is 16384x16384
vo_vdpau: hold a maximum of 10 video output surfaces for reuse
vo_vdpau: using 4 output surfaces of size 1360x768 for display queue
configfile: error - tried to update non-num type 0 (key audio.synchronization.av_sync_method, value 1)
ESC[?25lESC[?1cESC[9;0]ESC[?25hESC[?0cconfigfile: error - tried to update non-num type 0 (key audio.synchronization.av_sync_method, value 1)
vdpau_set_property: property=8, value=100
vdpau_set_property: property=2, value=0
vdpau_set_property: property=3, value=128
vdpau_set_property: property=5, value=0
vdpau_set_property: property=24, value=0
vo_vdpau: disable sharpness.
vdpau_set_property: property=25, value=0
vo_vdpau: disable noise reduction.
vdpau_set_property: property=4, value=128
vdpau_set_property: property=1, value=0
vo_vdpau: deinterlace: none
vo_vdpau: set_scaling_level=0
vo_vdpau: enabled features: inverse_telecine=0
vo_vdpau: disable noise reduction.
vo_vdpau: disable sharpness.
vo_vdpau: skip_chroma = 1
vo_vdpau: background_color = 0
vdpau_set_property: property=0, value=1
vo_vdpau: deinterlace: temporal

Sonst ist in den Logfiles nichts relevantes.

Danke,
Lupe

Zitat von TheChief

Wie ist denn die (grobe) Empfangsstärke bei femon?

Aehhh. Ich dumm. Wie bekommen angezeigt?

Lupe

Zitat von TheChief

Würde spontan mal nach diesen Meldungen forschen:

Code

May 19 16:34:57 yabba dhclient: XMT: Solicit on eth0, interval 60860ms.
May 19 16:34:57 yabba dhclient: RCV: Advertise message on eth0 from fe80::e091:f5ff:fe08:1bee.
May 19 16:34:57 yabba dhclient: IA_NA status code NoAddrsAvail.
May 19 16:35:01 yabba vdr: [2376] ERROR: 1 ring buffer overflow (1128 bytes dropped)
May 19 16:35:02 yabba vdr: [2376] SATIP: detected 1 RTP packet errors

Also am DHCP liegt es definitiv nicht. Ich bin ueber SSH kontinuierlich eingeloggt, keinerlei Stoerungen.

Der "ring buffer overflow" ist das richtige Symptom, leider bringt googeln dazu nichts erleuchtendes, genauso wie zu "sync found at offset". Sonst wuerde ich ja nicht hier fragen.

Irgendetwas im vdr kommt mit den empfangenen Paketen nicht mit, vermutlich, weil vdr seinen Output nicht los wird und die Puffer ueberlaufen. Leider bringt diese Erkenntnis ohne bessere VDR-Kenntnisse nichts. Und meine reichen nicht weit genug.

Der SATIP Paketfehler ist wahrscheinlich ein Startproblem, der tritt nicht wieder auf.

Zitat von ATD

Verteilersteckdose!? Powerline mag es oft nicht.Albert

Wenn die Powerline ein Problem macht, muss sie von kleinen Daemonen bessesen sein, die nur die Pakete an die yaVDR-Kiste stoeren und die and Windows durchlassen. Hmmm... Daemonen...

Lupe

Hallo!

Nachdem niemand eine zuendige Indee hatte, habe ich mich getraut, mal auf unstable Repos unzusteigen. Erstmal nur unstable-vdr und unstable-yavdr. Den Rest hebe ich jetzt auch auf unstable. Augen zu und durch!

Das Problem ist weg. Es war also ein a) gefixtes Problem b) in der Software. Vermutlich irgendwie im Zusammenhang mit dem SATIP plugin, das ja noch recht jung ist.

Egal.Auf zum naechsten Problem, das ich im Zusammenhang mit dem VFD oder dem IR-Empfaenger des OrigenAE S14V erwarte.

Lupe

Zitat von seahawk1986

Dann hängt es vermutlich an der curl-Version. Für unstable hatte ich eine neuere Version nach unstable-main gebracht. Ich hatte bislang noch keine Zeit das in testing und stable einzupflegen.

Ansonsten kann ich nur davon abraten unstable-yavdr zu nutzen, da ist einiges kaputtgespielt, das wir für precise vermutlich auch nicht mehr fixen werden.

Danke fuer den Hinweis. Die Repos unstable-main und unstable-xbmc hatte ich zurueckgehalten (bei xbmc bin ich sogar noch auf stable, aber es laeuft ja auch erstmal ohne XBMC):

Zitat von Lupe

Erstmal nur unstable-vdr und unstable-yavdr

Kann also nicht an curl gelegen haben. Aus unstable-main hole ich mir jetzt nur python-hdftool, weil die unstable-Version von yavdr-utils das will. Wenn ich in Probleme mit unstable-yavdr laufe, umgehe ich die oder downgrade das entsprechende Paket.

Schaunmermal.
Lupe

Zitat von mini73

Mischen von unstable mit den anderen Generationen wird definitiv zu Problemen führen. Du solltest dann besser auf testing, evtl testing-vdr-dev gehen, weil da ein vdr 2.1.6 ist. Oder Pakete lokal selbst bauen bzw. ein eigenes PPA aufsetzen.

Von unseren unstable-PPAs kann ich nur abraten.

Tjae. Das Leben ist hart Die unstable Repos habe ich ja nicht aus Jux und Dollerei genommen, sondern um das Problem zu loesen, um das es in diesem Thread geht. Ich habe keinen Bock, alles nachzuvollziehen, was von testing zu unstable fuehrt, und dann rauszufinden, was davon mein Problem loest. Da ich sowieso gerade am lcdproc-Plugin bastele (UTF-8 Umsetzung), koennte ich vielleicht auch das satip-Plugin in aktueller Version uebersetzen. Wenn ich allerdings einen VDR 2.1 brauche, wird das vielleicht etwas viel... Ich wollte ja eigentlich yaVDR benutzen, damit ich *nicht* alles selbst bauen muss...

Einen Versuch mit dem aktuellen satip-Plugin waere es wert.

Lupe

Zitat von DocViper

Das stable-vdr-fnu kennst du noch nicht?
Das sollte zu yavdr stable "kompartible" sein und bringt 0.3.2 satip mit.

Naja, erstmal hat mich der Disclaimer ein wenig abgeschreckt:

Zitat

This is my personal PPA, I don't care if it doesn't work for others!

Zweitens hatte ich automatisch angenommen, dass eine Kombination von yavdr mit fnu nur Chaos bringt. Oder zumindest bei Fragen sofortiges Abwimmeln ausloest Auf jeden Fall sollte man yavdr *-vdr und fnu *-vdr-fnu nicht mischen, nehme ich mal an.

Aus Neugier werde ich aber auf jeden Fall mal einen Test mit yaVDR testing und einem selbst uebersetzten satip-Plugin machen, ich moechte wissen, ob da die Ursache fuer die Bildstoerungen liegt.

Lupe