ZitatDu mußt vdr neu starten, um wieder Fernseh zugucken.
Aber nicht zwingend, eine etwas fragile Aufnahme hat mit gerade auch an die g2vgui (gen2vdr-spezifisch) zurück katapultiert.
Der VDR lies sich nicht reaktivieren, im Prinzip ja auch klar weil er ja noch glaubt aktiv zu sein.
Einmal zu XBMC geswitcht danach konnte ich zum VDR zurückswitchen ohne den VDR beenden zu müssen.
Oder passiert das mit dem VDR Start nur wenn X richtig neben der Spur war.
Dann kann ich nicht mitreden, das ist hier noch nicht vorgekommen. 
Gruß N!ce
Alles anzeigen
Aber nicht zwingend, eine etwas fragile Aufnahme hat mit gerade auch an die g2vgui (gen2vdr-spezifisch) zurück katapultiert.
Der VDR lies sich nicht reaktivieren, im Prinzip ja auch klar weil er ja noch glaubt aktiv zu sein.
Einmal zu XBMC geswitcht danach konnte ich zum VDR zurückswitchen ohne den VDR beenden zu müssen.
Oder passiert das mit dem VDR Start nur wenn X richtig neben der Spur war.
Dann kann ich nicht mitreden, das ist hier noch nicht vorgekommen.
Gruß N!ce
Ich habe mal "resume" von openbox auskommentiert. ein killall openbox bringt das hier:
vdr: audio/alsa: wait underrun error?
vdr: [4207] ERROR: TS packet not accepted in Transfer Mode
vdr: [4208] ERROR: driver buffer overflow on device 1
vdr: [4207] ERROR: TS packet not accepted in Transfer Mode
vdr: [4185] connect from 127.0.0.1, port 38026 - accepted
vdr: [4185] closing SVDRP connection
vdr: [4207] ERROR: TS packet not accepted in Transfer Mode
vdr: last message repeated 3 timesNach einem "start openbox" immer noch kein Bild. Ein "svdrpsend plug softhddevice resu" ändert nichts. Ein ""svdrpsend plug softhddevice susp" bringt das:
vdr: [4185] connect from 127.0.0.1, port 38029 - accepted
vdr: [4185] [softhddev]SetPlayMode: 0
vdr: [4185] [softhddev]SetVideoDisplayFormat: 1Ab da geht nix mehr und es hilft nur noch den VDR neu zu starten.
Starte ich den vdr ohne gestarteten X-Server kommt diese Meldung:
vdr[1605]: segfault at e0 ip 00007fc20ee98a3d sp 00007fffc88c4fb0 error 4 in libvdr-softhddevice.so.1.7.21[7fc20ee80000+24000]Das gleiche passiert wenn ich beim starten -s mitgebe und dann ein resume schicke ohne einen X zu starten.
@C-3PO
libav ist ein Fork von ffmpeg, beide sind in gewissen Grenzen kompatible. Haben aber vergessen eine Unterscheidung einzubauen.
Heist das nun, dass libav installiert werden muss, oder nicht?
BTW: libav 0.8 ist in portage.
Unter Gentoo schließen sich libav und ffmpeg aus. Da aber etliche Pakete ffmpeg voraussetzen (auch das ein oder andere Plugin), liegt mir die Kompatibilität zu ffmpegs libav doch sehr am Herzen. Eine andere Möglichkeit wäre, das softhddevice seine eigene libav mitbringt (wie etwa xbmc oder handbrake).
BTW: Tolles Plugin - toller Job - tolle Reaktionzeit des Entwicklers. In Ahnlehnung an einen Buchtitel: "johns, gibts Dich wirklich, und wenn ja: wie viele?"
Gruß, Ingo
Das gleiche passiert wenn ich beim starten -s mitgebe und dann ein resume schicke ohne einen X zu starten.
Komisch bei mir funktioniert es. Kann ohne X11 starten und resume/suspend ohne X11. Geht dann aber nur Ton.
Heist das nun, dass libav installiert werden muss, oder nicht?
BTW: libav 0.8 ist in portage.
Nein.
Johns
Komisch bei mir funktioniert es. Kann ohne X11 starten und resume/suspend ohne X11. Geht dann aber nur Ton.
Johns
Hmm. Wie sieht denn Deine komplette plugin befehlszeile aus?
Ich versuche es so: --plugin="softhddevice -f -s -g 1920x1080+0+0"
So bekomme ich es nicht ohne X zum laufen.
Neuste Version GIT genommen?
Bei johns bedeutet das, sie darf nicht älter als 5 Minuten sein.
Gerald
Bei mir fliegt nach 5 Minuten das Bild weg, wobei der Ton nach wie vor zu hören ist. Eine Änderung der Parameter im Setup, bzw. das Starten von X durch das Plugin oder extern hat mich nicht weiter gebracht. Hat jemand einen Tip für mich?
Feb 26 10:52:38 xvdr1 vdr: video: 5:40:32.939 -31 603 0/\ms 55 v-buf
Feb 26 10:53:34 xvdr1 vdr: [3514] max. latency time 2 seconds
Feb 26 10:53:34 xvdr1 vdr: video: 5:41:29.279 -47 599 0/\ms 54 v-buf
Feb 26 10:53:34 xvdr1 vdr: video: 5:41:29.299 -42 584 0/\ms 54 v-buf
Feb 26 10:53:34 xvdr1 vdr: video: dropping frame (1/29402)
Feb 26 10:53:35 xvdr1 vdr: video/vdpau: decoder render too slow 93 ms
Feb 26 10:53:35 xvdr1 vdr: video/vdpau: decoder render too slow 93 ms
Feb 26 10:53:35 xvdr1 vdr: video: 5:41:29.399 -145 605 0/\ms 58 v-buf
Feb 26 10:53:35 xvdr1 vdr: video: 5:41:29.419 -140 590 0/\ms 59 v-buf
Feb 26 10:53:35 xvdr1 vdr: video: dropping frame (2/29406)
Feb 26 10:53:35 xvdr1 vdr: video: missed frame (8/29408)
Feb 26 10:53:35 xvdr1 vdr: video: 5:41:29.479 -101 569 0/\ms 55 v-buf
Feb 26 10:53:35 xvdr1 vdr: video: 5:41:29.499 -96 586 0/\ms 57 v-buf
Feb 26 10:53:35 xvdr1 vdr: video: dropping frame (3/29408)
Feb 26 10:53:35 xvdr1 vdr: video: missed frame (9/29410)
Feb 26 10:53:35 xvdr1 vdr: video: 5:41:29.559 -57 597 0/\ms 54 v-buf
Feb 26 10:53:35 xvdr1 vdr: video: 5:41:29.579 -52 581 0/\ms 55 v-buf
Feb 26 10:53:35 xvdr1 vdr: video: dropping frame (4/29410)
Feb 26 10:53:38 xvdr1 vdr: video: 5:41:33.099 +8 579 0/\ms 56 v-bufGruß
iNOB
Hi johns,
Das Plugin läuft war stabil, aber das Timeing zu alsa läuft häufig weg - removed old cruft version. (siehe Log)
Ich hatte in den letzten Versionen eher underrun errors, darum hängt sich das Plugin bei mir nicht weg, wie du in Posting 1019 erklärt hast.
Ich hoffe, du hast schon eine Lösung wegen der ffmpeg/libav Funktion die du zur Driftkorrektur benötigst.
Wobei ich mich frage wann du schläfst, oder was anders machst als am Plugin zu coden 
Bei mir fliegt nach 5 Minuten das Bild weg, wobei der Ton nach wie vor zu hören ist. Eine Änderung der Parameter im Setup, bzw. das Starten von X durch das Plugin oder extern hat mich nicht weiter gebracht. Hat jemand einen Tip für mich?
Im Log deutet nichts auf Probleme hin.
Feb 26 10:53:35 xvdr1 vdr: video/vdpau: decoder render too slow 93 ms
Da kannst gucken ob ein paar Zeilen (bis 5s) davor ein invalid packet Meldung war. Hat aber nichts mit deinem Problem zutun.
Sollte weiter Bildanzeigen.
Hast Bildschirmschoner aus? Tastatur + Maus an dem Rechner, Maus bewegen oder Shift Taste drücken.
Johns
Hast Bildschirmschoner aus?
ja... war auch mein erster Gedanke. Aber so wie im Wiki beschrieben stehts schon in meiner xorg.conf. Tastatur und Maus hab ich nicht dran, kann aber für den Zweck angestöpselt werden. Ich schau heut Abend nochmal.
Thx
iNOB
Hab seit jeher noch ein Zeile mehr dazu in meinen xorg.conf Dateien:
Section "ServerFlags"
Option "NoPM" "true"
Option "blank time" "0"
Option "standby time" "0"
Option "suspend time" "0"
Option "off time" "0"
EndSection
Evtl. hilft es. An den genauen Issue kann ich mich schon gar nicht mehr erinnern, ist zu lange her, hatte aber was mit Screen-Blanking zu tun ...
Regards
fnu
hatte aber was damit Screen-Blanking zu tun ...
dazu hatte ich sogar mal einen thread aufgemacht und die liebe vdr-gemeinde belästigt - geholfen hat's: [solved] Screen Blanking (unter X) ausschalten?
ZitatAlles anzeigenAudio Buffers
So wie es ausschaut gibt es Sender (z.b. RTL) die nur 300 ms ein PES Packet schicken.
Somit ist jetzt im GIT die BufferTime 336ms.
Im TS Parser habe ich auch noch einen Fehler gefunden, dessen BufferTime ist nun automatisch 216 ms.
Man kann nun den neuen Parser nur mir -DUSE_TS_AUDIO testen.
Ich bitte alle, dies auch zutun, da Dieser Default werden soll.
Johns
ich sehe hier damit keine probleme! (hab aber auch ein einfaches setup: "cinch analog zu TV" / softhddevice: AC3 downmix aktiv)
ciax
hallo,
das ist jetzt nicht besonders wichtig - ich wollt's nur kurz anmerken. wenn ich das "systemplugin" im osd-menü aufrufe, kommt ein segfault (libnvidia-tls.so.295.20):
Feb 27 16:51:53 pvr vdr: [2571] systeminfo thread started (pid=2517, tid=2571)
Feb 27 16:51:53 pvr kernel: [32018.034014] systeminfo[2571]: segfault at 10 ip 00007fd4b9865c0f sp 00007fd48bffea98 error 6 in libnvidia-tls.so.295.20[7fd4b9865000+3000]liegt das eher am systeminfo-plug, am nvidia-treiber oder doch an softhddevice?
ansonsten läuft's softhddevice sehr gut - bin immer noch ganz weg von den reaktionszeiten des vdr (die er mit dem plugin wieder erlebt).
gruß, ciax
Alles anzeigenhallo,
das ist jetzt nicht besonders wichtig - ich wollt's nur kurz anmerken. wenn ich das "systemplugin" im osd-menü aufrufe, kommt ein segfault (libnvidia-tls.so.295.20):
CodeFeb 27 16:51:53 pvr vdr: [2571] systeminfo thread started (pid=2517, tid=2571) Feb 27 16:51:53 pvr kernel: [32018.034014] systeminfo[2571]: segfault at 10 ip 00007fd4b9865c0f sp 00007fd48bffea98 error 6 in libnvidia-tls.so.295.20[7fd4b9865000+3000]
liegt das eher am systeminfo-plug, am nvidia-treiber oder doch an softhddevice?
ansonsten läuft's softhddevice sehr gut - bin immer noch ganz weg von den reaktionszeiten des vdr (die er mit dem plugin wieder erlebt).
gruß, ciax
also ich hab durchaus auch alle drei im Einsatz und keinerlei solcher sgefaults
Christian
also ich hab durchaus auch alle drei im Einsatz und keinerlei solcher sgefaults
hmm, schräg - deine aussage führt mich dann ins leere. ich probier's nochmal mit vdr-xine, aber wenn's bei dir läuft .... (bin schon wieder ruhig - hat vrmtl. nichts mit dem thread zu tun).
ciax
also ich hab durchaus auch alle drei im Einsatz und keinerlei solcher sgefaults
Ditto, läuft hier ebenso unauffällig, auch mit nvidia-current 295.20.
Regards
fnu
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
