engine.buffers.video_num_buffers:250

Ich krieg plague

Hab nu 2 Installationen von ct-vdr mit vdpau, naja, eigentlich nur eine, die andere weigert sich vdpau auch zu benutzen...

die eine die läuft ist wunderbar um HD-Filme abzuspulen, aber bei SD-TV ist Schluss mit lustig...
nu tippe ich mal auf die buffers...
Habe entsprechend den Wert engine.buffers.video_num_buffers (von einer anderen Inst aus) auf 1000 eingestellt... Das geht auch soweit gut, daß ich nach dem Anstarten von vdr-sxfe noch diese 1000 in der config_xineliboutput habe... Hab eben nen mkv geschaut, dann nen TV-Mitschnitt angeworfen und irgendwann noch mal in die Datei geschaut... und dann stand da wieder 250...
Irgendein Modul muss den Wert verändern - aber welches Modul und wo nimmt es diese unsäglichen 250 her? Wäre echt hilfreich wenn mir jemand sagen könnte, wo AUSSER in der cong_xineliboutput ich noch einen Wert für engine.buffers.video_num_buffers setzen kann/muss.

Danke.

Edit: Auch wenn es nicht zur Überschrift passt: Ich hatte eben den Effekt, daß während die Ausgabe vom vdr hing sogar der mauszeiger einfror? Keine Ahnung wo da die CPUzeit hingeht?

Leider nein - zumindest nicht offensichtlich...
Bei den ganzen Einträgen dort zu xineliboutput finde ich leider weder etwas zu diesen buffern, noch die "250" (Standardwert der immer wieder auftaucht)...

Das var/lib/vdrdevel/plugins/xineliboutput ist bei mir leer, da steht also auch nix...

Der Wert wird offenbar in dem Moment überschrieben wenn ich vdr-xine starte.
Wo kann denn der Wert in dem Moment noch herkommen?

Danke.

Zitat

Original von gda

vdr-xine hat jetzt aber nichts mit xineliboutput zu tun. Wenn du vdr-sxfe meinst, dann lies mal hier.

Gerald

Jo, ich meinte vdr-sxfe :o)

Hmm - da gibt es also keine config weil ich lokal arbeite? Damit kann ich leben^^
Allerdings habe ich dann immer noch das Problem WO diese 250 herkommen - wo NICHT weiss ich ja langsam*G

Also einstellen kann man es wohl - gibt auch genug Einträge wo man die buffer hochsetzen soll weil sonst das passiert, unter dem ich derzeit leben - nach einer gewissen Zeit bekomme ich buffer_overflows in der syslog, der stream wird disconnected und ich "darf" vdr-sxfe neu starten...

Hmm, ok, Danke:o)
Im ersten Versuch hat es trotzdem noch mal den falschen Wert in die Datei geschrieben obwohl mit 1000 aufgerufen... beim zweiten Anlauf hat er die 1000 gelassen... nur leider hängt der vdr sich trotzdem weg...
Ist ja auch erst der x-te Versuch... Wenn ich sonst nix zu tun hätte könnte ich den Winter durch mit dem Ding die Langeweile bekämpfen^

Aber Danke, dann liegt es da schon mal nicht dran^^

Zitat

Originally posted by wbreu
Hi,

solange du keine vernünftigen Logausgaben in deinen Posts hast, wird dir bei deinem/deinen Problem/Problemen auch keiner helfen können.

Wenn ich ein Log gehabt hätte wäre ich ja weitergekommen^^
Das Problem war eben daß irgendwas reingeschrieben hat und ich nicht wusste wer oder was...

Aktuell das mit den Abstürzen - das ist wohl das Ding mit dem buffer-overflow - ich hatte gehofft das mit dem grösseren Buffer umgehen zu können... aber da war ich wohl auf dem falschen Dampfer...
Die "Lösungen" zu dem buffer_overflow gehen aber aber meinen Horzizont/meine Leidensfähigkeit - irgendwelche Versionen zu würfeln und neuzubauen etc... Da streich ich mal die Segel...

