[ANNOUNCE] vdr-xine-0.9.4 plugin

    danke rnissl


    mfg traxanos
    ____________________
    Ist das neu?, Nein Linux!


    VDR1: Zotac NM10-ITX Wifi - 2GB Ram - S2-6400 HD mit IR - yavdr 0.4 (development) - LianLi PC-Q11


    Tags: VDR-HD - AT5IONT-I - 4GB Ram - 512MB ION - TT 3600 DVB-S2 - TT6400-FF - Sundtek DVB-S2 Sundtek DVB-C - Tevii S480 (dank an L4M für kostenlose Bereitstellung) - yaVDR 0.5 (development) - SKY - HD+ - Atric - X10 FB - Zotac ID41 PLUS - SilverStone LC19B-R - Yamaha RX-V671 - Samsung 8Series 55"

    Läuft hier. Bin mal gespannt, ob ich damit wieder Tonaussetzer nach 30 min. habe (deshalb habe ich vor einem halben Jahr auf xineliboutput gewechselt)


    Schönen Dank rnissl für seine Arbeit an xine-lib und für das neue xine-plugin.


    Und: erster mit TrueColor OSD :D (auch wenn man davon noch nichts sieht)



    Grüße, Peter

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

    Hi,


    Zitat

    Original von Morone
    So nebenbei seh ich auch nichts vom osddemo


    Vermutlich auf andere OSD-Anzeigeart in vdr-xine's Setup-Menü wechseln. Auch wenn "Überlagern (X11)" das suggeriert ist es derzeit nicht ARGB fähig. Jede andere Einstellung passt.


    Zitat

    Original von Morone
    Und: erster mit Tonaussetzern ;)


    Leider hat es der neue Buffer-Algorithmus nicht mehr in 0.9.4 geschafft, da VDR-1.7.17 etwas zu früh kam. Bis jetzt waren die Tonaussetzer immer darin begründet, dass zu kleine Input-Buffer auf Seiten von .xine/config und/oder vdr-xine eingestellt waren.


    Bitte mal beiliegenden Patch einbauen. Die Ausgabe sieht dann z. B. so aus:


    Die Angaben bedeuten:
    vi: video input (zu dekodierende Daten)
    ai: audio input (zu dekodierende Daten)
    vo: video output (anzuzeigende Bilder)
    ao: audio output (auszugebende Audioframes)


    Und in Klammen:
    1.) konfigurierte bzw. mögliche Bufferanzahl
    2.) Anzahl gefüllte Buffer (warten auf Dekodierung bzw. Anzeige)
    3.) Freie Buffer (könnten noch mit Daten gefüllt werden, um noch größere Latenzen zu überbrücken)


    Zu Audioaussetzern kommt es, wenn von ao der mittlere Wert "über längere Zeit" 0 ist. Bildruckler gibt es, wenn gleiches bei vo auftritt.


    Die vi/ai Puffer müssen in .xine/config so erhöht werden, dass es noch freie Buffer gibt (rechter Wert > 0). Dann müssen in vdr-xine die Video- und Audio-Puffer so eingestellt werden, dass bei vo und ao der mittlere Wert > 0 bleibt.


    Aus einem außergewöhnlichen Fall kann ich sagen, dass Audio-Puffer in vdr-xine auf 16 bis 24 erhöht werden mussten, um obige Anforderung zu erfüllen. Danach kam es zu keinen Tonaussetzern mehr.


    Der neue Algorithmus soll sich zukünftig über zu kleine Input-Buffer beschweren und solange Puffern, bis die mittleren Angaben bei vo/ao stabil über 0 bleiben.


    Bye.

    Nabend,


    vielen Dank für die neue Version :) Das kommt ja wie gerufen das grade am OSD Handling für die VA-API gearbeitet wird.


    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

    Wie schaltet man das erweiterte Logging ein, wenn man die xine-lib-1.2 mit o.g. diff gepatcht hat?


    Gruß
    iNOB

    Einmal editiert, zuletzt von iNOB ()

    Also bei mir kam der Output ohne zutun.
    Allerdings musste ich mir die Sourcen neu ziehen , weil mein Versionsstand
    so alt war , dass ich net mal den Patch einspielen konnte, was
    dann auch gleich das TrueColor Problem beseitigte.


    Am Anfang sah auch alles gut aus , bis auf Umschaltverhalten , da wird tlw. bis zu 4x neu gepuffert oder synchronisiert.
    Output ist dann so (hier jetzt nur 2 x):

    Code
    DiscontinuityDetected: triggering soft start
