[vdr] [ANNOUNCE] VDR developer version 1.3.39

  • VDR developer version 1.3.39 is now available at


    ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.39.tar.bz2


    A 'diff' against the previous version is available at


    ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.38-39.diff


    The changes since version 1.3.38:


    - The SVDRP command LSTT now accepts the new option 'id' to have the channels
    of the timers listed with their unique channel ids instead of their numbers
    (suggested by Matthias Schniedermeyer).
    - Added a missing #include <linux/unistd.h> to thread.c (thanks to Ville Skyttä).
    - Fixed the "plugins-clean" and "plugins-install" targets in the Makefile (thanks
    to Andreas Brachold).
    - Fixed handling "more than 3 byte" key sequences in cKbdRemote::ReadKeySequence()
    (thanks to Peter Bieringer). If you are using the PC keyboard as remote control
    input you may need to make VDR newly learn the keys by removing the remote.conf
    file.
    - To avoid problems with access rights when VDR shall run as 'root' it now skips
    all SetCaps() and SetUser() calls when it is started as 'root' and "-u root"
    is given.
    - Added missing i18n entry for the "Timer" button (thanks to Ville Skyttä)
    - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg).
    - Making the "Menu" key behave consistently has not been well received by several
    users, so the new option "Setup/OSD/Menu button closes" can be used to get the
    old behavior back (which also is the default value of this option).
    - Dropped the default vdr user. The program now always runs under the user id
    it was started from, unless the '-u' option is given and it was started from
    the 'root' user. If you want to have a default vdr user, you can activate and
    adjust the "VDR_USER = vdr" line in your Make.config file (from the original
    patch by Ludwig Nussel).
    - Key macros can now be defined for all non-modeless keys (suggested by Mirko Dölle).
    - Adjusted the "KEY MACROS" section of vdr.5 to the new plugin calling mechanism
    introduced in version 1.3.32.
    - Removed the now obsolete "ca.conf" section from vdr.1 (thanks to Ville Skyttä).
    - Added missing description of L and R circular polarization to 'diseqc.conf'.
    - Added a note about "modprobe capability" to INSTALL (suggested by Patrick Cernko).
    - Fixed canonicalizing the file name in the SVDRP command GRAB to allow full path
    names (thanks to Stefan Huelswitt).
    - Added a missing '-' to the example for viewing a grabbed image on a remote host
    (reported by Philippe Gramoullé).
    - Made the "What's on now/next?" menus a lot faster by storing a pointer to each
    channel's schedule in the cChannel data.
    - Made the log messages regarding lost lock of devices "info" instead of "error"
    (suggested by Andreas Brachold).
    - The SVDRP command GRAB allows file names without extension again (suggested by
    Stefan Huelswitt).
    - Pressing '0' in the "Schedule" menu now rotates through displaying "This event on
    this channel", "This event on all channels" and "All events on all channels".
    This can be used to find reruns of a given show, or the episodes of a series.
    Note that if there are many channels in your channels.conf, displaying the
    "All events on all channels" page may take a while.
    - The status markers in the "Schedule" menu are now only updated if a submenu is
    closed in which a timer has been modified, which speeds up closing submenus.
    - Now only writing Dolby Digital tracks into the 'info.vdr' file of a recording
    if Setup.UseDolbyDigital is true (suggested by André Weidemann).
    - Added a leading '0' to the day in the DayDateTime() function (thanks to Rolf
    Ahrenberg).
    - No longer displaying color buttons in the recording info menu if it has been
    invoked from a player (reported by Jürgen Schilling).


    Have fun!


    Klaus


    _______________________________________________
    vdr mailing list
    vdr@linuxtv.org
    http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

    Gruß
    Frodo

  • Hallo,
    auch diese Version läuft hier wieder wunderbar, nur
    stören mich seit der 1.3.38'er Version folgende
    Meldungen beim compilieren.

    Code
    dev-system:/vdr/vdr-1.3.39-eis# make
    In file included from /usr/include/linux/fs.h:12,
                     from /usr/include/linux/capability.h:17,
                     from /usr/include/sys/capability.h:24,
                     from vdr.c:34:
    /usr/include/linux/wait.h:4: warning: `WNOHANG' redefined
    /usr/include/bits/waitflags.h:26: warning: this is the location of the previous definition
    /usr/include/linux/wait.h:5: warning: `WUNTRACED' redefined
    /usr/include/bits/waitflags.h:27: warning: this is the location of the previous definition


    Wie Sieht das damit aus, kann ich das irgnorieren, oder sollte man etwas dagegen machen?

  • Meine Verehrung geht wie immer an den Chef :)


    Da kann ich morgen wieder ne neue Version drauf hauen ;)




    I30R6










    VDR











    Hardware : GA-EP35-DS3L, C2Q Q6700 , 3GB DDR2 , Palit GT240, 250GB System & 500GB Video,
    Mystique-CaBix C2,TT Budget C-1501,Airstar 2, Fernbedienung X10
    Software : gen2vdr, Kernel 3.8.10, vdr 2.0.1
    PlugIns : audiorecorder,femon,admin,yacoto..
    Ausgabe: softhddevice

  • Hi!


    maverick: So wie es aussieht ist dies Meldung aber von anderen Includes. Ich denke nicht dass da Klaus was dagegen machen kann.


    Gruß,
    Brougs78

    - -- --- ================================================================ --- -- -
    Antec Fusion, Intel E5200, Asus P5N7A-VM (VDPAU), DD CineS2 v6 + DD DuoFlex CI // yavdr-0.6.1
    - -- --- ================================================================ --- -- -

  • Brougs78


    Denk ich mir auch, aber ich hab halt gedacht vielleicht weiß ja jemand worans leigt und hat nen Vorschlag. Bis jetzt sinds ja "nur" Warnings.


    Wird aber auch an den Uralt Versionen des gcc, der glibc und dem Kernel liegen. achso, gibts eigendlich ne neuere Version von libcap? Hab hier nur ne Uralt Version gefunden.

  • Hallo,



    Ein "Bug" ist in der neuen VDR Version enthalten:
    Wenn in der Datei keymacros.conf auf ein Plugin verwiesen wird, dieses aber nicht beim VDR Start geladen wird, "flutet" VDR das SysLog mit "ERROR: unknown plugin xxx" Meldungen!
    Innerhalb weniger Minuten hatte ich mehr als 1 Million Meldungen.
    Ich hatte Klaus heute morgen deswegen bereits angemailt.


    Bye,
    Frank


  • Hier der Fix:




    Klaus

  • Hallo,


    ich habe immer noch ein Problem mit zwei CAMs (Alphacrypt) an zwei FFs.
    Auf einer Karte ist Premiere, auf der anderen Kabel Deutschland freigeschaltet.
    Wenn ich den VDR die CA-Einstellungen der Sender erkennen lasse, kann ich nur die Sender entschlüsseln, die an der primären FF freigeschaltet sind.
    Bei Aufnahmen nimmt der VDR zuerst die sekundäre Karte und kann dann die Sender der primären natürlich nicht entschlüsseln.
    Ich hatte gehofft, dass mit der Implementierung des dynamischen CA-Handlings diese Problem gelöst ist.
    Als Workaround hatte ich die einzelnen Kanäle den beiden Karten zugewiesen. Dann habe ich allerdings das Problem, dass der VDR sporadisch neu startet (was sich in der Aufnahme nicht so gut macht :( ). Außerdem werden bei einer Aufnahme alle Kanäle auf demselben Transponder entschlüsselt und das führt beim Zappen zu Störungen in der Aufnahme (Klaus hatte das ja auch geschrieben).


    Gibt es noch eine andere Lösung, oder wird an den Problem gearbeitet?


    Gruß,
    Andree

  • Zitat

    Original von AKA
    Hallo,


    ich habe immer noch ein Problem mit zwei CAMs (Alphacrypt) an zwei FFs.
    ...


    Das Hauptproblem ist, daß die CAMs der Applikation (VDR) _alle_ Verschlüsselungsarten mitteilen, die sie können - nicht nur die, die mit der eingesteckten Smartcard tatsächlich möglich sind. Da hilft auch die QUERY-Funktion nicht viel weiter, da diese nur von den wenigsten CAMs tatsächlich implementiert wird, und auch dort oft fehlerhaft ist. Beim AlphaCrypt mit Firmware 3.05 beispielsweise führt ein QUERY zum sofortigen Decrypten des angefragten Kanals, obwohl es das laut Standard nicht soll. Schaltet man dann bei laufender Entschlüsselung eines Kanals einen weiteren dazu, so kommt es bei dem bereits entschlüsselten zu Störungen, die es aber laut Standard nicht geben darf. Am 15. November 2005 hatte mir jemand von Mascom mitgeteilt, daß diese Fehler verbessert werden, aber soweit ich weiß, gibt es noch keine neuere Firmware-Version für das AlphaCrypt CAM.


    Somit bleibt also nur die Möglichkeit, tatsächlich zu versuchen ob ein bestimmter Sender von einem bestimmten CAM entschlüsselt werden kann, was die Sache natürlich etwas aufwendig macht. Für die Version 1.4 werde ich da nichts mehr machen, aber hoffentlich danach...


    Klaus

  • Zitat

    Original von kls
    Für die Version 1.4 werde ich da nichts mehr machen, aber hoffentlich danach...


    Klaus redet in letzter Zeit auffällig oft von Version 1.4 ... :D


    Das lässt ja mal hoffen...

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!