Posts by e9hack

Muß man noch irgendwelche Compiler-Schalter zusätzlich setzen? softhddevice mit ffmpeg 1.2 und '--enable-vdpau' kackt bei HD immer ab:

Apr  3 16:09:02 vdr vdr: codec/video: ffmpeg/libav buggy: width or height zero
Apr  3 16:09:02 vdr vdr: codec/video: ffmpeg/libav buggy: width or height zero
Apr  3 16:09:02 vdr vdr: video/vdpau: out of surfaces
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create decoder: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video surface: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr vdr: video/vdpau: can't create video mixer: The size of a supplied object does not match the object it is being used with.
Apr  3 16:09:02 vdr logger: vdr died with error code 134

Gruß
e9hack

Quote from gda

Vor einem Jahr habe ich von meinem Provider eine 7390 bekommen, zu der Zeit war das kein Auslaufmodell.

An KabelBW-Kunden werden nur kastrierte 6330 geliefert und Congstar-Kunden bekommen Auslaufmodelle. Ca. 200€ (vor 3 Monaten ca. 270€) für eine aktuelle 7390 ist irgendwie teuer. Kannst Du Deine 7390 freezen, um z.B. DHCPv6 fahren zu können?

Mein aktueller Provider ist die Telekom, da alle anderen nur 1,5MBit schalten können. Da kann ich nur einen SpeedPort für 5 bzw. 6€/Monat mieten oder eine überteuerte Fritzbox kaufen.

Gruß
e9hack

Solange AVM nur Auslaufmodelle und kastrierter Boxen an Vertragskunden (Kabel oder Telefon) liefert bzw. total überteuerte Boxen auf dem freien Markt anbietet, wird jede Pseudoinovation nur ein Rohrkrepierer.

Gruß
e9hack

Quote from UFO

Da vom Kernel getrennte Treiber immer als Modul kompiliert werden müssen, war HOTPLUG schon immer Voraussetzung. Insofern verliert man nichts. Habe das __dev*-Gedöns aus ddbridge und ngene entfernt.

Wenn ddbridge HOTPLUG fähig sein soll, muß man das noch in ddb_device_create() und ddb_device_destroy() berücksichtigen. Aktuell wird der Treiber crashen, wenn man mehr als 32 ddbridge Karten verwendet oder wenn man die einzige Karte zum 32mal gezogen und wieder reingesteckt hat

vdr:/usr/src/media_build_experimental/v4l # vdr:/usr/src/media_build_experimental # cat ddbridge-device-create-d130224.diff
--- linux/drivers/media/pci/ddbridge/ddbridge-core.c.save       2013-02-24 07:55:15.000000000 +0100
+++ linux/drivers/media/pci/ddbridge/ddbridge-core.c    2013-02-24 08:09:00.591162852 +0100
@@ -2157,7 +2157,6 @@


 #define DDB_NAME "ddbridge"


-static u32 ddb_num;
 static int ddb_major;
 static DEFINE_MUTEX(ddb_mutex);


@@ -2512,12 +2511,19 @@


 static int ddb_device_create(struct ddb *dev)
 {
+       int i;
        int error = -1;


        mutex_lock(&ddb_mutex);
-       dev->nr = ddb_num++;
-       ddbs[dev->nr] = dev;
+       for (i = 0; i < sizeof(ddbs) / sizeof(ddbs[i]); i++)
+               if (!ddbs[i]) {
+                       dev->nr = i;
+                       ddbs[i] = dev;
+                       break;
+               }
        mutex_unlock(&ddb_mutex);
+       if (i >= sizeof(ddbs) / sizeof(ddbs[0]))
+               goto fail0;
        dev->ddb_dev = device_create(&ddb_class, &dev->pdev->dev,
                                     MKDEV(ddb_major, dev->nr),
                                     dev, "ddbridge%d", dev->nr);
@@ -2539,10 +2545,9 @@


 fail1:
        mutex_lock(&ddb_mutex);
-       ddb_num--;
        ddbs[dev->nr] = NULL;
        mutex_unlock(&ddb_mutex);
-
+fail0:
        return error;
 }


@@ -2552,6 +2557,9 @@
                return;
        ddb_device_files_delete(dev);
        device_destroy(&ddb_class, MKDEV(ddb_major, dev->nr));
+       mutex_lock(&ddb_mutex);
+       ddbs[dev->nr] = NULL;
+       mutex_unlock(&ddb_mutex);
 }

