Posts by panik105

    Hallo,


    ich habe heute meinen unter squeeze/experimental von e-tobi laufenden vdr auf 1.7.20 upgedatet. Seitdem
    kann ich keine Aufnahmen mehr auf Kanälen durchführen, die vom pvrinput-Plugin erzeugt werden
    (alle anderen funktionieren (SD und HD)).


    Folgende Meldungen im Syslog :
    frame type not in first packet of payload - buffering
    ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes
    ERROR: encountered new payload while buffering - dropping some data!


    Endlos viele, wenn ich die Aufnahme nicht sehr schnell wieder abbreche, irgendwann segfault.


    Das generelle Problem wird auch hier im Portal im Announce-Thread diskutiert (dort bzgl. HD-Kanälen).
    Es gibt aber bereits einen Fix von kls, der wenn ich Tobis changelog lese auch bereits übernommen wurde, oder ?


    Added 99_fix-recording-problem-vdr-1.7.20.dpatch


    Deshalb weiss ich nicht so recht, wo ich posten soll, dort, im Plugin-Forum oder hier :-)


    Tschuess..
    Michael

    Hallo, bei mir läuft es so :


    /etc/vdr/vdrconvert/vdrconvert.conf :

    Code
    1. #export LANG=de_DE@euro
    2. export LANG=de_DE.UTF-8
    3. #RECODE="recode latin1..UTF-8"
    4. RECODE="cat"


    /etc/vdr/vdrconvert/vdrconvert.dvd.conf :

    Code
    1. DVDTEXTMENU="Titelmenü"


    statt

    Code
    1. DVDTEXTMENU="TitelmenX"


    /usr/lib/vdrconvert/bin/vdr2dvd.sh :

    Code
    1. [ -z "$DVDTEXTMENU" -o "$DVDTEXTMENU" = "" ] && DVDTEXTMENU="Titelmenü"


    statt

    Code
    1. [ -z "$DVDTEXTMENU" -o "$DVDTEXTMENU" = "" ] && DVDTEXTMENU="TitelmenX"


    und

    Code
    1. [ -z "$DVDMENU_MENU_MAIN" -o "$DVDMENU_MENU_MAIN" = "" ] && DVDMENU_MENU_MAIN="Titelmenü"


    statt

    Code
    1. [ -z "$DVDMENU_MENU_MAIN" -o "$DVDMENU_MENU_MAIN" = "" ] && DVDMENU_MENU_MAIN="TitelmenX"


    (also überall den Text "Titelmenü"t in utf-8 statt iso-8859-1 schreiben)


    Bei letzterer Datei ist das unschön, da es sich leider nicht um eine Konfigdatei handelt, sondern um das Skript selbst.


    Tschuess..
    Michael

    Hallo,


    auch von mir mal vielen Dank für die immer neuen vdrdevel-Versionen :-)


    Als Info : graphlcd läuft hier mit vdrdevel ohne Probleme, wenn man in den Original-e-tobi-Sourcen alle Vorkommen von FRAMESPERSEC durch DEFAULTFRAMESPERSECOND ersetzt.


    (Der Tip Ist nicht von mir, sondern aus irgendeinem Thread zum Thema..)


    Tschuess..
    Michael

    Hallo,


    ich nutze das pvrinput-Plugin hauptsächlich um VHS-Videos zu digitalisieren.
    Als ich kürzlich auf NTSC-Videos stiess (der Videorekorder kann sie abspielen,
    mein Fernseher zeigt das auch korrekt an), gelang dies leider nicht.
    Stelle ich PAL ein, ist das Timing kaputt (diagonale Verzerrung), bei NTSC
    stimmt das Timing, dafür habe ich keine Farben.
    Recherche ergab, dass die meisten PAL-Rekorder mit NTSC-Abspielfunktionalität
    de facto PAL60 liefern (also NTSC-Timing gemischt mit PAL Farben).
    Erfreulicherweise ist sowohl meine Hardware (PVR150) als auch ivtv generell
    in der Lage, PAL60 zu verarbeiten.
    Ich habe die unten folgenden Änderungen an pvrinput vorgenommen (device.c)
    und damit erfolgreich die NTSC-Videos digitalisiert.
    Diese Änderungen wollte ich euch natürlich nicht vorenthalten - evtl. können
    sie ja sogar in eine zukünftige Release einfliessen.


    Tschuess..
    Michael


    Quote

    Original von Tobi
    Die ganzen ffmpeg-abhängigen Pakete müssten neu compiliert werden, im Moment musst du auf diese Pakete verzichten, oder bis nächstes Jahr warten... dauert ja nicht mehr lange :-)


    Da es ja inzwischen schon einige Zeit "nächstes Jahr" ist, wollte ich mal vorsichtig anfragen, ob evtl. die ffmpeg-basierten Pakete in angepassten Versionen kommen.


    Ich bin allerdings momentan durch die vielen Repositories etwas verwirrt :
    Ich habe hier e-tobi/experimental für vdr und vdrdevel mit entsprechenden vdpau-xine sowie xbmc von
    debian.oppserver.net. Mit vdr-ng habe ich momentan noch nichts am Hut, da ich noch nicht komplett auf 1.7
    umsteigen will und mir zuviele Plugins fehlen (ich müsste wohl mal ausmisten) :-))


    Wie sind die verschiedenen Repositories zu sehen, werden alle weitergepflegt ? Ich hatte zwischenzeitlich den
    Eindruck, dass man auf vdr-ng wechseln sollte, in der letzten ct wird aber explizit die von mir derzeit
    verwendete Kombination beschrieben.


    Tschuess..
    Michael

    Es hat sich "nur" einiges in der config geändert (s. Changelog) - Anpassungen bzgl. UTF-8 sind keine drin.
    Ich hatte die wg. UTF-8 geänderten Dateien vorher beiseite gelegt und habe sie nach dem Update wieder manuell drübergespielt.


    An einem neuen vdr-xxv wäre ich wg. UTF-8 auch sehr interessiert ! Seit einigen Monaten gibt es Version 1.4 (stable), die u.a. UTF-8-fähig ist.
    Lohnt es sich, von Hand upzudaten (nicht ganz so einfach u.a. wg. Mysql-DB) oder ist ein Update geplant ?


    Tschuess..
    Michael

    Ich habe inzwischen eine vdpau-fähige Grafikkarte (G210 passiv) mittels HDMI an LCD-TV angeschlossen :
    Die Fehlermeldungen sind weg. Die Abstürze ebenfalls. Danke nochmals.
    FF ist übrigens noch drin und mittels AVBoard per Scart (RGB) ebenfalls am LCD-TV angeschlossen.
    Negative Auswirkungen habe ich dadurch noch keine festgestellt.

    wbreu : Ok, dann weitere Tests erst mit entsprechender Hardware (was ja scheinbar ein Kapitel für sich ist..) - die weihnachtliche vdr-Bastelsaison neigt sich ja nun eh dem Ende entgegen :-))


    Warum sollte man die FF ausbauen, sind da irgendwelche Inkompatibilitäten bekannt ?
    (Ich habe das immer gerne als stabilen Fallback in der Hinterhand - manchmal will man ja auch nur einfach fernsehen.. und ein Extra-Bastel-System habe ich mir bislang gespart)

    Ok, danke. Weitere Tests dann erst wieder lokal, also wenn ich mein LCD-TV habe; wobei die Ergebnisse bei mir lokal und remote wie gesagt identisch waren - und Gigabit-Ethernet ist es auch.


    Und mplayer nicht über xineliboutput, sondern als Client für streamdev-server (http-Streaming auf Port 3000), um neben xineliboutput und xbmc als Client für streamdev-server (vdr-streaming auf Port 2004) eine 3. Variante testen zu können..

    So, ich habe inzwischen unter Wegfall der genannten Pakete upgedatet und versuche
    jetzt DasErsteHD und ZDFHD mittels DVB-C (UnityMedia) zu testen.


    Vorweg : ich habe bislang keine vdpau-fähige Hardware (aber Nvidia inkl. binary-Treiber)
    und ein System mit 1xFF, 1xBudget, AV-Board und normalem Fernseher (SVideo).
    Bevor ich in neue GraKa und LCD-TV investiere wollte ich software- und empfangsseitig
    alles klar machen. Ich habe jeweils xmbc, http-streaming mittels mplayer und xineliboutput
    getestet.


    Ergebnis :
    - xineliboutput läuft maximal 10 Sekunden - dann Absturz, Meldungen z.B.
    [h264 @ 0x2b6ed40]non-existing SPS 14 referenced in buffering period
    [h264 @ 0x2b6ed40]B picture before any references, skipping
    [h264 @ 0x2b6ed40]decode_slice_header error
    [h264 @ 0x2b6ed40]no frame!
    [h264 @ 0x2b6ed40]number of reference frames exceeds max (probably corrupt input), discarding one
    Last message repeated 4 times
    [h264 @ 0x2b6ed40]Cannot parallelize deblocking type 1, decoding such frames in sequential order
    [h264 @ 0x2b6ed40]number of reference frames exceeds max (probably corrupt input), discarding one
    Last message repeated 1 times
    [h264 @ 0x2b6ed40]mmco: unref short failure
    [h264 @ 0x2b6ed40]number of reference frames exceeds max (probably corrupt input), discarding one
    Speicherzugriffsfehler


    - mplayer liefert
    Cache size set to 320 KBytes
    Cache fill: 0.00% (0 bytes) nop_streaming_read error : Resource temporarily unavailable
    Cache fill: 0.00% (0 bytes)
    Exiting... (End of file)


    - xbmc läuft (z.B. 15 Minuten am Stück ohne Bild-/Ton-Asynchronität - allerdings nicht ganz flüssig,
    was mir aber ohne vdpau plausibel erscheint (Core2Duo-6300-CPU 90%+80%-Last))


    Anmerkungen :
    - Alle genannten 3 Wege laufen mit vdr und vdrdevel bei SDTV von beiden Clients aus einwandfrei
    - Zum Empfang wurde immer die KNC One verwendet, da die FF-Karte hdtv nur sehr schlecht empfängt


    Fragen :
    - Sind die o.g. Abstürze/Probleme bekannt ?
    - Lohnt es sich überhaupt, dies ohne entsprechende Graka zu testen ?
    - Habe ich evtl. ein Empfangsproblem (warum geht es dann aber mit xbmc) ?


    Tschuess..
    Michael

    Hallo,


    ich wollte mich auch mal an diese Sache wagen, bekomme es aber nicht hin :


    2 Systeme (einmal i386 mit dem vdr, einmal amd64 als Client), vdr und vdrdevel
    laufen (mit FF und SD-Kanäle auch remote mit xineliboutput). DVB-C (Unitymedia) mit
    ArdHD und ZdfHD funktionieren mit vdrdevel ca. 10s, dann Absturz xineliboutput,
    mit vdr kommt gar nix. Ich denke das ist Stand der Dinge - bei meiner Suche
    bin ich auf diesen Thread gestossen und habe jetzt folgende sources.list :


    deb http://e-tobi.net/vdr-experimental lenny base backports addons vdr-multipatch
    deb-src http://e-tobi.net/vdr-experimental lenny base backports addons vdr-multipatch
    deb http://e-tobi.net/vdrdevel-experimental lenny base backports addons vdr-multipatch
    deb-src http://e-tobi.net/vdrdevel-experimental lenny base backports addons vdr-multipatch


    deb http://ftp.de.debian.org/debian/ lenny main non-free contrib
    deb-src http://ftp.de.debian.org/debian/ lenny main non-free contrib
    deb http://security.debian.org/ lenny/updates main contrib non-free
    deb-src http://security.debian.org/ lenny/updates main contrib non-free
    deb http://www.debian-multimedia.org lenny main
    deb-src http://www.debian-multimedia.org lenny main
    deb http://www.backports.org/debian lenny-backports main contrib non-free
    deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free


    deb http://e-tobi.net/vdpau-xine1.1 lenny base backports addons vdr-multipatch
    deb-src http://e-tobi.net/vdpau-xine1.1 lenny base backports addons vdr-multipatch
    deb http://e-tobi.net/vdpau-xine1.1-vdrdevel lenny base backports addons vdr-multipatch
    deb-src http://e-tobi.net/vdpau-xine1.1-vdrdevel lenny base backports addons vdr-multipatch


    Ich habe es geschafft, den nvidia-Treiber zu aktualisieren, beim Rest kommt auf dem vdr :


    Entferne die folgenden Pakete:
    vdr-addon-noad
    vdr-plugin-image
    vdr-plugin-osdpip
    vdr2jpeg
    vdrdevel-plugin-image


    Deaktualisieren der folgenden Pakete:
    libavcodec51 [3:20080706-0.3lenny1 (stable, now) -> 0.svn20080206-18 (stable)]


    Auf dem Client sollen andere Pakete mit Abhängigkeiten zu Marillat (z.B. dvdstyler,
    kdenlive, qdvdauthor, ..) deinstalliert werden.


    Das liegt m.E. daran, dass libavcodec51 von libdirac0 abhängt, das mit libdirac-encoder0
    conflicted, das wiederum von libavcodec52 benötigt wird.


    Gibt es dafür irgendeine Lösung ?

    Hallo,


    ich versuche xbmc mit meinem vdr (debian lenny, i386, e-tobi experimental) zu verheiraten.
    Ich installiere xbmc auf einem 2. PC (debian lenny, amd64) mit nvidia-binary-Treiber aus
    sid (190.42). 3D-Grafik läuft, xbmc läuft, aber das pvr-addon macht Probleme.
    Ich habe IP-Adresse des vdr und Port 3000 eingestellt, aber er läuft auf einen Timeout.
    Im Log des vdr sehe ich, dass xbmc mit dem streamdev-plugin connected. Im Log
    von xbmc steht aber "ERROR: AddOnLog: PVRDLL/VDRClient: PCRClient-vdr: Detected unsupported
    Streamdev-Version"


    Ich habe dann den nvidia-binary-Treiber und xbmc mal auf dem vdr selbst installiert ->
    identisches Verhalten.
    Dann ist mir aufgefallen, dass in den oppserver-Repos streamdev-plugins liegen, ich habe
    vom aktuellen e-tobi-Stand aus gedowngraded -> wieder kein Unterschied.


    Fragen :
    Warum eigene Pakete für streamdev auf oppserver, wo doch der aktuelle Stand bei e-tobi
    bereits 0.5.0~pre20090706 ist, was lt. diverser Wiki-Einträge Minimum für xbmc ist.
    (s. auch changelog : - added XBMC support by extending VTP capabilities (thanks to Alwin Esch)) ?


    Warum melden sich die streamdev-Pakete von oppserver im vdr-Log als
    initializing plugin: streamdev-server (0.5.0-pre): VDR Streaming Server, obwohl die
    Pakete 0.3.4+cvs20090830.1810-1+opp~3 heissen ?


    Warum ist der Default-Port auf xbmc-Seite 2004, wo er auf vdr-Seite doch 3000 ist ?


    Habe ich evtl. doch die falschen Pakete installiert oder den falschen Port eingestellt ?


    Tschuess..
    Michael


    P.S.: Zugriff auf streamdev mittels mplayer http://... vom Desktop-PC aus (auf dem auch xbmc
    laufen soll) funktioniert schon immer und auch jetzt noch.

    Hallo, habe gestern auch auf 2.6.30-bpo.2 upgedatet (allerdings i386), danach bootete der vdr erst wieder, nachdem ich diverse comedi-Module mittels blacklist davon abgehalten habe, geladen zu werden.
    Diese kommen aus dem Staging-Bereich ?!
    Vorher hing er beim Laden der Module im Rahmen der initrd, bevor init startete - es kamen ein paar Meldungen wie staging, you have been warned, etc.. :-) danach ein Stacktrace, das wars.

    Dieses osdpip läuft jetzt ganz prima.
    Vielen Dank dafür und überhaupt für die ganze Arbeit.


    Kleine Anmerkung : kann es sein, dass das neue vdr2jpeg wieder einige Abhängigkeiten zu alten ffmpeg-Sachen enthält (z.B. libavcodeccvs51, libavformatcvs51, usw.) ?


    Tschuess..
    Michael

    Hallo,


    bei mir klappt osdpip mit lenny inzwischen wieder.
    Stand letzte Woche, evtl. Änderungen an den Repositories habe ich nicht betrachtet.


    Dreierlei war zu ändern :


    1.)
    Ich habe mir von
    http://home.arcor.de/andreas.r…pip/vdr-osdpip-0.0.10.tgz
    die neueste Version des Plugins geladen (m.W. handelt es sich im
    e-tobi-Repository noch um die 0.0.9) und deren Quelltext so behandelt
    wie im e-tobi-Paket.


    Dabei traten noch die folgenden Probleme auf :
    2.)
    02_debian_ffmpeg.dpatch führt eine Änderung ein, die den Aufruf von ffmpeg-config
    nach sich zieht, dieses Programm gibt es auf meinem System nicht (ja, ich habe
    apt-get build-dep ausgeführt). Also habe ich diesen Patch aus 00list rausgenommen.
    Der Fehler ist schwer zu finden, da nur eine kurze Meldung beim Bauen kommt aber
    ein binary gebaut wird, das mittels ldd keinerlei Abhängigkeit zu irgendwas
    ffmpeg-ähnlichen hat.


    3.)
    lt. decoder.h liegen die ffmpeg-Header nach neuem Schema in <libavcodec/avcodec.h> und
    nach altem Schema in <ffmpeg/avcodec.h>, beim Paket von debian-multimedia.org
    liegen sie aber in <ffmpeg/libavcodec/avcodec.h>. (avcodec hier als Beispiel für alle)
    Dies ist m.E. ein Fehler in den Paketen, da die Dateien sich nichtmal dann finden, wenn sie
    sich untereinander referenzieren.
    Dies habe ich (übergangsweise) durch entsprechende Links gelöst.


    Tschuess..
    Michael

    Hallo,


    ich habe schon seit Monaten lenny am Laufen. zunächst noch mit dem sid-Repository von e-tobi.net, dann mit dem lenny-Repository. Alles klappt prima bis auf das von dir beschriebene Problem mit osdpip (s. auch http://vdr-portal.de/board/thr…?postid=742079#post742079)


    Ich habe zwischenzeitlich versucht, sowohl einfach nochmal selbst zu compilieren, als auch das plugin vorher anzupassen (irgendwo gab es einen Thread mit Änderungen bzgl. neuen Versionen von ffmpeg - den finde ich aber gerade nicht mehr). Leider hatte ich damit auch keinen Erfolg, die Fehlermeldung war aber eine andere.


    Irgendwann habe ich aufgegeben, m.E. ist des mit dem momentanen lenny-Stand auf debian-multimedia.org nicht möglich, osdpip zu bauen.


    Wenn einer eine Lösung hat, wäre ich froh !


    Tschuess..
    Michael

    Ja, so klappt es ganz hervorragend. Danke !


    Da im diff ja bereits Änderungen an den example-Dateien waren,
    hätte ich noch was für channels.conf_newsyntax.example :


    k08:196250:PVRINPUT|TV:P:0:301:300:305:0:3140:0:0:0
    -k09:196250:PVRINPUT|TV:P:0:301:300:305:0:3252:0:0:0
    +k09:203250:PVRINPUT|TV:P:0:301:300:305:0:3252:0:0:0
    k10:210250:PVRINPUT|TV:P:0:301:300:305:0:3364:0:0:0


    und nochwas :
    +static const char *VERSION = "2008-12-24";
    Das gibt mir ja schon zu denken :-)


    Tschuess..
    Michael