[vVMaA]buffered 20.6 frames (v:47.0, a:20.6)
buffered 18.8 frames (v:47.5, a:18.8) <<<<<


    Ok mal schaen was der neue Algo bringt.


    Ich dachte dann auch , dass sich die Audioaussetzer erledigt haetten
    (habe die Einstellungen vorsichtshalber auch mal hochgeschraubt):

    Code
    vi: (5000, 1172, 3827), ai: (2300,    0, 2300), vo: (30, 12,  1), ao: (32, 27,  5)
vi: (5000, 1156, 3843), ai: (2300,    0, 2300), vo: (30, 12,  1), ao: (32, 26,  6)
vi: (5000, 1230, 3769), ai: (2300,    0, 2300), vo: (30, 12,  1), ao: (32, 30,  2)
vi: (5000, 1214, 3785), ai: (2300,    0, 2300), vo: (30, 12,  1), ao: (32, 29,  3)
vi: (5000, 1198, 3801), ai: (2300,    0, 2300), vo: (30, 12,  1), ao: (32, 29,  3)
vi: (5000, 1182, 3817), ai: (2300,    0, 2300), vo: (30, 12,  1), ao: (32, 28,  4)
vi: (5000, 1166, 3833), ai: (2300,    0, 2300), vo: (30, 12,  1), ao: (32, 27,  5)
vi: (5000, 1238, 3761), ai: (2300,    0, 2300), vo: (30, 12,  1), ao: (32, 29,  3)



    ABER ich bin dann kurz vor dem Bildschirm eingepennt ;) und so nach ca.
    2 Stunden war das Dilemma da.
    Kein Audio..

    Code
    vi: (5000,  257, 4742), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)
vi: (5000,  308, 4691), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)
vi: (5000,  280, 4719), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)
vi: (5000,  254, 4745), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)
vi: (5000,  252, 4747), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)
vi: (5000,  250, 4749), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)

    Hi,


    Zitat

    Original von Morone
    ABER ich bin dann kurz vor dem Bildschirm eingepennt ;) und so nach ca.
    2 Stunden war das Dilemma da.
    Kein Audio..

    Code
    vi: (5000,  257, 4742), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)
vi: (5000,  308, 4691), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)
vi: (5000,  280, 4719), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)
vi: (5000,  254, 4745), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)
vi: (5000,  252, 4747), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)
vi: (5000,  250, 4749), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)


    Traxanos hat im Vorfeld vergleichbares berichtet. Er konnte es aber nicht nachvollziehen, und ich selbst habe es noch nie beobachtet. Kannst du ermitteln, was in den 2 Stunden passiert ist?


    Bye.

    mir ist nochwas aufgefallen. wenn das bild noch nicht stabil läuft, sorgt das osd dafür dass das bild sich nicht stabilisiert. sobald das osd weg ist wird es stabil. danach kann ich auch wieder ins osd. das problem ist aber hauptsächlich das zappen, da das status fenster ja auch ein osd ist. sprich zappen geht bei mir garnicht mehr, und ich muss nach jedem switchen das status fenster wegklicken um bild zu bekommen.

    mfg traxanos
    ____________________
    Ist das neu?, Nein Linux!


    VDR1: Zotac NM10-ITX Wifi - 2GB Ram - S2-6400 HD mit IR - yavdr 0.4 (development) - LianLi PC-Q11


    Tags: VDR-HD - AT5IONT-I - 4GB Ram - 512MB ION - TT 3600 DVB-S2 - TT6400-FF - Sundtek DVB-S2 Sundtek DVB-C - Tevii S480 (dank an L4M für kostenlose Bereitstellung) - yaVDR 0.5 (development) - SKY - HD+ - Atric - X10 FB - Zotac ID41 PLUS - SilverStone LC19B-R - Yamaha RX-V671 - Samsung 8Series 55"

    bei mir schaut das wie folgt aus. Warum und Wann die Tonaussetzer kommen ist zufall aus meiner Sicht. Es hat weder etwas mit Empfang oder dem System zu tun.


    Anhand der Logs ist es absehbar, wann es passiert:


    dann baut es sich wieder auf:

    Code
    video_out: (vo_frame_draw:450) vi: (1800,  614, 1185), ai: ( 700,    0,  700), vo: (22,  4,  1), ao: (32,  1, 31)
