[ANNOUNCE] VDR developer version 1.3.44

  • Von: Klaus Schmidinger
    An: ML
    Datum: Heute 17:08:13

    VDR developer version 1.3.44 is now available at


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


    A 'diff' against the previous version is available at


    ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.43-44.diff







    *** IMPORTANT NOTE **************************************************
    *** ***
    *** This version changes the handling of the "summary" and "flag" ***
    *** fields in timer definitions. So in case you are using an ***
    *** external tool for programming timers, which uses that field, ***
    *** please wait until the author of that tool has adapted it to ***
    *** the new handling. ***
    *** ***
    *********************************************************************







    The changes since version 1.3.43:


    - Fixed setting the audio language codes in 'Transfer-Mode' (reported by Rolf
    Ahrenberg). The actual problem was the call to the Transferring() function in
    cDevice::AttachPlayer() before assigning the player.
    - Fixed removing the '-' when entering a channel number where there is no other
    one that fits the input (thanks to Joachim Wilke).
    - Fixed the 'libsi' function CharArray::checkSize(), which made a previous workaround
    in libsi/descriptor.c obsolete (thanks to Marcel Wiesweg).
    - The "Ok" key in the "Jump" mode of the replay progress display now confirms the
    jump instead of closing the display (thanks to Christoph Haubrich).
    - The 'summary' field of a timer definition has been renamed to 'aux', and is now
    only used for external applications to store auxiliary information with a timer,
    which has no meaning whatsoever to VDR itself.
    The contents of the 'aux' field of a timer is copied into the recording's
    'info.vdr' file, using the tag character '@'.
    - The description of a recording is now taken exclusively from its related EPG
    data. If an application wants to use a different description it needs to set
    it with SVDRP/PUTE and use table ID 0x00, so that it won't be overwritten (as
    a side effect, however, this also disables VPS for such an event).
    - There is no more "Summary" menu when pressing "Ok" in the "Timers" menu.
    The "Ok" key now always opens the "Edit timer" menu.
    - The upper 16 bit of a timer's "flags" are no longer treated specially when a timer
    is modified in the "Edit timer" menu. If an external application needs to know if
    a timer was modified, it has to keep a copy of the timer's data and compare that
    to the actual data.
    - The new function cRecordingInfo::ChannelID() can be used to retrieve the ID of
    the channel a recording was made from.
    - The 'info.vdr' file of a recording now also contains the 'E' and 'V' records of
    the EPG event used when creating it.
    - The option "Setup/OSD/Sort timers" has been removed. Timers are always sorted
    by their start time and priority.
    - The "Blue" key in the "Timers" menu now displays the EPG info of the event the
    selected timer will record (if available). The "On/Off" function has been shifted
    to the "Red" button. Editing a timer is done by pressing "Ok".
    - When determining which event a timer is going to record, all available events
    in the future are now taken into account (no more limit to 4 hours in the
    future). This has been done so that the event info is available in the "Timers"
    menu when pressing the "Blue" button. In order to avoid unnecessary work, each
    timer now has its own timestamp to control whether its schedule has changed
    since the last time its event has been set.
    - Fixed setting events to timers in case a non-VPS event has expired.
    - There is now a log message "timer ... set to event ..." when defining a timer
    from the EPG menu.
    - Lines tagged with '#' in the 'info.vdr' file of a recording are now silently
    ignored when reading that file (suggested by Peter Bieringer). Such lines can
    be used by external tools to store arbitrary information.
    - The 'event id' in EPG data has been extended to 32 bit, so that external tools
    can generate ids that don't collide with those from the DVB data stream
    (suggested by Matthias Schniedermeyer).
    - The DrawBitmap() function now has a new parameter 'Overlay' that allows a bitmap
    to be drawn with a transparent background (thanks to Alexander Hans).
    - Fixed cSchedule::GetFollowingEvent() in case there is currently no present event
    running (thanks to Pekka Mauno).


    Have fun!


    Klaus


    :modon  Django -> wenn dann richtig bitte! :modoff Dirk
    (Editiert)


    :evil: Nichts ist wahr, alles ist erlaubt! :evil:


    VDR-Server: ASUS A7V8X, Duron 1.300, 256 MB, 3x 120 GB Maxtor HD, PIONEER DVR-106, Design Tower AIR Black, 40x4 LCD,
    1x TT-DVB-S V1.6, 3x DVB-S Nova, URC-7562, CentOS 5.5, VDR: 1.6.0


    TecVDR: AOPEN MK73LE-N, Duron 1.300, 256 MB, 1x 120 GB Samsung HD, Pioneer DVR-A04, Gehäusesonderbau, 1x TT-DVB-S V1.6 4MB, 1x DVB-S Nova, 1x AV-Board, SuSE 9.0, VDR: 1.3.11

    Einmal editiert, zuletzt von Django ()

  • Django


    Das nächste mal bitte Ordentlich!

    Dirk

  • Danke für die neue Version!


    Und das hier:

    Zitat

    - The "Blue" key in the "Timers" menu now displays the EPG info of the event the
    selected timer will record (if available). The "On/Off" function has been shifted
    to the "Red" button. Editing a timer is done by pressing "Ok".


    ist doch mal wieder eine wirklich sinnvolle Änderung! Mir ist es bei gut ausgelastetem VDR ein paar mal passiert, dass ich ausgerechnet *den* Timer, den ich kontrollieren wollte, weil er mir *besonders* wichtig war mit einem doppelten Druck auf die blaue Taste deaktiviert habe und so ein schönes Loch in der Aufnahme hatte. Seitdem meide ich die blaue Taste für die Timer eigentlich wie der Teufel das Weihwasser. Kann ich mir demnächst wohl wieder angewöhnen :D


    Gruß,
    Holger

  • Habe hier leider, wie seit 1.3.42 schon, bei


    Einstellungen -> DVB -> Ok


    einen Crash des VDR.


    runvdr up bringt folgendes:


    /etc/init.d/runvdr: line 201: 1876 Segmentation fault $BINDIR/vdr -L $PLUGINDIR $PLUGINS $COMMON_PARAMETER -v /video0 -c $CONFDIR -w 900 -E /ramdisk/epg.data -s /usr/bin/poweroff.pl -r /usr/bin/noadcall.sh </dev/tty$VDRTTY


    Umgebung: LINVDR 0.7, plain vanilla 1.3.44, keinerlei Patches oder Plugins


    Keinerlei Einträge im logread


    Uli


  • Hab's probiert, bei mir passiert da aber nichts.


    Klaus

  • Hallo,
    ich habe auch mit dieser Version ein Problem. Nach dem Booten steht das Bild. Umschalten ist möglich, aber der neue Sender steht erneut. Die 1.3.41 Version läuft bei mir tadellos.


    Der Syslog zeigt folgendes:


    Feb 26 18:26:09 localhost vdr: [4542] ERROR (transfer.c,92): Invalid argument
    Feb 26 18:26:09 localhost last message repeated 3726 times
    Feb 26 18:26:09 localhost vdr: [4543] buffer usage: 80% (tid=4542)
    Feb 26 18:26:09 localhost vdr: [4542] ERROR (transfer.c,92): Invalid argument
    Feb 26 18:26:10 localhost last message repeated 3867 times
    Feb 26 18:26:10 localhost vdr: [4543] buffer usage: 90% (tid=4542)
    Feb 26 18:26:10 localhost vdr: [4542] ERROR (transfer.c,92): Invalid argument


    Hat jemand eine Idee? Hardware siehe Signatur.


    Mfg
    Holger

    HW: Asrock K7VM2 Hauppauge Nova-T (FW 2.16)RealMagic Hollywood Plus Karte
    Gehäuse: Antec CUBE CASE ARIA
    SW: SuSE 11.0 mit Kernel 2.6.33 VDR-1.6.0 mit dxr3-0.2.9, osdteletext und graphlcd Plugin
    em8300 Module: Version 0.18.0

  • Das mit der DVB Teil tritt auf wenn in der setup.conf bei der Senderaktualisierung ein ungültiger Wert steht.

    TV VDR: GigaByte 965DS3, Intel C2D 2,4GHz, 1GB RAM, HD Ext, 2x TT PCI S-3200 DVB-S2, ATI Radeon HD2600, VDR 1.6.0-HDTV, Gentoo 2007.1, Kernel 2.6.24
    TV VDR: AOpen 945 GTM-VHL, Intel C2D-M 1,83GHz, 2GB RAM, HD Ext, 1x TT PCI S-3200 DVB-S2, Intel GMA950, VDR 1.6.0-HDTV, Gentoo 2007.1, Kernel 2.6.24
    VDR Server: Supermicro 370DE6, 2x Intel P3 866 MHz, 2GB RAM, TT-DVB-s Rev. 1.3, TT S1100 budget, KNC1 budget, TT S1401, 2x 500GB WD HDs, 1x 9GB U160 SCSI

  • Zitat

    Original von Konni__
    Das mit der DVB Teil tritt auf wenn in der setup.conf bei der Senderaktualisierung ein ungültiger Wert steht.


    Das erklärt es natürlich, denn in cMenuSetupDVB wird dieser Wert als Index in ein Array von (char *) benutzt. Da muß ich wohl in cMenuEditStraItem::cMenuEditStraItem() eine Prüfung einbauen...


    Klaus

  • Hallo ferdi03,


    da du eine dxr3 hast und wahrscheinlich nicht das dxr3-plugin gepatcht hast, schau mal hier rein.
    http://www.vdr-portal.de/board…?postid=356853#post356853


    Der Vdr Patch ist ab 1.3.42 nicht mehr nötig!


    bis dann LordZodiac


    Vdr1: vdr-1.7.0 HDe, Nexus 2300-S und TT S2-3200
    Vdr2: vdr-1.4.7 Nexus CA, Terratec Cinergy 1200s
    Plugins: dvd-0.3.6b03+, femon-1.1.3
    System: Suse 9.1 Kernel 2.6.28


    Testkarten: Dxr3, Hauppauge DVB-c 2.1, Terratec Cinergy 1200c, Nova-t
    Alphacrypt Light 3.11
    AMD Sempron 2400+ 512MB Epox 8RDA3I Pro
    Pentium III 384MB BX440
    Panasonic SA-XR 15 EG-S :)

  • HI Ossiostborn! :mua


    Zitat

    Original von Dirk
    Das nächste mal bitte Ordentlich!


    JAWOLL! :bpl


    cu,
    BC


    :evil: Nichts ist wahr, alles ist erlaubt! :evil:


    VDR-Server: ASUS A7V8X, Duron 1.300, 256 MB, 3x 120 GB Maxtor HD, PIONEER DVR-106, Design Tower AIR Black, 40x4 LCD,
    1x TT-DVB-S V1.6, 3x DVB-S Nova, URC-7562, CentOS 5.5, VDR: 1.6.0


    TecVDR: AOPEN MK73LE-N, Duron 1.300, 256 MB, 1x 120 GB Samsung HD, Pioneer DVR-A04, Gehäusesonderbau, 1x TT-DVB-S V1.6 4MB, 1x DVB-S Nova, 1x AV-Board, SuSE 9.0, VDR: 1.3.11

  • Hallo,


    @Klaus
    der höhere Wert der Variablen wird durch den OnlyPID Patch verursacht. Das ganze ist also kein Fehler von "Vanilla" VDR, den du abfangen müsstest ;)




    Neues von der "Plugin Front": epgsearch, tvtv & vompserver funktionieren zur Zeit nicht mehr mit der neuen VDR Version. Sind jetzt "nur" noch 198 compilierte Plugins ;)


    Bye,
    Frank

  • Hi,


    also ich bin von vdr 1.3.37 direkt auf 1.3.4x umgestiegen. Jetzt habe ich ab und an das Problem, das manchmal, wenn die MinUserInactivity abgelaufen ist die Zeitspane bis zum Ablauf der nächsten MinUserInactivity bei 5 Minuten "hängt". Im OSD ist die aber die korrekte Zeit aufgeführt.
    Für mich sieht das so aus, als wenn dann für die Zeit fälschlicherweise die 5 Minuten bis zum automatischen Ausschalten eingesetzt werden.


    Auf den VDR wurde der BP von Frank99 angewandt. Vielleicht kann mir ja jemand nen Tipp geben...

    HD DVB-C System / Ubuntu 14.04 x64 / Kernel 3.13.0-48 x64; VDR 2.2.x; VDRadmin 3.6.10 / ACPI Wakeup

    SoftHD-Device GIT / Vdpau / Nvidia 337.25

    ASUS AT5IONT-I; Atom D525; 4GB; Nvidia GT218; 1x DD Cine C/T v6; 1x DD DuoFlex C/T v2; (20~40 Watt)

  • Zitat

    Original von Frank99
    Hallo,


    @Klaus
    der höhere Wert der Variablen wird durch den OnlyPID Patch verursacht. Das ganze ist also kein Fehler von "Vanilla" VDR, den du abfangen müsstest ;)


    Ein Programm sollte im Prinzip nie abstürzen, wenn wo auch immer ungültige Werte stehen.

  • clocker


    Danke, das hatte ich nicht mitbekommen. Ich werde mal sehen wie sich das in der 1.3.43 bzw. 1.3.44 verhällt.

    HD DVB-C System / Ubuntu 14.04 x64 / Kernel 3.13.0-48 x64; VDR 2.2.x; VDRadmin 3.6.10 / ACPI Wakeup

    SoftHD-Device GIT / Vdpau / Nvidia 337.25

    ASUS AT5IONT-I; Atom D525; 4GB; Nvidia GT218; 1x DD Cine C/T v6; 1x DD DuoFlex C/T v2; (20~40 Watt)

  • Hallo,

    Code
    - The "Blue" key in the "Timers" menu now displays the EPG info of the event the
    selected timer will record (if available). The "On/Off" function has been shifted
    to the "Red" button. Editing a timer is done by pressing "Ok".


    wenn ich eine geplante Aufnahme in Timer per EIN/AUS deaktiviere, verschwindet hier der Info Button, soll das so sein ?
    mfg

Jetzt mitmachen!

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