Posts by torsten lang

  • Probleme der S2-6400 - Archiv

    Quote from FireFly

    Ich muss nochmal hierauf zurückkommen, nachdem ich gestern auf aktuelle Treiber, Firmware und hddvbdevice upgedated habe trat das Problem schon zweimal auf. Beim zweiten Mal konnte ich nicht booten weil grade eine Aufnahme lief. Als ich dann ca. 90 min später booten wollte, gabs wieder ein OSD (habe trotzdem gebootet).


    Hallo zusammen,
    ich hänge mich da auch nochmal dran. Bei mir gibt's da verschiedene Ausprägungen: Zeitweise (und ziemlich unmotiviert - ich habe es jedenfalls bisher nicht an bestimmten Aktionen festmachen können) läßt sich der VDR per FB einfach überhaupt nicht mehr bedienen. Oft (nicht immer) berappelt sich die Geschichte dann nach einiger Zeit (kann schon mal 'ne Minute sein). Interessant dabei: Bei dieser Form von Totalverweigerung läßt sich der VDR aber sehr wohl noch per Live-Plugin "verarzten", d. h., daß z. B. das Starten der Wiedergabe einer existierenden Aufnahme auf diese Weise funktioniert und die Blockade auch löst.

    "OSD weg, aber VDR bedienbar" habe ich bei mir in dieser Form nicht (verwende den TNG mit High-Level OSD), aber den Effekt, daß nur noch der Hintergrund gezeichnet wird, nicht mehr aber der Text. Die Reaktionsgeschwindigkeit auf FB-Aktionen läßt sich dann auch eher in gefühlten geologischen Zeiträumen ermitteln.

    Viele Grüße,
    Torsten

  • [gelöst] Keine Umlaute und vdradmin-am nach Upgrade auf Squeeze

    Quote from WWW-KR

    Gibt es keinen anderen Weg dieser Problem aus der Welt zu schaffen? Wenn es wirklich an dem Paket von e-Tobi liegt, wieso melden sich dann nicht mehr Personen mit diesem Problem?


    Moin WWW-KR,
    zum ersten Punkt: Ja klar - UTF8 verwenden (und ggf. alle alten Aufnahmen "anfassen").
    zum zweiten Punkt: Es liegt nicht an e-Tobis Paket, sondern an der nicht einwandfrei arbeitenden fribidi-Bibliothek.

    Mittlerweile ist UTF8 auf neuen Installationen eigentlich Standard, daher darfst Du wohl kaum mit allzuvielen Rückmeldungen rechnen. Betroffen sind hauptsächlich Anwender, die aus bestimmten Gründen eben weiterhin ISO8859 verwenden.

    BTW - wenn Du eine Entwicklerversion verwendest, solltest Du auch etwas Bereitschaft mitbringen, mal ein Paket selbst zu compilieren. Debian macht es einem ja auch nicht allzu schwer, zumindest, solange Du einfach nur ein bestehendes Paket neu bauen mußt.

    Da ich ein fertiges Paket habe, kannst Du das natürlich mal ausprobieren. Ich hab's auf meine HP gelegt, unter http://tlang.dyndns.org/vdr_1.7.22-1~ctvdr2_i386.deb kannst Du's runterladen und ausprobieren (sprich mit dpkg -i <Paketname> installieren). Und bitte mal Rückmeldung geben.

    Gruß,
    Torsten

  • [gelöst] Keine Umlaute und vdradmin-am nach Upgrade auf Squeeze

    Hallo WWW-KR,
    ich kann Dir wahrscheinlich eine Lösung anbieten - bei meinem HD-VDR hatte ich auch mit dem Problem gekämpft: Die Ursache ist die BIDI-Bibliothek, die im e-Tobi/c't-VDR standardmäßig aktiviert ist. Entweder kommentierst Du in Make.config (wird über einen der Patches erzeugt) die Zeile

    Code
    BIDI = 1


    aus, was mein erster Workaround war oder Du nimmst den folgenden Patch, den mir Klaus kürzlich gemailt hat (hier mein Patchfile aus debian/patches):


    Wenn es mit dem Patch klappt, schick' doch bitte Klaus auch nochmal 'ne Bestätigung.

    BIDI ist für Sprachen gedacht, wo von rechts nach links ausgegeben wird. Dabei versucht die BIDI-Library UTF8-Sequenzen anzupassen und bearbeitet fälschlich auch ISO8859-1 Sonderzeichen. Ohne BIDI gibt es bei ISO8859-1 keine Probleme.

    Viele Grüße,
    Torsten

  • [ANNOUNCE] Extended EPG Plugin 0.0.2

    Hello Lucian,
    sorry, I retrieved an archieve from some other source. Although I did protocol the steps to setup special extensions of my HD VDR unfortunately I haven't the source of this file at hands. So here is the archive of the source code I used for my patches. It seems that it contains various patches and restructuring not in the GIT version, and also a lot of additional log code.

    I will try to find out where I got this archive from...

    Addition 20110109: I think I retrieved it from the files section of vdr-developer.org, but the original file seems to be deleted...

    With kind regards,
    Torsten

  • Probleme der S2-6400 - Archiv

    Hallo Firefly,
    also, meine Fernbedienung ist an einer noch vorhandenen SD FF Karte angeschlossen, da Gehäuseausschnitte für das AV-Board vorhanden sind und auch der IR-Empfänger fest im Gehäuse eingebaut ist. Trotzdem habe auch ich diese FB-Probleme bzw. teilweise unmotivierte Zwangspausen, wo sich dem VDR auch mal 30s lang überhaupt keine Reaktion per FB entlocken läßt. Interessanterweise reagiert aber in diesen Zeiten - wenn ich das richtig in Erinnerung habe (ich muß demnächst nochmal genauer drauf achten) aber das VDR Live Plugin noch ganz normal.

    Gruß,
    Torsten

  • Probleme mit dem EPG bei VDR 1.7.21

    Niemand? Für meinen Teil habe ich's eingrenzen können und den Sender, der mit seinen fehlerhaften EPG-Daten zur Zerstörung der epg.data Datei führt, auf die Blacklist gesetzt. Damit ist das eigentliche Problem noch nicht gelöst, aber erstmal umschifft, bis der VDR die fehlerhaften Daten sauber ausfiltert...

    Nachtrag 2012-01-10: Klaus hat mir mitgeteilt, daß er das Problem hat reproduzieren können und es in der nächsten VDR-Version gefixt sein wird.

    Gruß,
    Torsten

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

    Hallo Oliver,
    weißt Du, ob sich Pfade der Treiber geändert haben? Wenn ja, wäre es natürlich möglich, daß da noch alte Kopien vorhanden und bevorzugt geladen wurden. Jedenfalls war das Problem nach "make install" und "reboot" aufgetreten, danach waren die alte FF und die PVR350 weg und das Laden des Moduls schlug mit genannter Meldung fehl.

    Ich teste es nochmal aus.

    Nachtrag 2012-01-04:

    Anscheinend waren da tatsächlich Reste der alten Installation übrig. Jetzt klappt's und das Ent- und Neuladen des S2-6400 Treiber klappt mit dem neuesten Stand auch endlich ohne Kernel Panic.

    Viele Grüße,
    Torsten

  • [ANNOUNCE] Extended EPG Plugin 0.0.2

    Hello to all,
    I will bring this thread up again because I have crashes that seem to be caused by EEPG. Typically the crashes happen most of the time when watching recordings although that shouldn't have any influence (I have a four tuner system, so most of the time more than one DVB device is free), but at least anoter free DVB device may intensify the problem.

    I have a very strong suspicion what is going wrong here. Because I don't know the VDR and the plugin's source in detail can anyone check on this?

    When analysing the log files I found the following:

    vdr.log:

    syslog:

    Code
    Jan  3 23:32:01 tuxbox2 /USR/SBIN/CRON[10532]: (root) CMD (test -x /usr/bin/cardserverwatch && /usr/bin/cardserverwatch)
