Beiträge von sebixvi

  • graphlcd (base, vdr-plugin) touchcol branch (archiv)

    Keine Idee, aber denselben Fehler mit einer ganz anderen Konfiguration:


    ich habe ein DM140-GINK-Display. Sowohl mit dem dm140vfd-Plugin als auch mit LCDd bekomme ich in unregelmäßigen Abständen den Oops. Es scheint also tatsächlich ein Kernelproblem zu sein (hier auch yavdr 0.4 mit 2.6.38-13):



    Gibt's dazu schon Neuigkeiten?


    Sebi

  • Zweizeiliges Display (DM140VFD) - keine Kanalinfos mehr?

    Hmm,


    ich habe mir jetzt mal die Quellen des Plugins angesehen. Der Titel der aktuellen Sendung wird mittels dieser Funktion


    const cSchedule * schedule = schedules->GetSchedule(chID);
    if (schedule)
    {
    if ((p = schedule->GetPresentEvent()) != NULL)
    {
    if(chPresentTime && chEventID == p->EventID()) {
    return false;
    }


    bChanged = true;
    chEventID = p->EventID();
    chPresentTime = p->StartTime();
    chFollowingTime = p->EndTime();


    if(chPresentTitle) {
    delete chPresentTitle;
    chPresentTitle = NULL;
    }
    if (!isempty(p->Title())) {
    chPresentTitle = new cString(p->Title());
    }


    aus dem aktuellen Programmeintrag ausgelesen - zumindest soll dies passieren. Offenbar ist PresentTitle aber leer, sodass dm140vfd auf die Ausgabe Zeit/Kanalname zurückschaltet.


    Gab es hier eine Änderung, sodass die obige Funktion nicht mehr die korrekten Daten ermittelt? Im OSD und auch im live-Plugn wird der Name der aktuellen Sendung angezeigt, EPG-Daten funktionieren auch einwandfrei.


    Wo kann ich noch suchen?


    Danke,
    Sebi

  • Zweizeiliges Display (DM140VFD) - keine Kanalinfos mehr?

    Hallo zusammen,


    mein VDR auf Scaleo EVI-Basis hat das bekannte zweizeilige Display, was mit dem DM140VFD-Plugin angesteuert wird.


    Bisher meine ich, im Normalbetrieb Uhrzeit, Kanal und Name der aktuellen Sendung angezeigt bekommen zu haben.


    Seit einem der letzten Updates zeigt das Display in der oberen Zeile nur noch die Uhrzeit und unten den Sendernamen an. Sobald das Menü aktiviert ist, wird die aktive Menüzeile unten und oben der VDR-Status (disk usage etc.) angezeigt.


    In der Config-Seite des dm140vfd-Plugins ist die zweizeilige Ausgabe aktiv, andere Möglichkeiten, die Optionen für die Ausgabe einzustellen, habe ich nicht gefunden.


    Was habe ich übersehen? Ich nutze yavdr 0.4.


    Danke,
    Sebi

  • Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 1)

    Hallo zusammen,


    ich habe gerade meine DuoFlex CT durch eine Cine CT V6 ersetzt. Grandioses Feature für mich ist vor allem, dass ein Kabel für zwei Tuner ausreicht. Das spart zwei T-Verteiler, da ich bisher das Antennenkabel durch 2 T-Verteiler auf 2x DVB-C und 1x Analog-Tuner aufgeteilt habe,


    Allerdings habe ich an der analogen Karte jetzt eine sehr schlechte Bildqualität. Das Bild war ok, solange ich den Treiber nicht installiert hatte: nach dem Hochfahren wurde die Karte zunächst nicht erkannt, da ich v4l-dvb-dkms im Einsatz hatte. Nachdem ich das dkms-Paket deinstalliert habe und nach der Anleitung hier im Thread ddbridge & Co aus media_build_experimental gebaut habe, konnte ich ddbridge laden und vdr neu starten, sofort hatte ich ein Bild per DVB-C.


    Nur hat's dabei offenbar den Verstärker für den Antennenausgang zerrissen, das Bild der Analog-Karte sieht etwa so aus, als hätte man dem Videorecorder, der das Signal durchschleift, den Strom geklaut.


    Gibt's im DVB-Treiber irgend ein GPIO-Register, der für den Antennenverstärker zuständig ist? Ich benötige die Analog-Karte, um die grundverschlüsselten Sender ohne CI-Modul empfangen zu können...


    Sebi

  • Probleme mit WakeUp aus Standby(S3) mit Fernbedienung unter yaVDR

    Hallo,


    auch ich habe Probleme mit verschiedenen X10-Empfängern. Ein interner geht, ein weiterer interner sowie ein USB-Stick funktionieren nicht.


    Unter Windows bekommen es alle hin - es muss also gehen! Das USB-Wakeup der USB-Ports funktioniert, wenn ich den Empfänger im S3-Mode anschließe oder abziehe, wacht der Rechner auf. 5V ist ebenfalls am Port vorhanden.


    Lässt sich das wirklich nicht besser eingrenzen? Kann man irgendwelche Informationen beisteuern, die evtl. dem Treiberentwickler helfen?


    lsusb bringt - wie hier schon beschrieben - keine nennenswerten Unterscheidungskriterien. Und wie gesagt - unter Win schaffen's alle, den PC zu wecken!


    Sebi

  • yavdr 0.4 und X10 - nur jeder zweite Tastendruck wird erkannt?!

    Hallo,


    seit heute - ohne Update?! - wird bei meinem yavdr 0.4 mit X10-Fernbedienung nur noch jeder zweite Tastendruck erkannt. Dies betrifft vdr, aber auch Tools wie irw zeigt nur alle zwei Tastendrücke etwas an.


    Ich vermute, dass es etwas mit einem älteren Update zu tun hat; meine Frau hat heute den yavdr-Rechner neu gestartet, sodass Änderungen an Modulen ggfls. erst heute wirksam wurden.


    Gab es da Änderungen?


    Danke,
    Sebi

  • vdr crasht - Debug-enabled build für vdr 1.7.21?

    Hallo,


    aus verschiedenen Gründen hatte ich wieder die vdr-dbg aus dem Repository ohne Patch installiert. Trotz update-channels auf 0 und Entfernen der verdächtigen Kanäle (Pink, NRW.TV) traten wieder Abstürze auf. Heute war kein "Exotenkanal" betroffen, sondern Sat1.


    Offenbar sind es Empfangsprobleme, die sich dann in ungültigen Daten und dann in Crashes äußern.


    Sebi

  • vdr crasht - Debug-enabled build für vdr 1.7.21?

    Hallo,


    der Patch aus dem Parallelthread funktioniert offenbar doch: ich habe den Patch eingespielt und UpdateChannels wieder auf 5 gesetzt - keine Abstürze.


    Zur Kontrolle habe ich den Patch erweitert:


    if (length <= d->getDescriptorNumber()) {
    esyslog("bing!");
    return;
    }


    und tatsächlich erhalte ich in unregelmäßigen Abständen ein "bing!" im Syslog.


    Diese Zeile


    esyslog("add group descriptor: length = %d, last descriptor = %d, current descriptor = %d", length, d->getLastDescriptorNumber(), d->getDescriptorNumb


    wird übrigens nicht ausgelöst. Nachdem ich das wenig aussagekräftige "bing!" durch die Ausgabe von length und getCurrentDescriptor ersetzt habe, erhalte ich:


    Oct 18 23:13:30 dumbledore vdr: [8238] length: 1, current descriptor: 6



    Sebastian

  • vdr crasht - Debug-enabled build für vdr 1.7.21?

    Moin,


    nach dem Durchsehen des ausführlichen Backtraces habe ich PINK aus der channels.conf herausgenommen und UpdateChannels auf 0 gesetzt. Seither läuft mein vdr inzwischen 2 1/2h ohne crash.


    Der Patch aus dem Parallel-Thread bringt bei mir keine Änderung. Den von mini73 habe ich gerade eingepflegt, meine alte channels.conf wieder hergestellt und UpdateChannels wieder auf 5 gesetzt. Ich werde berichten!


    Die Zusammenfassung von steffen_b ist korrekt.


    Sebi

  • vdr crasht - Debug-enabled build für vdr 1.7.21?

    Hallo,


    mein Problem besteht noch immer. Deaktivieren sämtlicher Plugins und der Patch aus dem Parallel-Thread haben nichts gebracht.


    Ich habe die vdr-exit-other.conf mal abgeändert und den gdb-Aufruf mit "bt full" erweitert. Den letzten Backtrace hänge ich mal an.


    Was mir außerdem auffällt: die Crashes kommen pünktlich alle 9:14 min. Es muss also ein regelmäßiger Prozess sein, der immer an derselben Stelle stirbt.


    Seltsamerweise gibt es zwischendurch immer wieder Phasen, wo der vdr nicht abstürzt.


    Sebi

  • yavdr 0.4: eventlircd und Fernbedienungen - Die Grundlagen

    Zitat von TheChief

    Soweit ich das richtig verstanden habe, über die zugehörige evmap in /etc/eventlirc.d


    Da kann ich ja lange in /etc/lirc suchen für meine X10....



    Aaaber: als ich die 0.1pre installiert habe, ging die X10 mit Ausnahme der Zifferntasten (wg. anderer Schreibweise in remote.conf, AFAIR).


    Nach einigen Updates in den letzten Tagen, die mein System auf den Stand der 0.2 gehieft haben, geht


    - der Power-Button nicht mehr, irw zeigt KEY_POWER2 an, remote.conf reagiert aber nur auf KEY_POWER
    - Vol+ und Vol- sind vertauscht (remote.conf ist korrekt, irw zeigt die Buttons genau falsch herum an).


    Sebi


    Edith meint, dass ich natürlich yavdr 0.4 pre1 meinte, bei der alles funktionierte und die pre2, bei der die Vol-Tasten vertauscht und Power nicht mehr funktioniert.


    Das mit der Änderung des POWER-Knopfes habe ich gelesen. Allerdings wäre es mir lieber, den (einzigen) Power-Knopf zum vdr-Powerdown zu nutzen und nicht für eine (zumindest derzeit) nicht implementierte Power-Funktion.


    Dass man es remappen kann, ist klar, ich hielt es nur für einen Bug in der pre2.

  • vdr crasht - Debug-enabled build für vdr 1.7.21?

    Zitat von mini73

    Der meiste Code aus dem Backtrace ist aus dem disableDoubleEpgEntrys-Patch, das heißt aber nicht, das er zwingend dafür verantwortlich ist, dass die events-Liste in cSchedule zerschossen wird.
    Das könnte auch was anderes sein. Vielleicht eine Race-Condition in der Liste? Von wo aus darf AddEvent/DelEvent ausgerufen werden, gibt's da Beschränkungen? Weiß da jemand was?

    Der Patch ist es wohl nicht: ich habe mal spaßenshalber den Patch opt-38-disableDoubleEpgEntrys-Patch entfernt (patch -p1 -R). Die Abstürze bleiben, tauchen lediglich an anderer Stelle auf:


    bzw. alternativ



    oder auch:


    Code
    #0 skipspace (s=0x25 <Address 0x25 out of bounds>) at tools.h:194
194 if ((uchar)*s > ' ') // most strings don't have any leading space, so handle this case as fast as possible
#0 skipspace (s=0x25 <Address 0x25 out of bounds>) at tools.h:194
#1 isempty (s=0x25 <Address 0x25 out of bounds>) at tools.c:249
#2 0x0000000000480d41 in cEvent::Dump (this=0x7f680ac15010, f=0x7f680accf090, Prefix=0x4fd04f "", InfoOnly=false) at epg.c:450
#3 0x00000000004828e0 in cSchedule::Dump (this=<value optimized out>, f=0x7f680accf090, Prefix=0x4fd04f "", DumpMode=dmAll, AtTime=0) at epg.c:1067
#4 0x0000000000482b24 in cSchedules::Dump (f=0x7f680accf090, Prefix=0x4fd04f "", DumpMode=dmAll, AtTime=0) at epg.c:1228
#5 0x0000000000482cd3 in cSchedules::Cleanup (Force=<value optimized out>) at epg.c:1189
#6 0x00000000004e2e7d in main (argc=<value optimized out>, argv=<value optimized out>) at vdr.c:1375


    Irgendwas scheint also die epg-Daten zu zerschießen, wobei ich epg.data gestern gelöscht hatte, trotzdem tauchten die Abstürze auf.


    Seltsam ist auch, dass gestern abend - nach dem Löschen der Daten - die Abstürze nahezu im 10min-Takt auftraten. Heute hingegen ist "gespenstische Ruhe" und der vdr läuft seit mehreren Stunden. Kann es sein, dass irgendwo in den epg-Daten ein defekter Datensatz enthalten ist, der zum Absturz führt? Nur - wie finde ich den? Wenn vdr abstürzt, wird die epg.data nicht geschrieben, die Daten liegen bis dahin nur im Speicher.


    SebiXVI

  • vdr crasht - Debug-enabled build für vdr 1.7.21?

    Ahhhh...kaum macht man's richtig, schon funktionierts. Ich hatte nach einem vdr-source o.ä. gesucht, apt-get source war's, was mir fehlte.


    Danach und einem dpatch apply-all im Sourceverzeichnis konnte ich meinen vdr bauen und die vdr-dbg in /usr/bin ersetzen, ohne alle Plugins neu zu compilieren.


    Sebi

  • vdr crasht - Debug-enabled build für vdr 1.7.21?

    Danke hotzenplotz,


    das hatte ich schon gefunden und habe auch schon einen Backtrace erstellt, s.o.


    Allerdings passen zum einen meine Quellen nicht zum Backtrace - eine eit.c mit Zeile 558 bzw. 406 gibt es hier nicht, die Datei hat nur 404 Zelen.


    Außerdem habe ich den Patch aus dem Thread Segfault mit VDR 1.7.21 probieren wollen. Nachdem vdr compiliert wurde, habe ich die vdr-dbg durch die neu kompilierte Version ersetzt. Leider mögen dann die Plugins nicht mehr und beschweren sich über "unknown symbols". Muss ich tatsächlich unbedingt alle Plugins neu installieren? Anders herum (nur Plugins bauen und in /usr/lib/vdr installieren) funktioniert es doch auch?!


    Gerade aktuell sind die Crashs auf einem absoluten Höhepunkt, mehr als 10min sind nicht drin. Das war die letzten Tage anders, da kam es maximal alle paar Stunden zu einem Neustart.


    Sebi