[Bitte um eure Mithilfe] VDR: Wiedergabe einer Aufnahme stoppen benötigt mal mehr mal weniger Zeit bis ich wieder Livebild angezeigt bekomme

  • Hallo Portal,


    edit: Bitte beachtet meinen Aufruf auf Seite 2


    ich bin nicht ganz sicher ob es vom VDR kommt oder von softhddev. Mir ist aufgefallen, dass es manchmal sehr viel länger dauert aus einer Wiedergabe auszusteigen als ich es von früher (meiner alten Installation) gewohnt bin. Ich habe mal die logs für einen schnellen Ausstieg, und einen langsamen Aussstieg aus der Wiedergabe zusammengestellt.


    Hardware enspricht der Signatur, allerdings kommt vdpau zum Einsatz. Software ist relativ frisch installiert. VDR version ist 1.7.31 und softhddev ist frisch aus dem git (gestern Abend) compiliert. FFmpeg Version ist 1:1.0. Zunächst dachte ich es läg evtl. an der softhddev version die ich mir vor einigen Wochen mal compiliert hatte. Aber auch mit dem aktuellen Stand hat sich nichts geändert.


    Mit der neuesten softhddev Version geht mir allerdings nach einiger Zeit plötzlich das Bild weg weil der Rechner anscheinend aufgrund des Energiesparfahrplans schwarz anzeigt. Das hat er vorher auch aber nur wenn softhddev detached war. Gab es da eine Änderung?


    Hier die logs:


    Schneller Ausstieg (ca. eine halbe Sekunde)



    Langsamer Ausstieg (ca. 4 sek.)


    Man sieht ja auch deutllich, dass zum "vdr vdr[522]: [522] switching to channel 48" ganze 3 Sekunden vergehen.


    Gruß
    Atech

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

    3 Mal editiert, zuletzt von Atechsystem ()

  • Mit der neuesten softhddev Version geht mir allerdings nach einiger Zeit plötzlich das Bild weg weil der Rechner anscheinend aufgrund des Energiesparfahrplans schwarz anzeigt. Das hat er vorher auch aber nur wenn softhddev detached war. Gab es da eine Änderung?


    softhddevice Bildschirmschoner

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Es gab da viele Änderungen. In der aktuellen Version werden die Puffer vom Plugin vollgefülllt.
    Ich weiß jetzt nicht ob der VDR etwas zum löschen sendet. Es sind bis zu 8s gepuffert.
    Und ich denke dieses Nachlaufen siehst du.


    Du kannst mit -DUSE_SOFTLIMIT bauen, dann wird der Alte Code verwendet.
    Ich will dies eigentlich rauswerfen und suche noch die Stellen, warum es drin war.
    Du hast wohl eine gefunden.


    Der Screensaver ist nun Optional, bei normalen Make sollte mit gebaut werden.
    Wenn du aber Distribution benutzt, dann sollte nun ALSA,OSS,VDPAU,VAAPI,... verwendet
    werden.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch


  • Ich weiß jetzt nicht ob der VDR etwas zum löschen sendet. Es sind bis zu 8s gepuffert.
    Und ich denke dieses Nachlaufen siehst du.


    Vielleicht hilft ja das hier:

    Diff
    --- dvbplayer.c 2013/01/27 14:03:16     2.29
    +++ dvbplayer.c 2013/02/08 11:19:16
    @@ -291,6 +291,7 @@
     cDvbPlayer::~cDvbPlayer()
     {
       Save();
    +  Empty();
       Detach();
       delete readFrame; // might not have been stored in the buffer in Action()
       delete index;


    Klaus

  • Code
    Zweigspitze (HEAD) ist jetzt bei d4535a3... Fix xcb deadlock while closing PIP decoder.
    g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__KERNEL_STRICT_NAMES -DUSE_GRAPHTFT  -DAV_INFO -DAV_INFO_TIME=3000   -DUSE_PIP                    	-DUSE_SOFTLIMIT             	-DUSE_SWRESAMPLE -DUSE_VDPAU -DUSE_VAAPI -DUSE_ALSA -DUSE_OSS -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"softhddevice"'  -DGIT_REV='"d4535a3"' -I/usr/include -I/usr/include/vdr -I..   `pkg-config --cflags x11 x11-xcb xcb xcb-xv xcb-shm xcb-dpms xcb-atom xcb-screensaver xcb-randr xcb-glx xcb-icccm xcb-keysyms` `pkg-config --cflags gl glu` 	`pkg-config --cflags libva-x11 libva-glx libva`  `pkg-config --cflags alsa`   -c -o softhddevice.o softhddevice.cpp


    Ich habe jetzt -DUSE_SOFTLIMIT eingebaut. Aber das ändert leider nichts. Manchmal läuft das Bild kurz nach, dann bleibt es stehen und dann dauert es eine Weile bis das Livebild wiederkehrt:



    Kann das ganze mit dem alsa underrun zusammenhängen?


    Code
    Feb 08 13:09:51 vdr vdr[6398]: audio/alsa: wait underrun error? 'Datenübergabe unterbrochen (broken pipe)'
    Feb 08 13:09:51 vdr vdr[6398]: video: slow down video, duping frame
    Feb 08 13:09:51 vdr vdr[6398]: video: decoder buffer empty, duping frame (950/163) 0 v-buf
    Feb 08 13:09:51 vdr vdr[6398]: video: 11:38:11.199+8888	0   0/\ms   0+0 v-buf
    Feb 08 13:09:54 vdr vdr[6398]: [6398] switching to channel 21


    Gruß
    Atech

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight


  • Vielleicht hilft ja das hier:

    Diff
    --- dvbplayer.c 2013/01/27 14:03:16     2.29
    +++ dvbplayer.c 2013/02/08 11:19:16
    @@ -291,6 +291,7 @@
     cDvbPlayer::~cDvbPlayer()
     {
       Save();
    +  Empty();
       Detach();
       delete readFrame; // might not have been stored in the buffer in Action()
       delete index;


    Klaus

    Würd emir da sjetzt auch helfen oder ist das eine Idee für Johns?


    Gruß
    Atech

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

  • Klaus
    Würd emir da sjetzt auch helfen oder ist das eine Idee für Johns?


    Ich schätze beides.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470


  • Es war als Antwort auf "johns" Frage und als Hinweis für einen möglichen Fix im VDR gedacht.
    Probier's bitte mal aus.


    Klaus

    Ich habe den Patch eingebaut, aber leider hat sich nichts geändert.


    Ich habe jetzt verschiedene git stände von softhddev durch und bin jetzt bis http://projects.vdr-developer.…4d91506c6d9dc98fb713fdabf (das ist das letzte update beim archvdr) zurückgegangen aber keine Veränderungen. Soll ich mal die 0.5.2er versuchen?


    Danke für eure HIlfe...


    Gruß
    Atech

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

  • Auffällig ist, wenn ich eine Aufnahme das erste mal starte dann geht er beim stoppen schnell in den Livemodus. Beim zweiten mal dauert es dann immer lange. Wie beschrieben erstmal Nachlaufen, dann steht das Bild der Aufnahme und dann geht er irgendwann in den Live Modus.

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

  • Wie beschrieben erstmal Nachlaufen, dann steht das Bild der Aufnahme und dann geht er irgendwann in den Live Modus.

    Ich muss mich korrigieren, das Nachlaufen ist weg. Bild bleibt stehen, es dauert eine Weile und dann kommt wieder Livebild.....


    Der Patch von Klaus scheint zu helfen.

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

  • Wollte ich gerade auch schreiben, ist extrem deutlich zumerken.


    Die Frage ist, will man dies?


    Ich könnte auch am SetPlayMode oder Ähnlichen erkennen ob was Neues kommt,
    dann die Puffer zum leeren vormerken, sobald dann der neue Stream bereit ist, die Puffer leeren.
    Vorraussetzung ist, daß der VDR nicht auf Puffer leer wartet.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Ich muss mich korrigieren, das Nachlaufen ist weg. Bild bleibt stehen, es dauert eine Weile und dann kommt wieder Livebild.....


    Der Patch von Klaus scheint zu helfen.


    OK, wenn das wirklich was bringt, dann bau ich das für die nächste Version ein.
    Wirkt ja auch irgendwie logisch, denn wenn das primäre Device nicht selber empfangen kann, dann ist es praktisch dauernd im Wiedergabemodus, und wenn da keiner sagt, es soll seine Puffer löschen (die bei der Wiedergabe einer Aufzeichnung ja meist randvoll sind), dann kann sowas schon passieren.
    Allerdings könnte das Device seine Puffer natürlich auch im SetPlayMode(pmNone) löschen. Das zusätzliche Empty() im ~cDvbPlayer schadet sicher nicht, aber ich würde dennoch empfehlen, im softhddevice in SetPlayMode() für den Fall pmNone alle Puffer zu löschen (falls das nicht bereits geschieht, allerdings kann ich mir dann nciht erklären, warum obiger Patch was verändert hat).


    Klaus

  • Wollte ich gerade auch schreiben, ist extrem deutlich zumerken.


    Die Frage ist, will man dies?


    Ich könnte auch am SetPlayMode oder Ähnlichen erkennen ob was Neues kommt,
    dann die Puffer zum leeren vormerken, sobald dann der neue Stream bereit ist, die Puffer leeren.
    Vorraussetzung ist, daß der VDR nicht auf Puffer leer wartet.


    O, da bist du mir zuvorgekommen ;)


    VDR wartet gegen Ende einer Wiedergabe nur darauf, daß die letzte PTS bei GetSTC() kommt. Wenn man die Wiedergabe manuell abbricht, wird auf nichts gewartet.
    In SetPlayMode() bei pmNone die Puffer zu löschen wäre sicher nicht verkehrt. Ich würde sie auch nicht erst lange "vormerken", sondern die Wiedergabe sofort beenden und die Puffer löschen. Sonst hat der User kein unmittelbares Feedback.


    Klaus

  • Kann man denn an der langen Wartezeit, die vom stoppen bis zur Livewiedergabe manchmal vergeht noch etwas machen? Es passiert ja 3 Sekunden einfach nichts???


    Code
    Feb 08 13:09:51 vdr vdr[6398]: video: decoder buffer empty, duping frame (950/163) 0 v-buf
    Feb 08 13:09:51 vdr vdr[6398]: video: 11:38:11.199+8888	0   0/\ms   0+0 v-buf
    Feb 08 13:09:54 vdr vdr[6398]: [6398] switching to channel 21

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

  • Kann man denn an der langen Wartezeit, die vom stoppen bis zur Livewiedergabe manchmal vergeht noch etwas machen? Es passiert ja 3 Sekunden einfach nichts???


    Code
    Feb 08 13:09:51 vdr vdr[6398]: video: decoder buffer empty, duping frame (950/163) 0 v-buf
    Feb 08 13:09:51 vdr vdr[6398]: video: 11:38:11.199+8888	0   0/\ms   0+0 v-buf
    Feb 08 13:09:54 vdr vdr[6398]: [6398] switching to channel 21


    Kannst du das Verhalten gezielt herbeiführen? Wenn ja, dann würden mich die nötigen Randbedingungen interessieren, damit ich das hier nachvollziehen kann (zwar nicht mit softhddevice, aber ich schätze mal, daß das davon unabhängig ist).


    Setz doch mal versuchsweise in vdr.c MINCHANNELWAIT auf einen kleineren Wert.
    Ändert das was?


    Klaus

  • Kannst du das Verhalten gezielt herbeiführen? Wenn ja, dann würden mich die nötigen Randbedingungen interessieren, damit ich das hier nachvollziehen kann (zwar nicht mit softhddevice, aber ich schätze mal, daß das davon unabhängig ist).


    Setz doch mal versuchsweise in vdr.c MINCHANNELWAIT auf einen kleineren Wert.
    Ändert das was?

    Ich bin grade dabei die änderung in der vdr.c zu kompilieren. Bis ich es austesten kann wird es noch dauern - kann den VDR grade nicht stoppen.


    Gezielt herbeiführen ist schwierig. Auffällig ist, dass es meistens nach dem zweiten start einer Wiedergabe der selben Aufnahme dazu kommt. Dann auch wiederholbar. Irgendwann geht er wieder normal heraus und dann im direkten Anschluss kommt wieder die Verzögerung. Wie schon gesagt ich habe hier den 1.7.31 - eine neuere Version könnte ich nur auf meiner Testplatte mal ausprobieren. Wäre das Sinnvoll?

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

  • Wie schon gesagt ich habe hier den 1.7.31 - eine neuere Version könnte ich nur auf meiner Testplatte mal ausprobieren. Wäre das Sinnvoll?


    Bei der Fehlersuche ist es natürlich immer sinnvoll, erstmal die allerneueste Version zu probieren ;-).
    Im Zusammenhang mit MINCHANNELWAIT hat sich aber, soweit ich sehe, seit der 1.7.31 nichts geändert. Insofern kannst du es auch ruhig damit probieren.


    Klaus


  • Bei der Fehlersuche ist es natürlich immer sinnvoll, erstmal die allerneueste Version zu probieren ;-).
    Im Zusammenhang mit MINCHANNELWAIT hat sich aber, soweit ich sehe, seit der 1.7.31 nichts geändert. Insofern kannst du es auch ruhig damit probieren.


    Klaus

    Ja, das hat auf jedenfall geholfen. Habe den Wert jetzt MINCHANNELWAIT auf 1 gesetzt. Es gibt ca 1,5 Sekunden verzögerung nachdem ich auf Stop gedrückt habe.


    Kann der geänderte Wert jetzt zu anderen Problemen führen?

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight


  • O, da bist du mir zuvorgekommen ;)


    VDR wartet gegen Ende einer Wiedergabe nur darauf, daß die letzte PTS bei GetSTC() kommt. Wenn man die Wiedergabe manuell abbricht, wird auf nichts gewartet.
    In SetPlayMode() bei pmNone die Puffer zu löschen wäre sicher nicht verkehrt. Ich würde sie auch nicht erst lange "vormerken", sondern die Wiedergabe sofort beenden und die Puffer löschen. Sonst hat der User kein unmittelbares Feedback.


    Ich mache dies extra nicht.


    Beim Kanalwechsel dauert es ja eine gewisse Zeit bis ein komplettes Videobild vorhanden ist und genug gepuffert ist.
    Diese Puffer spiele ich noch ab.
    Dadurch entsteht der Eindruck eines schnelleren Kanalwechsels.
    Sind aber bei LiveTV nur ca. 336ms.


    Da es die anderen Ausgabeplugins nicht brauchen und du lieber nichts ändern willst, ändere ich es in meinem Plugin.


    Atechsystem
    Bis ich es gefixt habe, kannst du ja die Änderung im VDR drin lassen.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!