Für Kernel 3.8 sollte man DEFINE_PCI_DEVICE_TABLE aus compat.h entfernen, da sich die Definition geändert hat. Eigentlich ist es in compat.h komplett überflüssig, da es die Definition schon relativ lange gibt.

diff -r 9b79c0d0acf1 v4l/compat.h
--- a/v4l/compat.h      Sat Feb 02 09:01:28 2013 +0100
+++ b/v4l/compat.h      Sun Feb 24 08:49:22 2013 +0100
@@ -174,10 +174,12 @@
 #define KEY_IMAGES           0x1ba   /* AL Image Browser */
 #endif


+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 8, 0)
 #ifndef DEFINE_PCI_DEVICE_TABLE
 #define DEFINE_PCI_DEVICE_TABLE(_table) \
        const struct pci_device_id _table[] __devinitconst
 #endif
+#endif

Gruß
e9hack

Quote from 3PO

Dann bleiben ja nur noch 379 Einträge übrig.

Du mußt nur auf ein aktuelleres Treiber-Packet umsteigen. Da ist alles gerichtet.

Gruß
e9hack

Quote from S:oren

Ich halte des komplette Löschen der __devinit (and friends) für absolut ungefährlich (und heutzutage ohne jede Nebenwirkung).

Es scheint mir, dass hier die Bedeutung dieser Attribute nicht so recht klar ist. Deshalb mal der Versuch einer Erklärung:
Es war einmal eine Zeit, als Linux auf Rechnern lief, bei denen der Hauptspeicher in einzelnen Megabytes gezählt wurde. Da kamen findige Programmierer auf die Idee, Code, der nur einmal beim Start des Kernels zur Initialisierung der Hardware ausgeführt wird, in eine eigene init-Codesection auszulagern, die nach dem Hochfahren des Kernels aus dem Hauptspeicher gelöscht wird. Mit der Zeit wurden die Hauptspeicher größer und es wurden Geräte entwickelt, die man zur Laufzeit des Systems einfach so an- und abstecken konnte (z.B. USB). Dumm war nun, dass der Kernel den Code zur Initialisierung dieser Geräte bereits gelöscht hatte, diese Geräte waren also nicht verwendbar. Um nun diesen Init-Code wahlweise behalten zu können, führte man konfigurierbaren Hotplug-Support im Kernel ein. Code zur Initialisierung von solchen Geräten wurde statt __init mit __devinit (entsprechend für Daten) gekennzeichnet. Ist nun Hotplug nicht konfiguriert, wird _devinit wie __init behandelt, ist Hotplug konfiguriert, wird __devinit wie normaler Code ohne Attribut behandelt (entsprechend fuer Daten). Die Zeit vergeht und mittlerweile haben auch kleine embedded Computer Hauptspeicher von einem halben Gigabyte oder mehr und USB-Controller. Somit baut schon jahrelang niemand mehr Kernel ohne Hotplug-Support.

Bei linux-3.8 hat man nun etwas aufgeräumt, z.B. Support für den alten i386 entfernt, und auch das konfigurierbare Hotplugging nun per default immer eingeschaltet. __devinit hat nun keine Bedeutung mehr und wurde vollständig entfernt. Bei älteren Kerneln könnte man ein paar Byte Hauptspeicher mit __devinit sparen, aber nur dann, wenn Hotplugging deaktiviert ist. Verwendet irgendjemand hier einen Kernel ohne Hotplug-Support?

Deine Erklärung scheint ja plausibel zu sein. Nur aktuell sind zwei PCI-Karten betroffen. Es wird ja wohl keiner bei laufendem PC die ddbridge- oder ffhd-Karte permanent ziehen bzw. wieder reinstecken wollen. Die ddbridge-Karte benutzt sowohl __xxxx als auch __devxxxx Attribute. Die __devxxxx Attribute kann man entfallen lassen, die anderen werden nicht angetastet. Irgendwie paßt das nicht zusammen.

Gruß
e9hack

Quote from S:oren

Unfug!

Hast natürlich recht. Wenn, dann so:

vdr:/usr/src/media_build_experimental/v4l # hg diff compat.h
diff -r 9b79c0d0acf1 v4l/compat.h
--- a/v4l/compat.h      Sat Feb 02 09:01:28 2013 +0100
+++ b/v4l/compat.h      Sat Feb 23 16:51:53 2013 +0100
@@ -1095,4 +1092,32 @@
 #define VM_DONTDUMP VM_NODUMP
 #endif