video_out: (vo_frame_draw:450) vi: (1800,  624, 1175), ai: ( 700,    0,  700), vo: (22,  4,  1), ao: (32,  2, 30)
video_out: (vo_frame_draw:450) vi: (1800,  646, 1153), ai: ( 700,    0,  700), vo: (22,  4,  1), ao: (32,  2, 30)
video_out: (vo_frame_draw:450) vi: (1800,  668, 1131), ai: ( 700,    0,  700), vo: (22,  4,  1), ao: (32,  3, 29)
video_out: (vo_frame_draw:450) vi: (1800,  607, 1192), ai: ( 700,    0,  700), vo: (22,  4,  1), ao: (32,  4, 28)
video_out: (vo_frame_draw:450) vi: (1800,  625, 1174), ai: ( 700,    0,  700), vo: (22,  4,  1), ao: (32,  5, 27)
video_out: (vo_frame_draw:450) vi: (1800,  681, 1118), ai: ( 700,    0,  700), vo: (22,  4,  1), ao: (32,  7, 25)
video_out: (vo_frame_draw:450) vi: (1800,  710, 1089), ai: ( 700,    0,  700), vo: (22,  4,  1), ao: (32,  8, 24)
video_out: (vo_frame_draw:450) vi: (1800,  717, 1082), ai: ( 700,    0,  700), vo: (22,  4,  1), ao: (32,  8, 24)
video_out: (vo_frame_draw:450) vi: (1800,  715, 1084), ai: ( 700,    0,  700), vo: (22,  4,  1), ao: (32,  8, 24)


    Meine Einstellungen:

    Code
    engine.buffers.audio_num_buffers:700
