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 :

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

statt

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

statt

und

statt

(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

Nur mal zur Info :
Mit neuerem Kernel (Debian Lenny mit 2.6.30 von backports.org) tritt das Problem bei ansonsten unveränderter Konstellation nun nicht mehr auf.

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 ?

..und Port 2004 hatte ich vor Jahren mangels 2. vdr im Setup deaktiviert.
Jetzt gehts, übrigens sowohl mit den streamdev-Paketen von oppserver
als auch mit denen von e-tobi.

Vielen Dank für den Wink..

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.

mplayer-plugin spielt movs, mp4s und flvs zu schnell und ohne Ton

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