+#ifndef __devinit
+#define __devinit      __init
+#endif
+
+#ifndef __devinitdata
+#define __devinitdata  __initdata
+#endif
+
+#ifndef __devinitconst
+#define __devinitconst __initconst
+#endif
+
+#ifndef __devexit
+#define __devexit      __exit
+#endif
+
+#ifndef __devexitdata
+#define __devexitdata  __exitdata
+#endif
+
+#ifndef __devexitconst
+#define __devexitconst __exitconst
+#endif
+
+#ifndef __devexit_p
+#define __devexit_p    __exit_p
+#endif
+
 #endif /*  _COMPAT_H */

Und da Du ja gerade am Ändern bist, kannst Du auch gleich alle Warnings mit abstellen:

/usr/src/media_build_experimental/v4l/saa716x_rom.c: In function 'saa716x_eeprom_header':
/usr/src/media_build_experimental/v4l/saa716x_rom.c:115: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int'
/usr/src/media_build_experimental/v4l/saa716x_rom.c:115: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int'
...

Gruß
e9hack

Quote from jasminj

Du kannst einfach folgende Zeilen in "include/linux/init.h" vor der Zeile /* Used for HOTPLUG_CPU */ rein kopieren. Dann müssten alle Treiber in media-experimental wieder bauen:

Code

#define __devinit
#define __devinitdata
#define __devinitconst
#define __devexit
#define __devexitdata
#define __devexitconst

Patch mach ich dir keinen, weil der ev. in zukünftigen Versionen nicht mehr applied, weil media-experimental wird sicher noch eine Weile so bleiben, wie es ist, denke ich.
Alternativ kannst du die Defines nur in den betroffenen Files am Beginn rein geben (nach der include Orgie), was aber mühsamer sein wird, weil sicher auch andere Files von media-experimantal betroffen sind.

Eigentlich gehören die Module gerichtet. Wenn man es neu definiert, dann bitte so:

#define __devinit  __init
....

Es gehört dann in compat.h rein.

Gruß
e9hack

Ein abfeuern von 'xset -display :0 -dpms' nach dem X-Server Start hat mich erstmal über die 20 Minuten gebracht. Das Makefile werde ich aber auch noch ändern.

Gruß
e9hack

Quote from e9hack

Es scheint der Screen-Saver zu sein. 'xset -display :0 -dpms' schaltet zerhackten Ton ein, das Bild bleibt schwarz. Im log gibt es massig Fehlermeldungen.

Eigentlich starte ich X mit Option '-s off'. Das sollte den Screen-Saver doch abschalten.

Gruß
e9hack

Quote from seahawk1986

Schau mal ins Log des X-Servers.
Ansonsten kannst du es generell in der xorg.conf verbieten: https://wiki.archlinux.org/index.php/Disp…ng_up_DPMS_in_X

Es scheint der Screen-Saver zu sein. 'xset -display :0 -dpms' schaltet zerhackten Ton ein, das Bild bleibt schwarz. Im log gibt es massig Fehlermeldungen.

Gruß
e9hack

Quote from johns

Ich vermute du hast das alte Makefile verwendet:

Diff

diff --git a/Makefile-pre1.7.36 b/Makefile-pre1.7.36
index d951ebb..a84a4ad 100644
--- a/Makefile-pre1.7.36
+++ b/Makefile-pre1.7.36
@@ -26,6 +26,7 @@ CONFIG += -DUSE_PIP                   # too experimental PIP support
 #CONFIG += -DUSE_TS_VIDEO              # build new ts video parser
                                        # use ffmpeg libswresample
 CONFIG += $(shell pkg-config --exists libswresample && echo "-DUSE_SWRESAMPLE")
+CONFIG += -DUSE_SCREENSAVER
 CONFIG += $(shell pkg-config --exists vdpau && echo "-DUSE_VDPAU")
 CONFIG += $(shell pkg-config --exists libva && echo "-DUSE_VAAPI")
 CONFIG += $(shell pkg-config --exists alsa && echo "-DUSE_ALSA")

Display More

Ich benutze ein altes Makefile (von vor 1.7.35). Ich habe kein 'CONFIG += -DUSE_SCREENSAVER' im Makefile. Muß das jetzt rein?

Gruß
e9hack

Quote from mini73

20 Minuten klingt irgendwie nach Bildschirmschoner.

Wie finde ich das raus? Maus schubsen hilft nicht zum wiederbeleben. Ich verwende den nackten X-Server ohne Windows-Manager oder anderem Zeugs.

Gruß
e9hack