engine.buffers.video_num_buffers:1800
engine.buffers.video_num_frames:22
xine.modeLiveTV.prebufferFramesAudio = 4
xine.modeLiveTV.prebufferFramesVideoHD = 8
xine.modeLiveTV.prebufferFramesVideoSD = 4
xine.modeLiveTV.prebufferHysteresis = 8


    Tonausgabe über HDMI
    Alsa Version 1.0.24
    Aktuelles Xine-Lib aus dem Git mit Branch vdpau-extensions-patch-xine-lib-patch

    Mein VDR: Software: vdr 1.7.30 vdr-xine, xine-lib-1.2, Ubuntu 10.04, 2.6.35 Hardware: GT 220, TT-PCI S2-1600 + Mystique SaTiX-S2 V2

    Einmal editiert, zuletzt von sgp01 ()

    Hi,



    Tja, leider darf sich im Verlauf des Streams der Versatz von Audio und Video im Input (also auf Senderseite) ändern. Erwischt man in der Pufferphase z. B. das Audio vorausläuft und fällt es später zurück, dann kommt es mitunter zum buffer underrun bei der Ausgabe und der Ton stockt.


    Vermutlich ist xine.modeLiveTV.prebufferFramesVideoHD = 8 etwas zu optimistisch. Mit 16 könnte es ggf. klappen. Evtl. auch noch xine.modeLiveTV.monitoringDuration auf z. B. 30 oder höher setzen, um den A/V-Versatz über einen längeren Zeitraum zu beobachten, und hoffentlich die Extremstellen zu erwischen. Dies gilt für xine.modeLiveTV.monitoringMode = monitoringOnce. Andernfalls läuft die A/V-Versatz Beobachtung ständig mit und versacht eine etwas höhere CPU-Last.


    Bye.

    Danke für die Infos! Ich werde testen und berichten....


    Interessant ist, dass die Tonaussetzer idR beim Fussball auftreten. Das dürfte einerseits an ständigen Tonkulisse liegen (und man es sofort merkt wenn es Aussetzer gibt) und andererseits dass wahrscheinlich die ÖRs den Versatz auch nicht ordentlich hinbekommen.

    Mein VDR: Software: vdr 1.7.30 vdr-xine, xine-lib-1.2, Ubuntu 10.04, 2.6.35 Hardware: GT 220, TT-PCI S2-1600 + Mystique SaTiX-S2 V2

    Einmal editiert, zuletzt von sgp01 ()

    Hallo,


    die letzten zwei Wochen habe ich das Verhalten genauer beobachtet. Ich muss sagen, dass ich mit den höheren Bufferwerten schon wesentlich weniger Aussetzer habe. Trotzdem treten sporadische Aussetzer immer noch auf.


    Interessant ist, dass die Buffers über Zeit immer weniger werden. Also von

    Code
    video_out: (vo_frame_draw:450) vi: (2200, 1055, 1144), ai: ( 700,	0,  700), vo: (22,  4,  1), ao: (32, 20, 12)


    geht es im Verlauf des Zusehens runter auf

    Code
    video_out: (vo_frame_draw:450) vi: (2200,  806, 1393), ai: ( 700,	0,  700), vo: (22,  4,  1), ao: (32,  9, 23)


    Irgendwann tritt dann folgender Fehler auf:


    und dann ist es ganz vorbei....


    Ich habe Dir das komplette Log unter:
    http://benet.at/vdr-xine.log.gz
    gespeichert.


    Ich habe ORF2 HD geschaut und irgendwann auf ORF1 HD gewechselt.

    Mein VDR: Software: vdr 1.7.30 vdr-xine, xine-lib-1.2, Ubuntu 10.04, 2.6.35 Hardware: GT 220, TT-PCI S2-1600 + Mystique SaTiX-S2 V2

    Ja so sieht es bei mir auch in etwa auf.
    Der Puffer wird immer kleiner , bei Audio geht er irgendwann auf 0
    und dann Ton weg.
    Leider gibt es ueberhaupt keine Anzeichen warum.
    Wenn ich uimschalte ist Ton wieder da und Puffer voll.


    Gestern gab es nur was aber denke mal das war ne andere Baustelle

    Code
    Apr  7 03:44:21 master vdr: [5810] 1 cRepacker messages suppressed
