Beiträge von Norad

  • Update: Optimierter av7110 Treiber

    Moin,
    hatte bislang auf meinem Athlon64 das Problem, dass ich bei niedrigster Taktung (800MHz) bei der Wiedergabe von Aufnahmen Aussetzer hatte. Das scheint verschwunden zu sein :)
    Bislang läuft der Treiber bei mir bislang perfekt.

  • zweite Karte mit Kernel 2.6

    Welche Kernelversion ist das?
    Gib mal die Ausgabe von dmesg.
    Die beiden Karten müssten durch den den gleichen Treiber betrieben werden können, aber mit Budgetkarten kenne ich mich nicht aus ;)

  • [PATCH] 64bit fix für GraphLCD

    Moin,
    nachdem ich meinen VDR auf ein amd64-Debian umgezogen hatte, wollte GLCD keine animierten .glcd-files mehr abspielen. Ursache war offenbar ein bei 64bit größerer Header, so dass die offsets beim lesen der Dateien nicht mehr stimmten.


    Folgender Patch fixt das bei mir, ich weiß allerdings nicht, ob das jetzt noch auf 32bit läuft ...:

    Diff
    --- graphlcd-base-0.1.3/glcdgraphics/glcd.c     2005-10-31 17:18:58.000000000 +0100
+++ graphlcd-base-0.1.3.mod/glcdgraphics/glcd.c 2006-04-08 14:35:17.000000000 +0200
@@ -38,7 +38,7 @@
        unsigned short height; // height in pixels
        // only for animations
        unsigned short count;  // number of pictures
-       unsigned long delay;   // delay in ms
+       unsigned int delay;   // delay in ms
 };
 #pragma pack()


    Außerdem stieg mein gcc-4.1 mit

    Code
    framebuffer.c: In member function 'virtual int GLCD::cDriverFramebuffer::Init()':
framebuffer.c:103: error: cast from 'char*' to 'int' loses precision
make[1]: *** [framebuffer.o] Error 1


    aus, folgender Patch "behebt" das, ich weiß allerdings nicht, was dabei kaputt geht ;)

    Diff
    --- graphlcd-base-0.1.3/glcdgraphics/glcd.c     2005-10-31 17:18:58.000000000 +0100
+++ graphlcd-base-0.1.3.mod/glcdgraphics/glcd.c 2006-04-08 14:35:17.000000000 +0200
@@ -38,7 +38,7 @@
        unsigned short height; // height in pixels
        // only for animations
        unsigned short count;  // number of pictures
-       unsigned long delay;   // delay in ms
+       unsigned int delay;   // delay in ms
 };
 #pragma pack()

  • Timer korruption mit XXV svn r721 (und früher ..)

    bin nochmal auf die aktuelle SVN gewechselt und habe sämtliche Tabellen der Datenbank gedroppt.
    Ich kann den Fehler nicht mehr reproduzieren ..
    Das mit der Datenbank habe ich vorher auch schon gemacht, bloß habe ich dabei die Tabelle vom Autotimer immer in Ruhe gelassen.
    Mal sehen, on sich das Problem nochmal zeigt, sonst hefte ich das als X Akte ab.

  • Segfault mit Plugin ttxtsubs

    Moin, wenn ich mit vdr-1.3.44 und dem Patch vdr-1.3.44-subtitles-0.3.10-and-ttxtsubs-0.0.5.diff das ttxtsubs-Plugin benutzte, bekomme ich Segfaults beim beenden des VDR, BT:


    Ich kann damit nichts anfangen, mir ist schleierhaft, wie solch ein Backtrace zu stande kommen kann ...
    Dies passiert auch, wenn ich die anderen Plugins nicht lade (z.B. subtitles).
    Irgendwer 'ne Idee, was das sein kann?

  • Timer korruption mit XXV svn r721 (und früher ..)

    Moin,
    seit einiger Zeit habe ich das Problem, das mir mein VDR (1.3.44 mit diversen Patches und Plugins) ziemlich regelmäßig um die Ohren fliegt.
    Nach einigem Rumprobieren fiel mir auf, dass die Abstürze nur auftreten, wenn XXV läuft.
    Zeitweilig ließ sich der VDR auch garnicht mehr starten, weil ihm seine timers.conf total zermüllt war.
    Also habe ich die Timer-Sache mal genauer untersucht:
    Sobald XXV läuft, sammelt sich "Müll" im AUX-Feld der Timer an, ich finde den per

    Code
    svdrpsend.pl lstt | sed -re "s/[\r\n]//" | egrep -v ":$|epgsearch>$"


    (ja, ich benutze epgsearch und habe das autotimer-modul von xxv deaktiviert, Problem bestand aber auch schon, als ich noch XXV Autotimer benutzt habe).
    Beispiel:

    Code
    250-6 1:8:2006-03-27:2305:0015:40:99:Akte X - Die unheimlichen Fälle des FBI~Sternenlicht (Closure (2)), Die Originale! Serien bei kabel eins:IÚ· ³ø    E
