xineliboutput: Play_PES Buffer overflow (TCP/PIPE)

Bin immer wieder erstaunt welche Kopfstände gemacht werden, um den VDR mitsamt seinen Abhängigkeiten zu starten bzw. zu beenden. Hiermit gehts viel einfacher und bequemer.

Gruß
iNOB

iNOB - genau ich verwende auch runvdr-extreme und möchte es nicht mehr missen

Zu euren Problem, bei xine 1.2 habt ihr doch alle einen externen ffmpeg ?

Zitat

Original von iNOB
Bin immer wieder erstaunt welche Kopfstände gemacht werden, um den VDR mitsamt seinen Abhängigkeiten zu starten bzw. zu beenden. Hiermit gehts viel einfacher und bequemer.

Gruß
iNOB

Wenn man xineliboutput lokal startet ja. Verwerdet man jedoch vdr-sxfe, kann man dies zwar mit runvdr starten, aber falls es sich mal aufhängt ("HDTV-Beta"), muss man es manuell wieder neustarten. Und genau dafür sind tlw. noch Kopfstände nötig.

Marcus

Wenn's den VDR oder das Frontend zusammenreißt, startet das runvdr-extrem-Script nach einstellbarer Vorgabe das Ganze automatisch neu. Auch ohne den X-Server dabei zu beenden, falls gewünscht.

Gruß
iNOB

Wenn das Frontend sich beendet, wird das ganze wohl sicher neu gestartet. Aber kommt rundvdr-extrem auch damit klar, bzw. kann festellen wenn vdr-sxfe die Arbeit einstellt (Play_PES overflow messages), aber sich nicht beendet? Wenn ja, währe das cool. Auf anhieb habe ich aber in der Doku von runvdr-extreme nix derartiges finden können.

Bei mir rennt das komplett getrennt, vdr selber via runvdr-extreme da der so gut wie nie Probleme macht. (lirc ist dabei noch nicht aktiv)

Über ein script starte ich dann vdr-sxfe. Mit irexec kann ich es starten und beenden. Damit ist es dann auch ein leichtes zu xbmc zu wechseln. Vdr rennt dabei immer im Hintergrund und kann brav seine seine recordings machen.
vdr-sxfe.sh:

#!/bin/bash


USERNAME=xbmc


if pidof -s xbmc.bin ; then
   echo "XBMC is running => starting XVDR ..."
   # Try a clean kill
   echo "Closing XBMC!"
   ps aux|grep -v grep|grep -i xbmc.bin|awk '{print $2}'|xargs kill
   # takes a second or two to die with the soft kill
   sleep 2
   if pidof -s xbmc.bin ; then
      ps aux|grep -v grep|grep -i xbmc.bin|awk '{print $2}'|xargs kill -9
      echo "XBMC stopped (hard)"
   else
      echo "XBMC stopped (soft)"
fi
fi
killall -9 vdr-sxfe


    su $USERNAME -c "export DISPLAY=:0 && export XAUTHORITY=/home/$USERNAME/.Xauthority && xrandr -r 50.0"
    sleep 1
    su $USERNAME -c "vdr-sxfe --syslog --verbose --buffers=1000 --audio=alsa:hw:0,1 --video=vdpau --post tvtime:method=use_vo_driver --reconnect --lirc xvdr+tcp://127.0.0.1 &"
exit 0

xbmc.sh:

#!/bin/bash


USERNAME=xbmc


if pidof -s xbmc.bin ; then
   echo "XBMC is running => starting XVDR ..."
   # Try a clean kill
   echo "Closing XBMC!"
   ps aux|grep -v grep|grep -i xbmc.bin|awk '{print $2}'|xargs kill
   # takes a second or two to die with the soft kill
   sleep 2
   if pidof -s xbmc.bin ; then
      ps aux|grep -v grep|grep -i xbmc.bin|awk '{print $2}'|xargs kill -9
      echo "XBMC stopped (hard)"
   else
      echo "XBMC stopped (soft)"
fi
fi


killall -9 vdr-sxfe


    sleep 1
    su $USERNAME -c "DISPLAY=:0 /usr/bin/xbmc -l -fs &"


exit 0

.lircrc:

begin
	button = tv
	prog = irexec
	repeat = 0
	config = /etc/vdr/scripts/vdr-sxfe.sh
