Bin soweit mit dem softhddevice auch sehr zufrieden. Es hat zwar nicht den gleichen Funktionsumpfang, aber für den alltäglichen gebrauch doch ausreichend und eben schnell.
Kann der git sync von xine-lib dann von http://projects.vdr-developer.org/git/ ausgeschaltet werden (es ist ja dann eh das selbe, was auch im hg ist) ?
so habs mal umgebaut auf das vdr-interne jpeg Grab.
nun sollte es weniger Stress mit der Lib geben.
Das war eine gute Idee mit dem tools.h.
(Einrückung muss wohl noch dem aktuellen angepasst werden, aber sonst siehts gut aus)
Habs mal kurz angetestet. Leider nicht ganz so einfach. softhddev.c ist C und tools.h nutz C++ Code. In der Kombi nicht so einfach nutzbar.
Ich werden morgen mal probieren ob man das über den Umweg softhddevice.cpp nutzen kann. Übersichtlicher wird es dadruch aber glaub ich nicht 
also die "mem" Zeile im grab speichert ja das Bild im Speicher für den VDR. Entweder würde man das für die alten jpeg Versionen nochmal komplett selber implementieren.
oder man ersetzt im Makefile
CONFIG += $(shell ls /usr/lib/libjpeg* >/dev/null 2>&1 && echo "-DUSE_JPEGdurch
CONFIG += $(shell echo -e "\#include \n\#include \n\#include \n void main (void){jpeg_mem_dest(NULL,NULL,NULL);}"|gcc -x c - -ljpeg -o /dev/null >/dev/null 2>&1 && echo "-DUSE_JPEG" )dann kompiliert es auch nur mit Jpeg wenn eine passender Version vorhanden ist ( was ja meiner Meinung nach für einen sehr grossen Teil zutreffen würde ??)
ich werde heute abend mal einen kurzen gcc compile test für das makefile machen.
http://freecode.com/projects/libjpeg/releases/314766
jpeg_mem_dest ist erst ab libjpeg8a dabei.
Ansonsten müsste man das memory handling noch extra einbauen für libjpeg < 8a
Hi
ich find das Plugin auch super. Hab mal einen Patch für die fehlende JPEG Grab Funktion angehängt.
Ich musste bisher noch feststellen, dass über Nacht das Plugin manchmal wohl nicht richtig in den Suspend Mode geht.
1 mal ging richtig, 10 std später dann eine Menge
Jan 24 16:08:52 imap vdr: audio/alsa: broken driver 24Jan 24 16:08:52 imap vdr: video: display buffer empty, duping frame (189988/287720)Jan 24 16:08:52 imap vdr: video: display buffer empty, duping frame (189989/287720)Jan 24 16:08:52 imap vdr: video: display buffer empty, duping frame (189990/287720)Jan 24 16:08:52 imap vdr: video: display buffer empty, duping frame (189991/287720)Jan 24 16:08:52 imap vdr: video: display buffer empty, duping frame (189992/287720)Jan 24 16:08:52 imap vdr: video: display buffer empty, duping frame (189993/287720)svdrsend ... SUSP, schaltet sich die Ausgabe ab und das füllt nichts mehr ins Log. EIn Druck auf die Taste der FB läßt es dann ganz normal weiter spielen.
Hat so etwas ähnliches noch jemand ? Find die Umschaltzeiten super schnell und würde daher auch gern dauerhaft auf dieses Plugin umschwenken.
EDIT: update um ein kleines leak zu entfernen
Ja kann ich dir kurz sagen, am einfachsten ist es in den Quellen vom Kernel (die musst du drauf haben) die Datein /usr/src/linux-(version)/drivers/media/dvb/dvb-usb/pctv452e.c editieren und die 2 Zeilen dort zu suchen und die Werte mit dem - durch die mit dem + ersetzen.
Alternativ kannst du auch die patches runterladen und mit patch -p 1 < pctv452e.patch einbauen (-p kann auch -p 2 -p 3 oder -p0 sein, je nachdem wo du das genau machst)
ich hoffe das hilft fürs erste
Dann Kernel neu kompilieren , installieren und Module neu laden. Dann sollte es gehen
Nach jeden neuen Kernel habe ich wieder erneut getestet, ob es nun mit 2 TT 3600 funkioniert. WIe zu erwarten ging es nicht. Seit 3.2 ist der Treiber nun direkt im Kernel. Leider auch mit den selbe Problemen. Aber es gibt auf der Mailingliste von linux-media einen Patch. Vor allem der letzte Teil mit den USB Parametern ist hierbei wichtig.
@@ -1368,11 +1408,11 @@
/* parameter for the MPEG2-data transfer */
.stream = {
.type = USB_ISOC,
- .count = 7,
+ .count = 4,
.endpoint = 0x02,
.u = {
.isoc = {
- .framesperurb = 4,
+ .framesperurb = 64,
.framesize = 940,
.interval = 1
}
und ich kann sagen: 2 gleichzeitige Streams von den 2 TT 3600 laufen seit 30 min perfekt (vorher war schon nach 1 min wieder kaum was zu erkennen)
Wäre schön, wenn Ihr das auch testen könntet. Und vor allem wenn das die Probleme nun endgültig bei allen löst.
da nun ja recht viele Patches auf xine-devel angenommen werden, wäre es vielleicht einen Versuch wert, die ganzen VDPAU Patches und weitere aus dem git nochmal dort anzubringen ? Gestetet sind die aus dem git wohl nicht gerade wenig
Vielleicht klappts ja diesmal.
es wurden jetzt eine ganze Menge der patches aus der ML ins HG commited. Interessiert könnten im Git die Neuerungen schon testen. Ich hoffe ein paar Bugs sind es dann wieder weniger
auf xine-lib hat man sich wohl mal die Zeit genommen und so weit ich sehe, alle Patches aus der ML eingepflegt in hg. (liegen auch schon im git auf projects.vdr-developer.org)
den branch vdpau-extensions-patch-xine-lib-patch" gibt es nur damit nicht jeder die patches von der xine mailing liste runterladen muss und von hand "einbauen". Wer die Patches selber einbauen will kann dies nat. immer noch selbst in den durchflieger branches tun. Sollte die Patches ins xine-lib hg einfliessen , wird der Branch wieder entfernt und man hat wieder eine besser Übersicht bei den Branches
der Branch "vdpau-extensions-patch-xine-lib-patch" ist nur da, weil es noch nicht im xine-lib hg repo angekommen ist. Sollte dies der Fall sein, wird "vdpau-extensions-patch-xine-lib-patch" wieder entfernt und es wohl (wie sonst auch immer) mit in den df* branch übernommen.
ich hab die 3 fehlenden Patches nun in git mit einfliessen lassen.
so habe jetzt nochmal ein wenig getestet.
kKötzchen kommen bei mir _immer_ sobal die Meldung auftaucht. (mit dem "laufenden" 2.6.33 nur ganz selten, dann ist das Bild meist OK, oder hat mal ein ganz kleines Klötzchen unten)
mit plain 2.6.32 kriege ich gar kein Bild mehr hin (vdr startet, macht nur noch Fehler auf dem usb bus, zeigt aber kein Bild, über streamdev kommen noch Daten, aber nichts mehr was zu erkennen ist.) gleiches gilt für 2.6.38_rc3
hab nun noch den 2.6.37 getestet. Problem bleibt, Klötzer und Fehlermeldung. Den patch von Seite 1 habe ich auch probiert (USB fix für 2.6.38, aber ohne Veränderung).
NUn dachet ich schliesse ich wenigstens eine TT 3650 und eine Terratec Cinery USB DVB-S2 HD an ( die super läuft an meinem anderen Linux Rechner mit 2.6.37). Gleicher Treiberstand hier auf dem Asrock und es macht nur
[ 302.406880] dw2102: i2c transfer failed.
[ 302.406886] b0 00 00 00 00 00
[ 304.406835] dvb-usb: bulk message failed: -110 (6/0)
[ 304.406843] dw2102: i2c transfer failed.
[ 304.406849] b0 1d 00 00 00 00
[ 306.406792] dvb-usb: bulk message failed: -110 (6/0)
[ 306.406800] dw2102: i2c transfer failed.
[ 306.406806] b0 1d 1d 00 00 00
[ 308.406754] dvb-usb: bulk message failed: -110 (6/0)
[ 308.406762] dw2102: i2c transfer failed.Da die gleich Zusammenstellung auf einem anderen Rechner geht und mit 2.6.33 das Problem auch noch nicht auftrat, schliesse ich daraus, das irgendwas mit dem USB für den ION Chipsatz seit 2.6.34 "im Eimer" ist.
Kann das jemand bestätigen, ob es nut ION's trifft oder auch andere Chipsätze ?
Update:
ich habe nochmal gesucht as der unterschied zwischen dem 2.6.33 und 34 ist und wie das zu den Änderungen zum Vanilla 32 mit dem 32-r25 unter gentoo passt. dabei ist in beiden Fällen folgender Patch mit eingeflossen
diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index 1e391e6..805ec63 100644
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -510,6 +510,8 @@ static int disable_periodic (struct ehci_hcd *ehci)
ehci_writel(ehci, cmd, &ehci->regs->command);
/* posted write ... */
+ free_cached_lists(ehci);
+
ehci->next_uframe = -1;
return 0;
}
@@ -1121,8 +1123,8 @@ iso_stream_find (struct ehci_hcd *ehci, struct urb *urb)
urb->interval);
}
- /* if dev->ep [epnum] is a QH, info1.maxpacket is nonzero */
- } else if (unlikely (stream->hw_info1 != 0)) {
+ /* if dev->ep [epnum] is a QH, hw is set */
+ } else if (unlikely (stream->hw != NULL)) {
ehci_dbg (ehci, "dev %s ep%d%s, not iso??\n",
urb->dev->devpath, epnum,
usb_pipein(urb->pipe) ? "in" : "out");
@@ -1563,13 +1565,27 @@ itd_patch(
static inline void
itd_link (struct ehci_hcd *ehci, unsigned frame, struct ehci_itd *itd)
{
- /* always prepend ITD/SITD ... only QH tree is order-sensitive */
- itd->itd_next = ehci->pshadow [frame];
- itd->hw_next = ehci->periodic [frame];
- ehci->pshadow [frame].itd = itd;
+ union ehci_shadow *prev = &ehci->pshadow[frame];
+ __hc32 *hw_p = &ehci->periodic[frame];
+ union ehci_shadow here = *prev;
+ __hc32 type = 0;
+
+ /* skip any iso nodes which might belong to previous microframes */
+ while (here.ptr) {
+ type = Q_NEXT_TYPE(ehci, *hw_p);
+ if (type == cpu_to_hc32(ehci, Q_TYPE_QH))
+ break;
+ prev = periodic_next_shadow(ehci, prev, type);
+ hw_p = shadow_next_periodic(ehci, &here, type);
+ here = *prev;
+ }
+
+ itd->itd_next = here;
+ itd->hw_next = *hw_p;
+ prev->itd = itd;
itd->frame = frame;
wmb ();
- ehci->periodic[frame] = cpu_to_hc32(ehci, itd->itd_dma | Q_TYPE_ITD);
+ *hw_p = cpu_to_hc32(ehci, itd->itd_dma | Q_TYPE_ITD);
}
/* fit urb's itds into the selected schedule slot; activate as needed */
@@ -2123,13 +2139,27 @@ sitd_complete (
(stream->bEndpointAddress & USB_DIR_IN) ? "in" : "out");
}
iso_stream_put (ehci, stream);
- /* OK to recycle this SITD now that its completion callback ran. */
+
done:
sitd->urb = NULL;
- sitd->stream = NULL;
- list_move(&sitd->sitd_list, &stream->free_list);
- iso_stream_put(ehci, stream);
-
+ if (ehci->clock_frame != sitd->frame) {
+ /* OK to recycle this SITD now. */
+ sitd->stream = NULL;
+ list_move(&sitd->sitd_list, &stream->free_list);
+ iso_stream_put(ehci, stream);
+ } else {
+ /* HW might remember this SITD, so we can't recycle it yet.
+ * Move it to a safe place until a new frame starts.
+ */
+ list_move(&sitd->sitd_list, &ehci->cached_sitd_list);
+ if (stream->refcount == 2) {
+ /* If iso_stream_put() were called here, stream
+ * would be freed. Instead, just prevent reuse.
+ */
+ stream->ep->hcpriv = NULL;
+ stream->ep = NULL;
+ }
+ }
return retval;
}
@@ -2195,9 +2225,10 @@ done:
/*-------------------------------------------------------------------------*/
-static void free_cached_itd_list(struct ehci_hcd *ehci)
+static void free_cached_lists(struct ehci_hcd *ehci)
{
struct ehci_itd *itd, *n;
+ struct ehci_sitd *sitd, *sn;
list_for_each_entry_safe(itd, n, &ehci->cached_itd_list, itd_list) {
struct ehci_iso_stream *stream = itd->stream;
@@ -2205,6 +2236,13 @@ static void free_cached_itd_list(struct ehci_hcd *ehci)
list_move(&itd->itd_list, &stream->free_list);
iso_stream_put(ehci, stream);
}
+
+ list_for_each_entry_safe(sitd, sn, &ehci->cached_sitd_list, sitd_list) {
+ struct ehci_iso_stream *stream = sitd->stream;
+ sitd->stream = NULL;
+ list_move(&sitd->sitd_list, &stream->free_list);
+ iso_stream_put(ehci, stream);
+ }
}
/*-------------------------------------------------------------------------*/
@@ -2231,7 +2269,7 @@ scan_periodic (struct ehci_hcd *ehci)
clock_frame = -1;
}
if (ehci->clock_frame != clock_frame) {
- free_cached_itd_list(ehci);
+ free_cached_lists(ehci);
ehci->clock_frame = clock_frame;
}
clock %= mod;
@@ -2322,9 +2360,13 @@ restart:
* No need to check for activity unless the
* frame is current.
*/
- if (frame == clock_frame && live &&
- (q.sitd->hw_results &
- SITD_ACTIVE(ehci))) {
+ if (((frame == clock_frame) ||
+ (((frame + 1) % ehci->periodic_size)
+ == clock_frame))
+ && live
+ && (q.sitd->hw_results &
+ SITD_ACTIVE(ehci))) {
+
incomplete = true;
q_p = &q.sitd->sitd_next;
hw_p = &q.sitd->hw_next;
@@ -2394,7 +2436,7 @@ restart:
clock = now;
clock_frame = clock >> 3;
if (ehci->clock_frame != clock_frame) {
- free_cached_itd_list(ehci);
+ free_cached_lists(ehci);
ehci->clock_frame = clock_frame;
}
} else {beim nächsten Test werde ich diesen mal wieder rausnehmen, zumal ja hier in ISO Stream (also bei TT -36x0 Datenströmen, Mircroframes ausgelassen werden) Ich hoffe, das brint Änderungen.
ja die sind (auch auf anderen Rechnern) mit dem Artefakten aufgenommen
--
so habs mal getestet mit 2.6.32 vanilla, leider selbes Ergebnis wie mir dem 2.6.38-rc3.(startet den vdr dann scheinen keine Daten mehr durchzukommen.) Muss ich wohl noch s2-liplianin in der Version testen, ab wann wieder ein bild kommt. Von daher kann ich noch keine genaue Aussage treffen mit einem nachträglichen downgrade auf 2.6.32.
ja kann ich mal mit 2.6.32 vanllia testen.
ich 2.6.27 hatte ich immer die "frischen vanilla sources". Bis einschliesslich 2.6.33 ging das immer gut, danach war kein Kernel mehr zu finden der das Problem behebt. Unter gentoo gibt es leider keinen ohne Patches mehr. Ich lade den mal von Hand.
in dem Forum hatte ich auch schon mal gesucht, dort hatte jemand selbes beschrieben, das wurde dann aber (trotz Funktion unter Windows) auf einen defekten USB Kontroller geschoben (glaube ich mich zu erinnern). Ih suche mal den Thread.
Hier ein Link auf meinen alten Breitrag mit Link zu dem Forum (mit Beispielbildern). Vielleicht kann ich morgen schon etwas zu, 2.6.32 sagen. Wenn ich einen Testrechner hätte könnte ich mit git bisect mal schauen wo genau das her kommt, nur haben ich nur den einen VDR laufen, und der wird fast durchgehend gebraucht
bei mir geht es auch nur mit dem vanilla 2.6.33. ein nachträglich installierter 2.6.32-25 (mit diversen Patches die nachträglich mit eingeflossen sind) besteht ebenfalls das Problem.
bis es über die xine-lib hg Version direkt einfliesst, habe ich mal einen Branch angelegt, wo diese Patches mit denen von durchflieger zusammen mit den neuen vom R. Nissl enthalten sind.
http://projects.vdr-developer.org/git/?p=xine-li…-xine-lib-patch
Da jetzt Kernel 2.6.38-28-generic läuft warten wir also bis ein Kernelupdate zur Verfügung steht.
du hast schon 2.6.38 drauf ?
ist ja auch nur eine Idee, vielleicht liegt es auch nicht daran. Viel mehr fällt mir aber auch nicht ein dazu im Moment (ich suche da schon Monate nach dem Fehler)