Jan  3 23:32:24 tuxbox2 kernel: [25747.319946] demux_worker: called but nothing to do
Jan  3 23:32:34 tuxbox2 kernel: [25757.829968] section handler[6340]: segfault at c ip b75cc649 sp b07f7320 error 4 in libc-2.11.2.so[b755c000+140000]
Jan  3 23:32:34 tuxbox2 kernel: [25757.994892] saa7146: unregister extension 'av7110'
Jan  3 23:32:34 tuxbox2 kernel: [25758.054687] av7110 0000:03:02.0: PCI INT A disabled

    As the code loads both freesat tables immediately one after another there should be no other operations logged in between, just like this:

    Code
    Jan  1 06:48:01 tuxbox2 vdr: [2089] EEPG: NagraGuide Extended EPG detected on pid f02.
Jan  1 06:48:01 tuxbox2 vdr: [2089] EEPG: Loading table 1 Filename </var/lib/vdr/plugins/eepg/freesat.t1>
Jan  1 06:48:01 tuxbox2 vdr: [2089] EEPG: Loading table 2 Filename </var/lib/vdr/plugins/eepg/freesat.t2>
Jan  1 06:48:01 tuxbox2 vdr: [2086] Process:3411 EEPG: Pid: 0x00 Tid: 0 Length: 88 PMT pid: 0x010c


    IMHO this is a must because the load_file() function reallocates entries in the global huffman table "tables". As these are global instead of member variables the entries must never be changed while another thread is accessing it.

    But what I observe at several other points in the log is something like that:

    Code
    Jan  1 06:48:01 tuxbox2 vdr: [2086] EEPG: NagraGuide Extended EPG detected on pid f02.