Ich habe seit dem 9.2.13 (d31ff55) Probleme mit softhddevice. Nach ca. 20 Minuten gibt es kein Bild und keinen Ton mehr. Der Bildschirm wird schwarz. GrabImage liefert jedoch weitherhin Bilder. Im Log gibt es keine Anhaltspunkte. Die letzte funktionierende Version ist vom 26.1.13 (8b22585). Dazwischen habe ich keine Versionen gezogen. Ffmpeg ist 1.0:

vdr:/usr/src/vdr-1.7.37-work/PLUGINS/src # ffmpeg -version
ffmpeg version 1.0
built on Jan 27 2013 15:09:55 with gcc 4.4 (SUSE Linux)
configuration: --prefix=/usr --enable-shared --enable-nonfree --enable-pthreads --enable-postproc --enable-avfilter --enable-gpl --enable-x11grab --enable-libfaac --enable-libgsm --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-vaapi --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --extra-cflags='-fPIC -mtune=native -march=native -mfpmath=sse -O4 -pipe'
libavutil      51. 73.101 / 51. 73.101
libavcodec     54. 59.100 / 54. 59.100
libavformat    54. 29.104 / 54. 29.104
libavdevice    54.  2.101 / 54.  2.101
libavfilter     3. 17.100 /  3. 17.100
libswscale      2.  1.101 /  2.  1.101
libswresample   0. 15.100 /  0. 15.100
libpostproc    52.  0.100 / 52.  0.100

Nvidia-Treiber ist 318.18. Mit der Version von heute ist softhddevice wieder schwarz geworden. Laufzeit war genau 20 Minuten. Das Log sagt nichts. Es ist 16:41 passiert:

Feb 12 16:38:08 vdr vdr: video: 16:06:37.193  +26  377   0/\ms  64+2 v-buf
Feb 12 16:39:08 vdr vdr: video: 16:07:37.193  +25  424   0/\ms  61+2 v-buf
Feb 12 16:39:56 vdr kernel: [ 1332.483896] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables C
Feb 12 16:40:03 vdr vdr: [6447] (channels.c:258) changing name of channel 1405 from '372 - 15:00,;' to '372 - 17:00,;'
Feb 12 16:40:03 vdr vdr: [6447] (channels.c:486) linking channel 1093 from 1533 1402 1405 1400 1406 1426 1544 1543 1429 to 1533 1402 1400 1405 140
Feb 12 16:40:08 vdr vdr: video: 16:08:37.193  +24  351   0/\ms  64+2 v-buf
Feb 12 16:41:00 vdr vdr: video: speed up video, droping frame
Feb 12 16:41:00 vdr vdr: video: 16:09:29.073  -24  350   0/\ms  63+1 v-buf
Feb 12 16:41:07 vdr vdr: [6464] (outputserial.c:650) Aurora: size=5116679, speed=8527 Byte/s
Feb 12 16:41:08 vdr vdr: video: 16:09:37.213  +44  399   0/\ms  64+2 v-buf
Feb 12 16:42:08 vdr vdr: video: 16:10:37.213  +43  446   0/\ms  66+2 v-buf
Feb 12 16:43:08 vdr vdr: video: 16:11:37.213  +42  373   0/\ms  64+2 v-buf
Feb 12 16:44:08 vdr vdr: video: 16:12:37.213  +41  420   0/\ms  66+2 v-buf
Feb 12 16:44:23 vdr vdr: [6565] (thread.c:252) epg data writer thread started (pid=6438, tid=6565, prio=low)
Feb 12 16:44:24 vdr vdr: [6565] (thread.c:264) epg data writer thread ended (pid=6438, tid=6565)

Gruß
e9hack

Es gibt zwei Verzögerungen. Hier wird die Firmware geladen:

9 15:08:11 vdr kernel: [ 8178.596071] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
  9 15:08:12 vdr kernel: [ 8179.005931] DRXK driver version 0.9.4300

Hier wird der Tuner-Chip initialisiert:

9 15:08:12 vdr kernel: [ 8179.012464] drxk: frontend initialized.
  9 15:08:12 vdr kernel: [ 8179.012472] (/usr/src/media_build_experimental/v4l/ddbridge-core.c:1250) dvb_input_attach
     -> call to tuner_attach_tda18271()
  9 15:08:13 vdr kernel: [ 8180.423416] (/usr/src/media_build_experimental/v4l/ddbridge-core.c:1253) dvb_input_attach
  9 15:08:13 vdr kernel: [ 8180.423435] DDBridge 0000:02:00.0: DVB: registering adapter 1 frontend 0 (DRXK DVB-C DVB-T).