end


begin
	button = vcr
	prog = irexec
	repeat = 0
	config = /etc/vdr/scripts/xbmc.sh
end

Für das beenden von xbmc betreibe ich etwas mehr Aufwand als für vdr-sxfe da xbmc manchmal Sachen nicht mehr abspeichert wenn man es einfach killt.
Lirc ist so auch nur in der jeweiligen Anwendung aktiv.

Gibt´s denn jetzt wirklich jemandem, bei dem der HD-VDR per Software-Decoding ohne diese Abstürze läuft?

Habe es zuletzt vor ca. 4-6 Wochen mit Ubuntu 9.04 probiert, und nachdem es weder auf einem Q9400 mit GeForce 8800, also Intel-Plattform, als auch einem Athlon X2 4300 mit nForce 4 und GeForce 8600 funktioniert hat (immer "Play_PES Buffer overflow" bis hin zum Totalabsturz), bin ich davon ausgegangen, dass es doch eher "Zufallstreffer" sind, wenn es irgendwo anscheinend stabil läuft. Vielleicht waren es auch die Leute mit den 4x50e/5050e-Athlons, bei denen eh durch den fehlenden Speichercontroller eine kleine Art von "Bremse" drin ist, die ja bei meinen beiden Lösungen nicht existiert - als würde diese Bremse das System davon abhalten, den Puffer vollzuschreiben und damit einen Overflow zu generieren ;).

Oder benutzen die, die behaupten, dass es bei ihnen läuft, xine anstelle von xineliboutput? Und wieso tut sich diesbezüglich auch nix in der ML? Die meisten Infos hier scheinen sich um xineliboutput zu drehen.

Warte noch auf die neuen Stromspar-Athlons und dann will ich auch endlich einen "richtigen" neuen VDR aufsetzen, habe aber das Gefühl, dass diese Mühe (noch) umsonst sein könnte. Denn diese Hänger haben einen seeehr geringen WAF (und CHF=Child acceptance factor).

P.S.: Getestet sowohl mit TT DVB-S2 Budget (Q9400) als auch Nova-S2-HD (Athlon X2).

Das einzige das ich dazu sagen kann ist das der PES fehler introduziert wurde in der 185 branch der nvidia treiber...

Met 180.60 gab's kein PES fehler.

Ich möchte gerne nach xine-ui unsteigen, aber der hat keine eingebaute medienspieler.
So ich bin wieder zurück auf xv. Und dass läuft stabil, selbst beider CPU cores wurden angesprochen. Das war in die vergangenheit nicht der fall.

Tag!

Carel

Kommt darauf an was man unter stabil versteht. Meine HW1 ist von letzter Woche Donnerstag bis gestern (da habe ich den Test dann beendet) mit geöffneten vdr-sxfe ohne Probleme durchgelaufen. Ich muss dazu aber sagen das ich über diese 5 Tage nicht 24h am Tag wie wild gezappt habe. (mir ging es mehr darum ob diese Tonaussetzer wieder auftreten und das sind sie nicht.)

Auf HW2 zappt meine Frau doch sehr heftig aber zu 99% SD und das nur 1-2h am Tag und ich frage sie von Zeit zu Zeit ob es den Probleme gab und in letzter Zeit verneinte sie das jedes mal.

Als ich vor paar Monaten von einen FF Karten VDR auf dieses xineliboutput wollte sie mir den neuen PC fast um die Ohren werfen
Diese Probleme sind aber nun alle beseitigt.

carel:
xv mag ja gehen, aber dann ist das mit dem Deinterlacing bei 1080i ja nicht so der Hit, wenn´s über die CPU läuft.

Hallo,

im Laufenden Betrieb habe ich die Probleme eigentlich selten, sondern sporadisch nur, wenn vdr-sxfe gestartet wird (nach Reboot oder beim Beenden zwischendrin).

Ich nutze nun runvdr mit folgendem Watchdog: [ANNOUNCE] runvdr extreme 0.4 - klappt eigentlich hervorragend.

Gruss
Marcus

GIbts jetzt eigentlich eine richtige Lösung?? Also außer das das Frontend neu gestartet wird??
Habe das mit der aktuellen Easyvdr 0.7.14Beta nämlich auch

cXinelibServer::Play_PES Buffer overflow (TCP/PIPE)