Jan  1 06:48:01 tuxbox2 vdr: [2086] EEPG: Loading table 1 Filename </var/lib/vdr/plugins/eepg/freesat.t1>
Jan  1 06:48:01 tuxbox2 vdr: [2089] Process:3411 EEPG: Pid: 0xf02 Tid: 97 Length: 328 PMT pid: 0x0000
Jan  1 06:48:01 tuxbox2 vdr: [2086] EEPG: Loading table 2 Filename </var/lib/vdr/plugins/eepg/freesat.t2>
Jan  1 06:48:01 tuxbox2 vdr: [2086] EEPG: Filter Pid:f02,Tid:4e,Mask:fe added.


    or that:

    So what I observe here is that concurrent processes access (and modify) these tables like in the crash situation where two load operations seem to be done simultaneously. This is bad, really bad. The realloc in load_file may move around the memory blocks anytime, what if an access to these tables is interrupted, then the memory is moved and the original block freed? Well, accesses to unallocated memory may occur which would lead to segmentation faults!

    What I do not understand is why at all these tables are reloaded all the time because as far as I understand the code the only changes done to these tables are done by load_file(). So it should be sufficient to load the tables once at startup and then only do read accesses to them.

    I have not analysed the behaviour regarding the other files read because there is separate and totally different code reading them.

    Please let me know if I'm right. If yes, I fear we need major changes to avoid these crashes caused by multitasking :wow :wow :wow

    Addition 2012-01-04:

    I also would expect the plugin to have major memory leaks due to reloading and reloading the tables again without freeing the allocated memory. I have done an emergency fix for the table handling - tables will now load ONCE at start of the plugin as they will never change during run time. Nevertheless there still are some global variables like e. g. some date information which will be changed inconsistently.

    As there also seems to be a lot of redundance (e. g. separate huffman table structures and decoders for freesat and sky) I would suggest to do a rewrite from scratch by using the functional code but unifying duplicate code fragments and making the whole thing multitasking safe as the filter can (and WILL) operate in parallel on different DVB devices.

    Addition 2 2012-01-04:

    I have attached the patch with my emergency repair. Please check if the EPG still works completely with my changes and if it solves the problem with the crashes.

    Regards,
    Torsten

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

    Hallo Oliver,
    leider habe auch ich ein Problem mit dem aktuellen Stand. Der make läuft durch, allerdings funktionieren meine alten Karten nun überhaupt nicht mehr (PVR350, TT FF 2300). Fehlermeldung z. B. bei der FF:

    FATAL: Error inserting dvb_ttpci (/lib/modules/2.6.39-bpo.2-686-pae/kernel/drivers/media/dvb/ttpci/dvb-ttpci.ko): Invalid argument

    Der Kernel ist derselbe 2.6.39, mit dem vor einigen Monaten noch alles lief.

    Was könnte da los sein?

    Viele Grüße,
    Torsten

  • Probleme mit dem EPG bei VDR 1.7.21

    Moin zusammen,
    ich habe mit dem VDR 1.7.21 ein Problem mit den EPG-Daten. Der VDR trägt zwar fleißig Daten zusammen. Beim Hochfahren ist der vom VDR angezeigte EPG aber komplett leer und füllt sich, ausgehend vom gerade aktiven Bouquet und dem Background-Scan, erst langsam wieder, d. h. die Cache-Datei wird anscheinend nicht oder nicht korrekt eingelesen.

    Lege ich die Datei neu an, starte den VDR, warte ca. 10min. bis er die aktuell zusammengetragenen Daten gespeichert hat, und starte ihn dann neu, klappt es meist. Die Datei ist dann allerdings sehr viel kleiner.

    Zum Test: Eingestellt habe ich den Live-TV-Kanal auf DMAX. Weiterhin habe ich ein Backup der EPG Cache Datei (ca. 30MB groß, die Datei enthält für die getesteten Sender definitiv aktuelle EPG-Daten). Die EPG-Daten checke ich entweder per Live-Plugin oder auch direkt per OSD. Wenn ich den VDR stoppe, die aktuelle epg.data gegen die gesicherte epg.data ersetze und den VDR wieder starte, dann ist der EPG z. B. für die Öffentlich-Rechtlichen leer. Nehme ich stattdessen die nach ca. 10min. neu angelegte Datei, dann ist der EPG gefüllt. Ich habe dann mal etwas gewartet, bis die Datei weiter gefüllt war, und den VDR wieder neu gestartet. Ergebnis: EPG wieder leer!

    Aufgrund der vier SAT-Positionen und der dadurch resultierenden vielen Sender wächst der EPG-Cache auf ca. 30MB.

    Der VDR ist im Wesentlichen der von e-Tobi bereitgestellte, wegen des DVBHDDEVICE-Plugins muß ich aber selbst compilieren. Weiterhin ist wegen der englischen Sender auf 28,2°E noch das EEPG-Plugin installiert.

    Hat irgendwer eine Idee hierzu?

    Viele Grüße,
    Torsten

  • Probleme der S2-6400 - Archiv

    Hallo,
    was für Klimmzüge muß man denn überhaupt machen, daß das zusammenspielt? Daß das dvbhddevice noch gepatcht werden muß, davon wußte ich bisher nichts...

    In der Kombination switcht der VDR jedenfalls immer auf Frontend 5 (PrimaryDVBDevice=5), und dann gibt's kein OSD und nichts mehr...

    Gruß,
    Torsten

  • Probleme der S2-6400 - Archiv

    Quote from Freddy

    Kann mir jemand bitte erklären, was die vor- und Nachteile von den beiden (oder sind es drei?) IRQ-Typen sind? In der Anfangsphase ist mein Rechner ohne int_type=1 auch komplett eingefroren, daher verwende ich im Moment 1. Sollte ich den Parameter wieder löschen? Kann man überhaupt eine pauschale Aussage machen, dass IRQ-Typ X besser ist? Oder ist das Hardware-abhängig? :rolleyes:
    Danke und Grüße,
    Freddy


    Hallo Freddy,
    soweit ich mich erinnere gibt es zwei Arten, die Interrupts auszulösen: Über eine der Hardware-Interrupt-Leitungen im jeweiligen Slot (bei PCI normal INT#A - ich weiß aber nicht, wie das mit den HW-Interrupts bei PCIe ist) oder als Message über den PCI-Bus. Bei Letzterem braucht's aber weitere Voraussetzungen wie den APIC.

    Nach dem, was ich bisher überflogen habe, ist die Variante per PCI-Message etwas schneller, ein weiterer Vorteil ist, daß auf diesem Weg mehr Interrupts zur Verfügung stehen und die Karte dann i. d. R. ihren Interrupt exklusiv bekommt.

    Wenn also int_type=1 unterstützt wird, ist das wohl die etwas bessere Methode.

    Viele Grüße,
    Torsten

  • Probleme der S2-6400 - Archiv


    Hallo Falk,
    hallo wtor,
    was mich mal interessieren würde - welche Treiber benutzen denn den Interrupt der S2-6400 bei euren Systemen noch mit? Dazu darf der Treiber - wenn ich den Code richtig verstehe - aber nicht mit int_type=1 geladen werden, weil er dann den Interrupt exklusiv nutzt.

    Also meine Bitte: Modul mal ohne int_type Option laden und unter /proc/interrupts nachschauen, was da alles drauf hängt.

    Bei mir macht ein gleichzeitig installierter PVR350 Framebuffer-Treiber auf demselben Interrupt Probleme, der Absturz tritt aber im S2-6400-Treiber auf.

    Viele Grüße,
    Torsten

  • Probleme der S2-6400 - Archiv

    Quote from torsten lang

    Hallo Falk,
    tja, wie gesagt, int_type=1 funktioniert bei meinem Board überhaupt nicht, die Karte selbst läuft ansonsten mit den Standard-Einstellungen aber absolut stabil.

    Was mich aber wundert - wie soll man diese Seite nur finden? Von der Hauptseite über die S2-6400 scheint sie überhaupt nicht verlinkt zu sein...

    Viele Grüße,
    Torsten


    Hallo zusammen,
    beim Experimentieren (mit dem ganzen PC-Geraffel geht das anscheinend wohl nicht anders) bin ich zumindest drüber gestolpert, daß es nur dann kracht, wenn auch noch der FB-Treiber für die PVR350 geladen ist (benutzt denselben Interrupt). Entlädt man den vorher, läßt sich der Treiber ohne Probleme neu laden, danach kann dann auch der ivtvfb wieder geladen werden.

    Viele Grüße,
    Torsten