Beiträge von 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 Aufnahmen :)


    Gruß,
    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: 32000


    Danach einfach nochmal übersetzen (make) und wie gewohnt installieren.


    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:


    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

    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:


    Syslog zeigt dauerhaft Einträge der Form:

    Code
    Apr 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:


    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! :bounce1


    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... :rolleyes:


    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):

    Code
    -                        dest[3]=GET_A(c);
    +                        //dest[3]=GET_A(c);

    Ergebnis:
    [Blockierte Grafik: http://www.jazzgames.com/dest0.JPG]


    2. dest[3]=0 (und MMX2-Code #if 0llen):

    Code
    -                        dest[3]=GET_A(c);
    +                        dest[3]=0;

    Ergebnis (kein Unterschied, daher gleiches Bild ;) !):
    [Blockierte Grafik: 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:
    [Blockierte Grafik: http://www.jazzgames.com/HasAlpha.JPG]
    [Blockierte Grafik: 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ß,
    Matthias


    P.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...