250-7 1:8:2006-03-28:0000:0106:40:99:Outer Limits - Die unbekannte Dimension~Das Gesetz der Natur (The Balance of Nature):IÚ·p©ø
250-8 1:8:2006-03-28:1709:1825:40:99:Star Trek - Das nächste Jahrhundert~Die Seuche (Symbiosis):ø·      ù       ’

    (btw. war epgsearch gerade nicht geladen, als das hier auftrat).


    Besonders schnell lässt sich das Problem provozieren, wenn ich Timer über XXV verändere bzw. lösche.
    Im Log fällt mir dabei folgendes auf (Auzug, das geht so noch weiter..):

    Code
    46 (202) [14:32:21] TIMERS: EVT:270 Call command "delt 5" on svdrp
47 (202) [14:32:23] TIMERS: EVT:270 Call command "lstt" on svdrp
48 (202) [14:32:32] TIMERS: EVT:270 Call command "delt 4" on svdrp
49 (202) [14:32:33] TIMERS: EVT:270 Call command "modt 6 1:::::0:0::" on svdrp
50 (202) [14:32:34] TIMERS: EVT:270 Save timer "" with TimerId: "0"
51 (202) [14:32:34] TIMERS: EVT:270 Call command "modt 11 1:::::0:0::" on svdrp
52 (202) [14:32:34] TIMERS: EVT:270 Save timer "" with TimerId: "0"


    Ich bin jetzt auf SVN Revision 686 zurück gegangen, bislang scheint alles in Ordnung.
    Hoffe, ihr könnt damit was anfangen


    Gruß & Danke
    Malte

  • ANNOUNCE: graphlcd-0.1.3

    hmm, das -base archiv ist nicht aufzufinden ...


    BTW. passiert mir das hier mit dem vdr 1.3.39 mit der -base 0.1.2:


    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread -1544967248 (LWP 31681)]
    cGraphLCDState::SetChannel (this=0x8daf628, ChannelNumber=0) at channels.h:204
    204 tChannelID GetChannelID(void) const { return tChannelID(source, nid, (nid || tid) ? tid : Transponder(), sid, rid); }
    Current language: auto; currently c++
    (gdb) bt
    #0 cGraphLCDState::SetChannel (this=0x8daf628, ChannelNumber=0)
    at channels.h:204
    #1 0xa7cc54c2 in cGraphLCDState (this=0x8daf628) at state.c:64
    #2 0xa7cba051 in cGraphLCDDisplay::Action (this=0xa7ccc3c0) at display.c:255
    #3 0x08105780 in cThread::StartThread (Thread=0xa7ccc3c0) at thread.c:243
    #4 0xa7f20e70 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
    #5 0xa7d9ec6e in clone () from /lib/tls/i686/cmov/libc.so.6

  • wieder mal doppelte EPG Einträge: w_epgfix

    hmm, inzwischen habe ich eine Macke im EPG gefunden, und zwar auf RTL2.
    Ich pumpe da mit infosatepg + tvmovie2vdr zusätzlich EPG rein. Am Mittwoch gibt's da 2 Folgen Stargate SG-1 hintereinander.
    Aus infosat kommt Stargate 20:15-22:05 (also Doppelfolge als einzelnes Event), RTL2 liefert Stargate 20:15-21:00 und Stargate 21:00-22:05 (also zwei Folgen als einzelne Events).


    Okay, das kann man denke ich nicht unter einen Hut bringen, für mich also akzeptabel (wo war doch gleich dieser noEPG-Patch ...).

  • wieder mal doppelte EPG Einträge: w_epgfix

    Moin,
    ich habe mir mal überlegt, wie man 'ne Sendung außer über ihre Startzeit erkennen kann und mir fiel der 'disableDoubleEpgEntrys' von Emanuel Wontorra ein (den habe ich vor dem w_epgfix benutzt). Dort wird neben der Startzeit die Dauer einer Sendung benutzt, um diese zu erkennen. Ich habe den w_epgfix mal so umgebastelt, dass er auch die Dauer berücksichtigt, bislang habe ich keine doppelten Einträge finden können und die vorher unterschlagenen Sendungen fehlen auch nicht mehr. Vielleicht taugt der Patch ja was ...


    P.S.: die Formel für die Dauer habe ich aus Emanuel's Patch geklaut ...

  • Nachfolger der TT Rev. 1.5?

    Ist der j2 denn genau so empfindlich wie bei der Rev.1.5? Bei meiner habe ich eine Tochterplatine drauf gebaut, die die RGB-Signale auf 0.7V bringt, noch ein wenig filtert und die Karte (angeblich ...) vor Überspannungen aus dem SCART-Anschluss schützt.
    Ist das bei der "Mod"-Version hier auch noch nötig oder ist sowas schon integriert?

  • wait_for_sysfs

    udev 045 ist ziemlich alt, aktuell ist glaube ich die 065.
    da gab's änderungen in der zusammenarbeit mit dem kernel, ein update von udev währe wohl sinnvoll.

  • XXV - erste Alpha Version zum testen.

    Ich hätte da mal 'ne Anregung:
    Ich beziehe mein EPG aus dem InfosatEPG (über tvmovie2vdr). Da gibt's die Sendungstitel mit Untertiteln und 'nem sehr kurzen Summary, dass das Genre wiedergibt 'ne Woche im vorraus. Ein oder zwei Tage vor einer Sendung wird das EPG dann aber aktualisiert und die Sendung mit 'nem detaillierten Summary versehen.
    Wenn ich nun einen Autotimer habe, so wird der mit dem knappen EPG von sieben Tage vor der Sendung erstellt.
    Es währe praktisch, wenn vom Autotimer erstellte Timer automatisch an EPG-Aktualisierungen angepasst werden würden, so dass die resultierenden Aufnahmen aus aktuellen EPG-Daten erstellt werden.

  • infosatepg 0.0.9, seit samstag keine daten

    moin,
    seit Samstag (da isses mir jedenfalls aufgefallen) sieht ein infosatepg-lauf bei mir so aus:


    Wobei der Inhalt der Dateien so aussieht:

    Code
    # cat received_data/infosat_01_20
@H:1 16.01.2005 01:00
Copyright (c) 2005 TechniSat Digital. All rights reserved.


#@LO=2
@Q:


    Vorher keine Probleme ...

  • XXV - erste Alpha Version zum testen.

    Mir ist bei XXV 0.12 (mit stone-template) aufgefallen, dass bei Serien, die Doppelpunkte (z.B. 24~13:00 - 14:00 Uhr(Day 3: 01:00 P.M. To 02:00 P.M.)) der Episodenname abgeschnitten wird (aus dem obigen wird also 12~13). Ich habe da mal 'ne kleine regex in TIMERS.pm eingebaut, mit der das Problem zumindest für mich erstmal umgangen wird.
    Zitat aus man 5 vdr:

    Code
    File   The file name this timer will give to a recording.  If the  name
       contains  any  ':' characters, these have to be replaced by '|'.
       If the name shall  contain  subdirectories,  these  have  to  be
       delimited by '~' (since the '/' character may be part of a regu-
       lar programme name).