Wäre aber gut wenn mir jemand sagen könnte ob es einen *einfachen* Weg gibt, den vdr zu überzeugen beide Kerne zu nutzen... dann würde ich erstmal auch ohne vdpau auskommen... Im Moment ist es aber so, daß bei der Inst. ohne vdpau ein Kern bei 100% schwitzt, die Ausgabe stockt und der andere Kern sich langweilt... also bei Abspielen von HD-Material.

****
hier noch mal die Fehlerausgabe, also vom Anstarten bis zum Tschüss aus der syslog:
Oct 15 11:49:49 vdrHD vdrdevel: [3275] changing pids of channel 1310 from 401+401=2:402=deu:0:0 to 501+501=2:502=deu:0:0
Oct 15 11:50:09 vdrHD vdrdevel: [3279] [discovery] Received valid discovery message VDR xineliboutput DISCOVERY 1.0#015#012Client: 255.255.255.255:37890#015#012#015
Oct 15 11:50:09 vdrHD vdrdevel: [3279] [discovery] BROADCAST: VDR xineliboutput DISCOVERY 1.0#015#012Server port: 37890#015#012Server address: 127.0.0.1#015#012Server version: xineliboutput-1.0.90-cvs#015#012#015
Oct 15 11:50:09 vdrHD vdrdevel: [3279] [xine..put] Client 0 connected: 127.0.0.1:46679
Oct 15 11:50:09 vdrHD vdrdevel: [3279] [xine..put] cxSocket: setsockopt(SO_SNDBUF): got 262142 bytes
Oct 15 11:50:09 vdrHD vdrdevel: [3279] [xine..put] Trying PIPE connection ...
Oct 15 11:50:09 vdrHD vdrdevel: [3279] creating directory /var/lib/vdrdevel/plugins/xineliboutput/pipes.3191
Oct 15 11:50:09 vdrHD vdrdevel: [3279] removing /var/lib/vdrdevel/plugins/xineliboutput/pipes.3191
Oct 15 11:50:09 vdrHD vdrdevel: [3279] [xine..put] cBackgroundWriterI initialized (buffer 512 kb)
Oct 15 11:50:09 vdrHD vdrdevel: [3279] [xine..put] cTcpWriter initialized (buffer 512 kb)
Oct 15 11:50:09 vdrHD vdrdevel: [3279] [xine..put] Pipe open
Oct 15 11:50:49 vdrHD vdrdevel: [3275] changing pids of channel 1310 from 501+501=2:502=deu:0:0 to 401+401=2:402=deu:0:0
Oct 15 11:51:52 vdrHD vdrdevel: [3275] changing pids of channel 1310 from 401+401=2:402=deu:0:0 to 501+501=2:502=deu:0:0
Oct 15 11:52:52 vdrHD vdrdevel: [3275] changing pids of channel 1310 from 501+501=2:502=deu:0:0 to 401+401=2:402=deu:0:0
Oct 15 11:53:52 vdrHD vdrdevel: [3275] changing pids of channel 1310 from 401+401=2:402=deu:0:0 to 501+501=2:502=deu:0:0
Oct 15 11:54:52 vdrHD vdrdevel: [3275] changing pids of channel 1310 from 501+501=2:502=deu:0:0 to 401+401=2:402=deu:0:0
Oct 15 11:55:17 vdrHD vdrdevel: [3289] [xine..put] cXinelibServer::Play_PES Buffer overflow (TCP/PIPE)
[...]
Oct 15 11:55:20 vdrHD vdrdevel: [3289] [xine..put] cXinelibServer::Play_PES Buffer overflow (TCP/PIPE)
Oct 15 11:55:20 vdrHD vdrdevel: [3289] [xine..put] cXinelibServer: Too many TCP buffer overflows, dropping client
Oct 15 11:55:20 vdrHD vdrdevel: [3289] [xine..put] cXinelibServer::Play_PES Write/Queue error (TCP/PIPE)
Oct 15 11:55:20 vdrHD vdrdevel: [3289] [xine..put] Closing connection 0