Apr  7 03:44:21 master vdr: [5810] cAudioRepacker(0xC0): skipped 572 bytes while syncing on next audio frame
Apr  7 03:44:21 master vdr: [5811] ERROR: driver buffer overflow on device 1
Apr  7 03:44:21 master vdr: [5811] buffer usage: 60% (tid=5810)
Apr  7 03:44:21 master vdr: [5810] ERROR: skipped 258523 bytes to sync on TS packet on device 1
Apr  7 03:44:21 master vdr: [5810] TS continuity error (5)
Apr  7 03:44:21 master vdr: [5810] TS continuity error (11)


    Am OS oder Kernel liegt es jedenfalls schon mal nicht , Tritt bei Gentoo bis Ubuntu auf.

    Sieht für mich so aus/hört sich so an, als wenn er irgendwann am Ende des Buffers ankommt und dann konstant am Limit kratzt, also die Position im Buffer nicht gecheckt wird, bis er nur noch am Rand rumkratzt.


    Für X11 Overlay hat sich noch ein Bug eingeschlichen, dass das OSD in Abhängigkeit von der Videogrösse skaliert wird und nicht in Abhängigkeit der Bildschirmgrösse.


    Steffen

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

    vdr-wiki YaVDR |YaVDR Blog

    Bei der Wiedergabe einer h264 720p Aufnahme starte ich pausiert an einer Sprungmarke.


    1. Beim Start von Zeitlupe vorwärts mit Rechts zeigt der vdr log
    TrickSpeed: 8
    TrickSpeedMode: push H.264 SequenceEndCode
    TrickSpeedMode: push H.264 SequenceEndCode
    TrickSpeedMode: push H.264 SequenceEndCode
    TrickSpeedMode: push H.264 SequenceEndCode
    PPPPTrickSpeedMode: push H.264 SequenceEndCode
    PPPPPPPPTrickSpeedMode: push H.264 SequenceEndCode
    ...
    und im Rythmus der SequenceEndCode Meldungen wird das Bild pixelig und der Bildfluss stockend.


    2. Ausgehend von der Sprungmarke drücke ich Play, Pause und starte Zeitlupe vorwärts mit Rechts. Der vdr log:
    TrickSpeed: 8
    PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
    ...
    Der Start ist verzögert, aber es läuft ohne Bildstörungen und fliesst gleichmäßig.


    Könnt ihr auch diese Fehler (verzögerter Start bzw. rythmische Bildstörungen und rythmisch stockender Bildfluss) beobachten?

    Ich habe mal versucht das xine Plugin 0.9.4 mit vdr-1.7.18 zu bauen, bekomme aber folgende Fehlermeldung:

    Code
    vdr01 xine # make clean all
g++ -g -O3 -Wall -Woverloaded-virtual -fPIC -march=core2 -O2 -mtune=generic -pipe -D__STDC_CONSTANT_MACROS -ggdb -O0 -fPIC -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_ALTERNATECHANNEL -DUSE_CHANNELBIND -DUSE_CHANNELPROVIDE -DUSE_CUTTERLIMIT -DUSE_CUTTIME -DUSE_DDEPGENTRY -DUSE_DVLVIDPREFER -DUSE_DYNAMITE -DUSE_GRAPHTFT -DUSE_HARDLINKCUTTER -DUSE_JUMPINGSECONDS -DUSE_LIEMIEXT -DUSE_LIRCSETTINGS -DUSE_LNBSHARE -DUSE_MAINMENUHOOKS -DUSE_MCLI -DUSE_MENUORG -DUSE_NOEPG -DUSE_PINPLUGIN -DUSE_PLUGINMISSING -DUSE_ROTOR -DUSE_TIMERINFO -DUSE_TTXTSUBS -DUSE_VALIDINPUT -DUSE_WAREAGLEICON -DUSE_YAEPG -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"xine"' -DFIFO_DIR=\"/tmp/vdr-xine\" -DVERIFY_BITMAP_DIRTY=0 -DSET_VIDEO_WINDOW -I/usr/local/src/DVB/include `pkg-config --cflags libxine`  -I/usr/local/src/VDR/include xine.c
g++ -g -O3 -Wall -Woverloaded-virtual -fPIC -march=core2 -O2 -mtune=generic -pipe -D__STDC_CONSTANT_MACROS -ggdb -O0 -fPIC -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_ALTERNATECHANNEL -DUSE_CHANNELBIND -DUSE_CHANNELPROVIDE -DUSE_CUTTERLIMIT -DUSE_CUTTIME -DUSE_DDEPGENTRY -DUSE_DVLVIDPREFER -DUSE_DYNAMITE -DUSE_GRAPHTFT -DUSE_HARDLINKCUTTER -DUSE_JUMPINGSECONDS -DUSE_LIEMIEXT -DUSE_LIRCSETTINGS -DUSE_LNBSHARE -DUSE_MAINMENUHOOKS -DUSE_MCLI -DUSE_MENUORG -DUSE_NOEPG -DUSE_PINPLUGIN -DUSE_PLUGINMISSING -DUSE_ROTOR -DUSE_TIMERINFO -DUSE_TTXTSUBS -DUSE_VALIDINPUT -DUSE_WAREAGLEICON -DUSE_YAEPG -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"xine"' -DFIFO_DIR=\"/tmp/vdr-xine\" -DVERIFY_BITMAP_DIRTY=0 -DSET_VIDEO_WINDOW -I/usr/local/src/DVB/include `pkg-config --cflags libxine`  -I/usr/local/src/VDR/include xineDevice.c
xineDevice.c: In constructor »PluginXine::cXineDevice::cXineDevice(cPlugin*, PluginXine::cXineSettings&, PluginXine::cXineRemote*)«:
xineDevice.c:4371:53: Fehler: Aufruf des überladenen »cDevice()« ist mehrdeutig
/usr/local/src/VDR/include/vdr/device.h:798:3: Anmerkung: Kandidaten sind: cDevice::cDevice(cDevice*)
/usr/local/src/VDR/include/vdr/device.h:207:3: Anmerkung:                  cDevice::cDevice()
make: *** [xineDevice.o] Fehler 1
vdr01 xine #


    Hat Jemand eine Idee, woran das liegen könnte?

    Hi


    Hast du den Ext Patch drinen?


    Dan könnte es evtl an dem liegen


    Diff
    --- a/device.h
