Hi,
ich habe ein Ticket im TRAC erstellt, ist an Alwin assigned.
Gruß,
Matthias
Posts by hubermat
-
-
Hi,
bei mir klappts auch nicht. Außerdem habe ich immer wieder Störungen im Bild, die ich sonst nicht habe, manchmal stürtz XBMC auch komplett ab.
Von daher verwende ich jetzt statt dem TV-Plugin direkt die Video-Wiedergabe über das per SMB gemountete video-Verzeichnis. Da klappt dann auch spulen, und ich habe meine Aufnahmen schön hierarchisch anstatt in einer flachen Liste. Ist ganz hilfreich bei 1TB an AufnahmenGruß,
Matthias -
Hallo zusammen,
ich habe das Problem bei mir lösen können. Die Ursache war, daß bei der von XBMC verwendeten FFMpeg-Version die Anzahl der Frames für die Erkennung des (Video-)Formats heruntergesetzt ist. Ich habe die ursprünglichen Werte von einem aktuellen FFMepg in der Datei xbmc/cores/dvdplayer/Codecs/ffmpeg/libavformat/avformat.h korrigiert, und jetzt wird das Format wieder erkannt.
Hier die Defines, die zu ändern sind (mit Zeilennummer):
451: #define MAX_PROBE_PACKETS 2500 // was: 100
647: #define RAW_PACKET_BUFFER_SIZE 2500000 // was: 32000Danach einfach nochmal übersetzen (make) und wie gewohnt installieren.
Gruß,
Matthias -
So, Server ist upgegraded und läuft mit Version 1.6.0r2 + streamdev-0.5.0pre. Gerade läuft das aktuelle Sportstudio in der XBMC-Oberfläche
Probleme habe ich noch mit dem Abspielen von Aufnahmen: Aufnahmen abspielen schlägt bei einigen fehl
Gruß,
Matthias -
Hallo zusammen,
ich habe auch das Problem mit den Aufnahmen. Symptom: Audio spielt, aber kein Bild. Im XBMC wird das Lautsprecher-Bildchen angezeigt. Im Log steht dann sowas:
Code
Display More22:19:31 T:2998074256 M:1442181120 DEBUG: AddOnLog: PVRDLL/VDRClient: CVTPTransceiver::GetStreamRecordin g - local address 192.168.0.114:41473 22:19:31 T:2998074256 M:1442181120 DEBUG: AddOnLog: PVRDLL/VDRClient: CVTPTransceiver::OpenStreamSocket - listening on 0.0.0.0:33415 22:19:31 T:2998074256 M:1442181120 DEBUG: Open - Recording has started on filename pvr://recordings/30.t s 22:19:31 T:2998074256 M:1442181120 NOTICE: Creating Demuxer 22:19:31 T:2998074256 M:1442181120 DEBUG: Open - probing detected format [mpeg] 22:19:31 T:2998074256 M:1442181120 DEBUG: Open - av_find_stream_info starting 22:19:31 T:2998074256 M:1442377728 DEBUG: Open - av_find_stream_info finished 22:19:31 T:2998074256 M:1442377728 INFO: ffmpeg[B2B2FB90]: Input #0, mpeg, from 'pvr://recordings/30.ts ': 22:19:31 T:2998074256 M:1442377728 INFO: ffmpeg[B2B2FB90]: Duration: 00:00:03.14, start: 85075.297467 , bitrate: -2147483 kb/s 22:19:31 T:2998074256 M:1442377728 INFO: ffmpeg[B2B2FB90]: Stream #0.0[0x1e0]: Video: 0x0000, 90k tbr, 90k tbn 22:19:31 T:2998074256 M:1442377728 INFO: ffmpeg[B2B2FB90]: Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz , 2 channels, s16, 192 kb/s 22:19:31 T:2998074256 M:1442377728 NOTICE: Opening video stream: 0 source: 256 22:19:31 T:2998074256 M:1442377728 ERROR: CDVDPlayerVideo::OpenStream - Invalid framerate 90000, using forced 25fps and just trust timestamps 22:19:31 T:2998074256 M:1442377728 NOTICE: Creating video codec with codec id: 102400 22:19:31 T:2998074256 M:1442377728 DEBUG: FactoryCodec - Video: - Opening 22:19:31 T:2998074256 M:1442377728 DEBUG: CDVDVideoCodecFFmpeg::Open() Unable to find codec 102400 22:19:31 T:2998074256 M:1442377728 DEBUG: FactoryCodec - Video: - Failed 22:19:31 T:2998074256 M:1442377728 ERROR: Unsupported video codec 22:19:31 T:2998074256 M:1442377728 WARNING: OpenVideoStream - Unsupported stream 0. Stream disabled.
Der im XBMC eingebaute ffmpeg scheint wohl den video-codec nicht zu erkennen...
Das gleiche tritt übrigens auch auf, wenn ich die .vdr Datei direkt mit XBMC abspiele (über Video im Hauptmenü, mittels SMB gemappt).
Live-TV hingegen klappt vorzüglich...
Hier noch meine Specs:
Client: XBMC pre-testing rev. 23164 vom 25.09.
Server: VDR 1.6.0r2, streamdev-0.5.0pre
Aufnahmen alle erstellt mit VDR 1.4.1, bevor ich wegen XBMC/vdr auf 1.6.0 umgestiegen bin...Über jeglichen Hinweis wäre ich dankbar!
Gruß,
Matthias -
Hallo BBlack,
ich bin gerade dabei, mir das gleiche auszusetzen und stehe vor den gleichen Fragestellungen. Nur daß ich den VDR auf dem Server im Keller laufen habe und dort noch 1TB an Aufnahmen von der aktuell genutzen Version 1.4.1 (läuft seit 2 Jahren unverändert produktiv liegen. Diese will ich mir natürlich erhalten...
Installiere gerade auf einer Acer Aspire Revo R3600 das XBMC pvr-testing von heute (rev. 23164). Danach ist der Server dran und bekommt eine Jungkur (neuester Kernel, VDR 1.6.0, streamdev 0.5.0-pre for XBMC).
Es stellen sich mir die gleichen Fragen wie Dir bezüglich 1.7.x. Ich werde es wohl erstmal mit 1.6.0 versuchen.
Berichte über Erfolge/Mißerfolge würden mich sehr interessieren!
Gruß,
Matthias -
Okay, habs inzwischen selbst gefunden. Die Spannungen scheinen korrekt zu sein.
Sobald der Regen (!) es zuläßt, werden ich mal die Kabel/Übergänge überprüfen. -
Ich habe gerade die Ausgangsspannung der Karte an der F-Buchse gemessen: 13 V bei ARD, 18 V bei Sat1. Ist das okay?
-
Moin,
ich habe jetzt auch ein "lost lock on channel" - "regained lock on channel" Problem. Mein System mit einer Nova-S, Kernel 2.6.17, vdr 1.4.1 lief seit mehreren Jahren im 24/7-Betrieb stabil.
Seit Ostermontag habe ich jetzt ein Empfangsproblem:Code
Display Morestatus SCVYL | signal a292 | snr b322 | ber 00000200 | unc 00000000 | FE_HAS_LOCK status S | signal 8fd4 | snr 8a21 | ber 0000ff00 | unc 00000000 | status S | signal 9606 | snr 8e86 | ber 0000ff00 | unc 00000000 | status SCVYL | signal a141 | snr acf2 | ber 0000ff00 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal ac7d | snr bd3f | ber 00000e00 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal af02 | snr c933 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal af00 | snr d13d | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal b03e | snr c77d | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal a9ef | snr b088 | ber 00000700 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal a7ad | snr ac7d | ber 00008500 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal aa65 | snr b637 | ber 00001d00 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal ac67 | snr b9a9 | ber 00000100 | unc 00000000 | FE_HAS_LOCK status SC | signal 9ec3 | snr 98d3 | ber 0000ff08 | unc 00000000 | status S | signal 7d6e | snr 8148 | ber 0000ff28 | unc 00000000 | status SCVYL | signal a9f2 | snr b0c7 | ber 0000ff00 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal af71 | snr d944 | ber 00000100 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal af01 | snr d989 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal af06 | snr d9b6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal adc2 | snr c90f | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal adc0 | snr ced6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal adc2 | snr d671 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal b03e | snr d3c8 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal adc1 | snr d071 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal aead | snr c564 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal ab39 | snr b535 | ber 00000100 | unc 00000000 | FE_HAS_LOCK status S | signal 8575 | snr 83f1 | ber 0000ff08 | unc 00000000 | status S | signal 90de | snr 8823 | ber 0000ff08 | unc 00000000 | status SC | signal 8fd1 | snr a146 | ber 0000ff08 | unc 00000000 | status SCVYL | signal a9fb | snr ceac | ber 00004300 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal a7a1 | snr c31e | ber 00000000 | unc 00000000 | FE_HAS_LOCK status SCVYL | signal a282 | snr ab1e | ber 00002100 | unc 00000000 | FE_HAS_LOCK
Syslog zeigt dauerhaft Einträge der Form:
CodeApr 18 10:56:53 huber vdr: [25043] frontend 0 lost lock on channel 25, tp 112460 Apr 18 10:56:54 huber vdr: [25043] frontend 0 regained lock on channel 25, tp 112460 Apr 18 10:56:59 huber vdr: [25043] frontend 0 lost lock on channel 25, tp 112460 Apr 18 10:57:01 huber vdr: [25043] frontend 0 regained lock on channel 25, tp 112460 Apr 18 10:57:03 huber vdr: [25043] frontend 0 lost lock on channel 25, tp 112460 Apr 18 10:57:03 huber vdr: [25043] frontend 0 regained lock on channel 25, tp 112460
Das Problem tritt mit jedem Channel auf, keine Aufnahme gelingt mehr ohne Fehler und Glitches, ab und zu macht der VDR ein emergency restart.Was könnte das sein? Ich war über Ostern nicht am System dran, habe aber noch am Ostersonntag eigentlich den ganzen Tag über Aufnahmen gemacht (auch mehrere parallel - alle prima). Könnte sich dabei etwas überhitzt haben => Karte kaputt? Vielleicht ist ein Kind gegen die Sat-Schüssel gerempelt - aber dann würde ich doch nicht zwischendrin FE_HAS_LOCK mit 0 BER bekommen, oder? Was meint Ihr?
Bin für jeden Tip dankbar.
Gruß,
Matthias -
Hallo zusammen,
ich habe mein Display jetzt schon einen ganze Weile am Laufen und es läuft prima mit XBOX und VDR. Jetzt würde ich gerne das Einschalten und Umschalten zwischen den Eingängen automatisieren. Ich glaube mich zu erinnern, daß ich irgendwo mal was über eine serielle Schnittstelle gelesen habe. Hat da jemand schon Erfahrungen gemacht oder kennt die Parameter/Kommandos?
Gruß,
Matthias -
Hallo,
hier mal meine Erfahrungen zu den ganzen Einstellungs/Auflösungs-Sachen.
Ich betreibe das Display an DVI, mit 1280x768. Dabei kommt jedes Pixel einzeln sauber rüber, es wird auch 1280x768 angezeigt. Justieren mußte ich in diesem Betriebsmode gar nichts. Daher merke ich ggf. nicht, daß Einstellungen verloren gehen, da ich ja nichts spezielles hier eingestellt habe.
Im TV-Tuner-Betrieb, der etwas zu 50% der Betriebsdauer genutzt wird (solange ich noch am VDR bastele) habe ich auch noch nie Einstellungen verloren. Kanäle, Aspekt-Mode etc. sind alle okay.
Gruß,
Matthias -
Danke, klappt (wenn ich das -O2 rausnehme).
Allerdings tritt dann ein anderes Phänomen auf: der VDR (bzw. das Plugin) wird nicht richtig zuende initialisiert und bleibt irgendwo hängen. Das äußert sich so, daß der VDR läuft (Bild und OSD ist da), aber an der Kommandozeile, an der ich den VDR in den Hintergrund schicken will, bleibt der VDR im Vordergrund. Will heißen, /etc/init.d/vdr start kommt nicht zurück. Wenn ich dann mit Ctrl-C abbreche, wird der VDR gestoppt.
Nach Neuübersetzen von vdr-softdevice mit -O2 und auskommentiertem MMX2-Part tritt dieses Problem nicht mehr auf.
Sehr komisch, das!P.S. Hatte ich schon erwähnt, daß das Bild leicht ruckelt? Auslastung liegt zwischen 50% und 90%, je nach bewegtem Inhalt (Deinterlacer aktiv). Die Daten kommen über NFS rein bzw. werden über streamdev gestreamt.
P.P.S. Vielen Dank für die vielen Ratschläge. Ihr quält Euch jetzt schon ganz schön lange mit meinen "Problemen" rum...
-
Code
scu ~ # gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.1 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.1 (Gentoo 4.1.1)
-
Hier der diff zu meiner aktuellen (gepatchten) Version, die mit Pseudo-Alpha funktioniert:
Diff
Display Morecvs diff -bBU 3 SoftOsd.[ch] Index: SoftOsd.c =================================================================== RCS file: /cvsroot/softdevice/softdevice/SoftOsd.c,v retrieving revision 1.17 diff -b -B -U3 -r1.17 SoftOsd.c --- SoftOsd.c 10 Sep 2006 20:33:29 -0000 1.17 +++ SoftOsd.c 25 Sep 2006 18:39:02 -0000 @@ -391,7 +391,7 @@ void cSoftOsd::ARGB_to_RGB32(uint8_t * dest, color * pixmap, int Pixel) { uint8_t *end_dest=dest+4*Pixel; -#ifdef USE_MMX2 +#if 0 //def USE_MMX2 end_dest-=16; __asm__( "movq (%0),%%mm5 \n" Index: SoftOsd.h =================================================================== RCS file: /cvsroot/softdevice/softdevice/SoftOsd.h,v retrieving revision 1.7 diff -b -B -U3 -r1.7 SoftOsd.h --- SoftOsd.h 10 Jul 2006 18:23:28 -0000 1.7 +++ SoftOsd.h 25 Sep 2006 18:39:02 -0000 @@ -13,12 +13,12 @@ #define __SOFTOSD_H__ // osd some constants and macros -#define OPACITY_THRESHOLD 0x9FLL +#define OPACITY_THRESHOLD 0x9FLL /* 0x00LL */ #define TRANSPARENT_THRESHOLD 0x1FLL #define COLOR_KEY 0x00000000LL -#define OSD_WIDTH 720 -#define OSD_HEIGHT 576 +#define OSD_WIDTH 1280 +#define OSD_HEIGHT 768 #define IS_BACKGROUND(a) (((a) < OPACITY_THRESHOLD) && ((a) > TRANSPARENT_THRESHOLD)) #define IS_TRANSPARENT(a) ((a) < TRANSPARENT_THRESHOLD) @@ -35,7 +35,7 @@ #define X_OFFSET 0 #define Y_OFFSET 0 -#define OSD_STRIDE (736) +#define OSD_STRIDE (1280) #define COLOR_RGB16(r,g,b) (((b >> 3)& 0x1F) | ((g & 0xF8) << 2)| ((r & 0xF8)<<10) )
Also ist außer der OSD-Größe und dem Auskommentieren des MMX-Teils nichts geändert. Wenn ich den Patch in SoftOSD.c nicht mache, habe ich einen "schwarzen Bildschirm" (und "200 Puls - bald..." ;-).
Gruß,
Matthias -
Im SoftOSD.diff war nur der MMX2-Part ge-if 0-lt.
Das habe ich jetzt wieder rausgemacht (also Original-SoftOSD.c) und Deinen DirectFB-Patch eingespielt. Ergebnis: kein Video-Bild.
Dann habe ich den MMX2-Part wieder rausgemacht und siehe da - Video-Bild ist wieder da, mit dem "Pseudo-Alpha". Also alles wie vorher.
Ich kann damit gut leben. Warum allerdings der MMX2-Part nicht funktioniert, würde mich schon interessieren... -
Was ich unter "Skalierung" bezeichnet habe, gibt es natürlich schon längst! Nennt sich "Crop-Mode". Ich schäme mich in Grund und Boden...
Ich bin mir allerdings ziemlich sicher, daß es keinen Crop-Mode für 15:9 gibt. Das werde ich jetzt dann doch noch selbst nachrüsten... -
Suuuppper!!! Der Pseudo-Mode funktioniert jetzt einwandfrei!
Jetzt werde ich nur noch an der Skalierung arbeiten, dann bin ich zufrieden.
Wieso wird eigentlich in video-dfb eine Fernbedienung angelegt (und angelernt)? Macht das der VDR nicht selbst über z.B. lirc?
Vielen Dank für Deine Hilfe,
Matthias -
Schlechte Neuigkeiten. Ich bin nochmal zurück auf den Patch-Stand, bei dem ich nur den MMX2-Teil auskommentiert habe. Ergebnis was das halbtransparente OSD.
Ich habe mich die ganze Zeit gefragt, wie das überhaupt sein kann. Wenn meine Layer laut dfbinfo gar kein Alpha können, sondern nur dst-colorkeying, dann ist doch Halbtransparenz eigentlich gar nicht möglich (zumindest nicht über Layer), sondern das Video-Bild müßte "von Hand" mit dem OSD verrechnet werden (was aktuell wohl nicht erfolgt, denke ich).
Ich habe jetzt bei genauerer Betrachtung festgestellt, daß das OSD gar nicht halbtransparent ist!!! Tatsächlich sah das nur aus der Entfernung so aus. Von Nahem betrachtet, ist das ein opaques OSD, bei dem jedes zweite horizontale Pixel das OSD zeigt, und das andere das Videobild...Wie geht's jetzt weiter? Was läßt sich denn (rein theoretisch) mit Destination Colorkeying so alles anstellen?
Das Berechnen der OSD-Transparenz in Echtzeit (sprich: Verrechnung mit dem decodierten Live-Bild) wäre zu rechenintensiv, oder?Wenigstens ein Lichtblick: Das Hängenbleiben tritt nicht mehr auf. Frag mich nicht...
Gruß,
Matthias -
Wenn ich die Zeile regs -> SCLRKVH = regs -> SCLRKVL = regs -> SCLRKEN = 0; reinnehme, passiert
A.: opaques OSD, wenn ich SoftOSD.c gar nicht ändere (also keine Änderung zu früher)
B.: opaques OSD und kein Video-Bild (sic!), wenn ich in SoftOSD.c den MMX2 Part rausnehme und dest[3]=0.Pixelformat ist bis auf den einen kurzen Test drei Postings weiter hinten immer auf ARGB.
Das Hängenbleiben ist mir schon beim ersten Test mit softdevice aufgefallen. Seitdem habe ich das.
Mit einem halbtransparenten OSD wäre ich schon zufrieden, wenn ich den Grad der Transparenz einstellen könnte.
Wenn ich irgendwie mitdenken kann/soll, bitte sagen! Wie wäre es z.B. mit dem Ansatz vom 3. Versuch (colorkeying), nur daß man vorher einen halbtransparenten Hintergrund draufmalt ("blittet"?).
Gruß,
Matthias -
So, neue Tests:
1. Nur dest[3] auskommentieren (und MMX2-Code #if 0llen):Ergebnis:
[Blocked Image: http://www.jazzgames.com/dest0.JPG]2. dest[3]=0 (und MMX2-Code #if 0llen):
Ergebnis (kein Unterschied, daher gleiches Bild !):
[Blocked Image: http://www.jazzgames.com/dest0.JPG]3. HasAlpha = true und dest[3]=0 (und MMX2-Code #if 0llen):
Code- dest[3]=GET_A(c); + dest[3]=0; ... - HasAlpha=!OSDpseudo_alpha; + HasAlpha = true; // HasAlpha=!OSDpseudo_alpha;
Ergebnis:
[Blocked Image: http://www.jazzgames.com/HasAlpha.JPG]
[Blocked Image: http://www.jazzgames.com/HasAlphaClose.JPG]Ich habe dann auch nochmal einen Test gemacht, bei dem ich nur HasAlpha=true gesetzt habe. Ergebnis ist das gleiche wie bei 3.
Gruß,
MatthiasP.S. Wenn ich den VDR wieder beende, kann ich ihn nicht erneut starten, softdevice bleibt bei der Initialisierung von DFB hängen (das selbe passiert mit jeder anderen DFB-Test-Applikation auch). Wenn ich den VDR nicht starte, kann ich die DFB-Applikationen beliebig oft starten und stoppen. Irgendeine Idee, was das sein könnte? Ich muß für jeden VDR Test-Run den Rechner neu starten...