oft stürzt das fontend ja nicht mal ab. Da sieht mans nur im syslog und das man ca 1 sek standbild hat

HI,

ich habe jetzt auf die vdr verseion 1.7.11 incl extensions Patch gewechselt.
Jetzt habe ich den Fehler bei jedem vdr start!!!. So stark das vdr-sxfe nach 2 sek abschmiert und ein standbild liefert.

Wenn ich innerhalb dieser 2 sek umschalte, ist alles io. Dann wird umsgeschaltet,, die fehler sind weg und alles läuft perfekt. Auch alle folgenden Umschaltvorgänge. HAbe die buffers schon von 5000 auf 100 gestellt. An den fehlern ändert sich nicx nur das die umschaltzeit etwas schneller ist....

ich bin etwas ratlos...

Hallo,
habe ähnliche Probelme mit meinem freevdr 2.1b - (Ausgabe über xineliboutput) aber nur, wenn ich an der asound.conf rumfummle. Hab jetzt mal digital Ton benutzen im DVB-Menü deaktiviert und in der asound.conf nur folgende Einträge drin:

pcm.!default {
type hw
card 0
device 0
}

... damit geht's erstmal ohne abschmieren und Start von xbmc. Weiß zwar nicht, ob das was mit Eueren Probs zu tun hat, aber vielleicht ist es ja mal 'ne Spur.

yam

Also ich nutze kein HDTV und keine Hardware Beschleunigung mit closed Source treibern. Habe aber trotzdem das Problem

Mar  3 21:10:06 server vdr-sxfe[28837]: [28853] [demux_vdr] audio stream changed: 00000000 -> 03010000
Mar  3 21:10:07 server vdr-sxfe[28837]: [28853] [demux_vdr] ts2es: payload not PES ?
Mar  3 21:10:07 server last message repeated 3 times
Mar  3 21:10:08 server vdrdevel: [28706] [xine..put] cXinelibServer::Play_PES Buffer overflow (TCP/PIPE)
Mar  3 21:10:11 server last message repeated 1000 times
Mar  3 21:10:11 server vdrdevel: [28706] [xine..put] cXinelibServer: Too many TCP buffer overflows, dropping client
Mar  3 21:10:11 server vdrdevel: [28706] [xine..put] cXinelibServer::Play_PES Write/Queue error (TCP/PIPE)
Mar  3 21:10:11 server vdrdevel: [28706] [xine..put] Closing connection 0
Mar  3 21:10:12 server vdr-sxfe[28837]: [28852] [input_vdr] Control stream disconnected
Mar  3 21:10:12 server vdr-sxfe[28837]: [28852] [input_vdr] Control thread terminated

Ich habe keine Lösung dafür.

Gruss,

Jörg

Habe noch was hier gepostet. Scheint evtl dasselbe Problem zu sein ?

Kann das Problem von mir jemand nachvollziehen ?

Gruss,

Jörg

Zitat

Original von yam
Hallo,
habe ähnliche Probelme mit meinem freevdr 2.1b - (Ausgabe über xineliboutput) aber nur, wenn ich an der asound.conf rumfummle. Hab jetzt mal digital Ton benutzen im DVB-Menü deaktiviert und in der asound.conf nur folgende Einträge drin:

pcm.!default {
type hw
card 0
device 0
}

... damit geht's erstmal ohne abschmieren und Start von xbmc. Weiß zwar nicht, ob das was mit Eueren Probs zu tun hat, aber vielleicht ist es ja mal 'ne Spur.

yam

Alles anzeigen

... bei mir waren's die Buffer: http://www.freevdr.de/forum/in…,956.msg6199.html#msg6199

yam

Bei mir ist es die FF Karte. Nachdem ich nur noch meine Budget Karte aktiviert habe sind die Probleme weg. Ich denke mal das es am nicht durchgeführten Full-TS Mod liegt (Bandbreitenbeschränkung) Aber das macht nix. Brauche die FF Karte sowieso nicht mehr als Ausgabedevice. Dann muss ich mal schaun wie ich meine FB nun anschliesse.

Gruss,

Jörg

P.S.: Im VDR Aufruf einfach mal mit -Dx die Karte selektieren wenn hier noch jemand eine FF und Budget Kombi im Einsatz hat. Wirkt eventuell Wunder