Gruß
e9hack

Hi,

ich habe vor ein paar Tagen meiner alten Suse 11.2 Installation eine 3TB WD Platte untergeschoben. Das Bios sagt zwar, daß da nur 700GB wären. Der Kernel ist ein selber compilierter 3.7.4, da es für Suse 11.2 keine Updates mehr gibt. Util-linux scheint aktuell genug zu sein. Suse 11.2 bringt aber keine Tools mit, die eine GUID-Partitionstabelle erstellen oder bearbeiten können. Ich habe gptfdisk 0.8.6 compiliert. Hardware ist ein älters AMD board, was nur SATA mit 1,5MBit kann.

Gruß
e9hack

Quote from iNOB

Code

ffmpeg version N-36313-g2cba62b, Copyright (c) 2000-2011 the FFmpeg developers
  built on Jan  1 2012 00:05:45 with gcc 4.4.5
  configuration: --prefix=/usr --enable-shared --enable-gpl --enable-postproc --enable-pthreads --enable-libmp3lame --enable-libvorbis --enable-libxvid --enable-libx264 --enable-libtheora --enable-zlib --enable-nonfree --enable-filter=av --enable-filter=lavf --enable-libfaac --enable-pic --enable-libschroedinger --enable-x11grab --enable-version3
  libavutil      51. 33.100 / 51. 33.100
  libavcodec     53. 49.100 / 53. 49.100
  libavformat    53. 29.100 / 53. 29.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 57.100 /  2. 57.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0.  5.100 /  0.  5.100
  libpostproc    51.  2.100 / 51.  2.100

Display More

Iss schon "relativ" alt und da produktiv genutzt, werde ich auch so schnell nix dran ändern.

Der nvidia Installer jubelt einem immer neue ffmpeg Libraries unter. ffmpeg -version zeigt leider nur die zum kompilieren von ffmpeg verwendeten Libraries an. Was tatsächlich installiert ist, erfährt man nicht. Wenn man aus irgendwelchen Gründen ältere Libraries benötigt, muß man die Library-Links zurückverbiegen.

Gruß
e9hack

Quote from geronimo

Wobei ...
... die SD-FF zickt nicht nur bei HD-Aufnahmen rum.
Bei manchen Sendungen von 3sat ist die Bitrate derart hoch, dass es die FF nimmer verkraftet.
Dann geht sie in Zeitlupen-Anzeige über mit völlig abstrusen Nebeneffekten (Zeitlupenton, Bildaussetzer, etc).
Klar, auch in so einem Falle sind die Aufnahmen dann Schrott.

In der Konstellation ist die FF auch bei mittleren Bitraten überfordert. Da gehen zwei Streams zum PC und einer zurück zur Karte. Dafür ist das Interface zum TMX320AV7111 zu schmalbandig.

Gruß
e9hack

Hi,

wenn ich PIP beende, sehe ich immer 2..4 Meldungen über freigegebene, aber nicht verwendete Surfaces:

Jan  7 17:46:18 vdr vdr: (video.c:8120) video: slow down video, duping frame
Jan  7 17:46:18 vdr vdr: (video.c:8125) video: slow down video, duping frame
Jan  7 17:46:18 vdr vdr: (video.c:8171) video: 24:28:51.871  +84  684 240/\ms  23+7 v-buf
Jan  7 17:46:31 vdr vdr: (video.c:5546) video/vdpau: release surface 0x000015, which is not in use
Jan  7 17:46:31 vdr vdr: (video.c:5546) video/vdpau: release surface 0x000016, which is not in use
Jan  7 17:46:31 vdr vdr: (video.c:5546) video/vdpau: release surface 0x000017, which is not in use
Jan  7 17:46:31 vdr vdr: [13641] (thread.c:264) TS buffer on device 1 thread ended (pid=13610, tid=13641)
Jan  7 17:46:31 vdr vdr: [13639] (ringbuffer.c:43) buffer stats: 112236 (2%) used
Jan  7 17:46:31 vdr vdr: [13639] (thread.c:264) receiver on device 1 thread ended (pid=13610, tid=13639)
Jan  7 17:46:36 vdr vdr: [13636] (outputserial.c:650) Aurora: size=5268192, speed=8780 Byte/s

Gruß
e9hack

Quote from grumble

Vielleicht kann ich ja einfach einen Treiberbaustein tauschen.

Der zu wechselnde Treiberbaustein ist der TMX320AV7111GFN

Gruß
e9hack