Zitat

Originally posted by gda
Ich habe das schon einige male hier im Portal erklärt, wenn du mit vdr-sxfe arbeitest, dann benutzt du remote. Lokal bedeutet, das ein Plugin mit dem VDR gestartet wird und das Bild ausgibt.
Im Link den ich gepostet habe kann man doch sehen, das vdr-sxfe sehr wohl auf eine config datei zugreifen will. Wieso kommst du jetzt darauf, dass du keine config haben kannst?

Also die Feinheiten sind mir gar nicht so wichtig - wenn es nur laufen würde wie mein "alter" vdr^^

eine config habe ich natürlich - die config_xineliboutput. Nur keine config die im var/lib/... liegt...

hmm, .c definiere ich mal als source die ich dann neu compilieren müsste?

Danke für den Tip, aber ich glaub ich streich hier erstmal die Segel - ich schaffe es nicht mal bei einer neuen Installation reproduzierbar vpau zu bekommen... denke mal die Reihenfolge der verschiedenen Module, plugins etc. ist mir unklar... oder irgendwelche Versionen sind nicht kompatibel...
Daß es keine setup.exe gibt damit kann ich ja leben - aber die howtos sind irgendwie entweder alle mehr oder weniger veraltet oder passen nicht zu meinem System... habs unter ctvdr, lenny frisch, ubuntu, suse versucht und irgendwann kam immer der Moment wo die Anleitung nicht mehr passte...

Ich denke mal ich versuche es später nochmal wenn vdpau etwas ausgereifter ist - bis dahin muss ich wohl umbooten je nachdem ob ich HD oder SD haben will :o)

Die ganzen Geschichten mit xine und xineliboutput und... da steig ich ehrlich nicht durch, wer mit wem und so... und dann mit und ohne cvs, mit und ohne Durchflieger... hatte eigentlich gehofft daß ich ein passendes repo eintrage, mir ein paar plugins runterlade und dann nur noch Anpassungen an die Hardware und meine Wünsche vornehme... Da war ich dann leider von meinem SD-ctvdr zu sehr verwöhnt... denke mal ich bin seit hmm version 3? dabei... jedenfalls seit einem Haufen von Jahren...
Damals habe ich so mit Sachen wie Samba und dergleichen gekämpft...

Aber mit dem Versuch mir einen stabilen HD aufzusetzen war ich wohl entschieden zu optimistisch^^

Danke erstmal für die Tips, ich stelle sicher noch andere dusselige Fragen... mit vdpau werde ich aber wohl erstmal aussetzen bis ich über ein paar Threads gestolpert bin die mich zumindest ein Licht am Ende des Tunnels erahnen lassen:o)

Ich glaube was gelesen zu haben, daß das mit dem lock_display nur für ältere Versionen auftrat.

Hab jetzt Dank des Hinweises mal den buffer erfolgreich auf 2500 gesetzt... hatte dann noch stockende Phasen die aber seltsamerweise nur zu Beginn auftraten... Inzwischen läuft Phoenix aber schon eine ganze Weile ohne sich zu verabschieden... Wenn das so bleibt wäre DAS Problem zumindest schon einmal gelöst (vielleicht nicht optimal, aber es läuft^^)

DANKE:o)

Also falls jemand auf der Suche mal über diesen Thread stolpert - buffers auf 2500 ist keine Lösung sondern nur ein Workaround...
Es hakelt immer noch, im Syslog gibt es ein Nest von vermehrungsfreudigen Buffer_overflows - aber zumindest läuft der vdr-sxfe durch... ab und zu bleibt das Bild stehen und holt dann im Blitzgang wieder auf während der Ton normal weiterläuft... aber wie gesagt, zumindest kann man ihn durchlaufen lassen...