+++ b/device.h
@@ -163,7 +163,6 @@ private:
static int nextCardIndex;
int cardIndex;
protected:
- cDevice(void);
virtual ~cDevice();
virtual bool Ready(void);


    mfg

    Hallo,


    gegen welche xinelib sollte man das vdr-xine 0.9.4 plugin Bauen? Ich habe es bisher mit:


    - xinelib-1.2-hg (aktuellste) von hier: http://hg.debian.org/hg/xine-lib/xine-lib-1.2


    - xinelib.git (aktuellste) von hier: http://projects.vdr-developer.…?p=xine-lib.git;a=summary


    probiert.


    Leider habe ich bei beiden die gleichen Probleme (Videotreiber: xv):


    - Bei verwendung von text2skin Skins (PearlHD, Anthra xy) ruckelt das TV Bild wenn ich im Menü Navigiere (bei Anthra beienträchtigt das Ruckeln sogar die Navigationsgeschwindigkeit). Gleiches Verhalten bei verwendung von xinelibout.


    - Bei PearlHD (bei diesem Skin tritt das Ruckeln "nur" bedingt bzw. schwach auf) Blitzt beim Ausblenden des OSDs kurz ein großes Quadrat auf. Gleiches Verhalten bei verwendung von xinelibout.


    - Bei zwei Aufnahmen auf untershiedlichen Transpondern hängt der VDR eine Zeit lang wenn ich den letzten Kanal der von einem der beiden Transponder (also den letzten empfangbaren Kanal in der Kanalliste der auf einem der beiden Transponder empfangbar ist) "überschreite". Nach einer kurzen Zeit werden dann alle Befehle die ich per IR gesendet habe plötzlich ausgeführt.Mit xinelibout funktioniert es.


    - Wenn ich bei einer Timeshift Aufnahme oder einer regulären Aufnahme die noch läuft beim Abspielen Spule fängt das Bild kurz (ca. 30 sek.) vor Ende der Aufnahme an zu Ruckeln (entspricht einer Slideshow) und der VDR reagiert nicht auf Eingaben. Irgendwann läuft das Bild wieder weiter und alle gesendeten IR Befehle werden ausgeführt. Falls ich an dieser Stelle versuche weiter zu Spulen passiert das gleiche. Ich kenne dieses Problem noch aus meiner VDPAU Zeit mit vdr-xine 0.9.3 - unter xinelibout funktioniert das ganze aber.


    So ich hoffe das ist einigermaßen verständlich. Besonders stört mich der letzte Fehler. Mit den anderen kann ich Leben, auch wenn es etwas unschön ist. Allerdings kann ich die OSD Probleme nur schwer nachvollziehen da genug CPU Leistung vorhanden ist um das OSD zu Rendern. Das gleiche Verhalten habe ich auch auf meinem CoreI5 Desktop mit der leistungsfähigeren Intel GMA HD Grafik.


    Gruß


    Atech


    Ergänzung: VDR: 1.7.18, Text2Skin 1.3 git

    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

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden