[ANNOUNCE] VDR developer version 2.3.6

  • HowTo: APT pinning

    Dieser Beitrag wurde bereits 4 Mal editiert, zuletzt von fnu ()

  • Hallo Klaus,


    vielen Dank für die neue Version.


    Regards
    Frank

    HowTo: APT pinning

  • Hi,


    da geht man einmal ein Stündchen aus dem Haus und schon gibt es eine neue VDR Version ;D


    Danke Klaus für die neue Version.

    Gruß MegaX


  • --obwohl
    ++weil



    >> Added checking the correct sequence of locking global lists
    Das wird helfen, versteckte Probleme in Plugins zu finden, sher schön.

  • Code
    1. > rm tools.o
    2. > make vdr
    3. CC tools.o
    4. LD vdr
    5. > rm tools.o
    6. > make VERBOSE=1 vdr
    7. CC tools.o
    8. g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -m32 -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DLIRC_DEVICE="/var/run/lirc/lircd" -DVIDEODIR="/video" -DCONFDIR="/video" -DARGSDIR="/video/conf.d" -DCACHEDIR="/video" -DRESDIR="/video" -DPLUGINDIR="/home/kls/vdr/VDR/PLUGINS/lib" -DLOCDIR="/home/kls/vdr/VDR/locale" -I/usr/include/freetype2 -I/home/kls/vdr/DVB/current/media_build_experimental/linux/include/uapi -o tools.o tools.c
    9. LD vdr
    10. g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -m32 -fPIC -rdynamic args.o audio.o channels.o ci.o config.o cutter.o device.o diseqc.o dvbdevice.o dvbci.o dvbplayer.o dvbspu.o dvbsubtitle.o eit.o eitscan.o epg.o filter.o font.o i18n.o interface.o keys.o lirc.o menu.o menuitems.o mtd.o nit.o osdbase.o osd.o pat.o player.o plugin.o positioner.o receiver.o recorder.o recording.o remote.o remux.o ringbuffer.o sdt.o sections.o shutdown.o skinclassic.o skinlcars.o skins.o skinsttng.o sourceparams.o sources.o spu.o status.o svdrp.o themes.o thread.o timers.o tools.o transfer.o vdr.o videodir.o -ljpeg -lpthread -ldl -lcap -lrt -lfontconfig -lfreetype /home/kls/vdr/VDR/libsi/libsi.a -o vdr


    Klaus

  • Ich habe mit vdr-2.3.6, beim Start Meldungen, wie folgende im Syslog:



    Aber skindesiger scheint zu funktionieren.


    Muss ich mir Sorgen machen? :angst


  • Muss ich mir Sorgen machen? :angst


    Das zeigt nur an, daß da die Reihenfolge der Locks nicht so ist, daß ein Deadlock ausgeschlossen ist.
    Das kann lange Zeit gut gehen, aber wenn irgendwann mal ein anderer Thread erst die Timer und dann die Channels lockt, dann könnte es passieren, daß die beiden sich gegenseitig blockieren. Daher sollten die Listen immer in der vorgegebenen Reihenfolge gelockt werden.


    Klaus

  • Ist das beabsichtigt, dass das mit den Locks immer nur bei einem Plugin angezeigt wird?


    Je nachdem, in welcher Reihenfolge ich die Plugins labe, kommt die o.g. Meldung von einem anderen Plugin.

  • Ist das beabsichtigt, dass das mit den Locks immer nur bei einem Plugin angezeigt wird?


    Jenachdem, in welcher Reihenfolge ich die Plugins labe, kommt die o.g. Meldung von einem anderen Plugin.


    Es wird nur das erste Auftreten einer ungültigen Lock-Reihenfolge angezeigt, weil der Backtrace eine relativ aufwendige Operation ist und das, wenn es häufig vorkommen sollte, die Performance schnell in den Keller treiben könnte. Außerdem reicht es ja, einen Fehler anzuzeigen - den man dann beheben sollte und sich dann auf den nächsten konzentrieren kann ;-).


    Klaus

  • Man muss nicht alle Plugins gleichzeitig laden ;-).


    Du kannst in thread.c in der Funktion cStateLockLog::Check() die Zeile


    dumped = true;


    auskommentieren. Dann zeigt er alle solchen Vorkommnisse an.


    Klaus

  • [...] Dann zeigt er alle solchen Vorkommnisse an. ...


    OK, habe ich mal gemacht und so wie es auf den ersten Blick aussieht, sind nur skindesigner und osd2web von diesem Problem betroffen. :)


    Allerdings habe ich diese Meldung, die ich keinem Plugin zuordnen kann:


  • Verdammt, jetzt habe ich es gerade geschaft alle Plugins für 2.3.5 in meinem PPA anzupassen und schon kommt 2.3.6 :]

    Gruß
    Frodo

  • OK, habe ich mal gemacht und so wie es auf den ersten Blick aussieht, sind nur skindesigner und osd2web von diesem Problem betroffen. :)


    Das muss noch nichts heissen. Das Ganze ist ja ein dynamischer Vorgang. Es kann also durchaus sein, daß bei bestimmten Aktionen oder Kombinationen von Aktionen noch Meldungen kommen. Hatte ich im Core-Code auch (siehe HISTORY).

    Zitat

    Allerdings habe ich diese Meldung, die ich keinem Plugin zuordnen kann:


    Code
    1. Jun 04 21:13:47 [vdr] [19956] /usr/bin/vdr cChannelsLock::cChannelsLock(bool) at channels.h:258 (discriminator 2)
    2. Jun 04 21:13:47 [vdr] [19956] /usr/bin/vdr at ??:0
    3. Jun 04 21:13:47 [vdr] [19956] /usr/bin/vdr cDisplayChannel::DisplayInfo() at menu.c:4627
    4. Jun 04 21:13:47 [vdr] [19956] /usr/bin/vdr cDisplayChannel::cDisplayChannel(int, bool) at menu.c:4581


    Kann es sein, daß du menu.c gepatcht hast? Im original Code ist Zeile menu.c:4627 in cDisplayChannel::ProcessKey() und nicht in cDisplayChannel::DisplayInfo().


    Klaus

  • sind nur skindesigner ... von diesem Problem betroffen.

    Kann ich bestätigen, mein Test-VDR mit skindesigner Skin:



    Und irgendwie ist die Formatierung dieser Zeile komisch, PID und ":" vertauscht:


    Code
    1. Jun 4 22:41:22 vdr2 vdr[1332]: invalid lock sequence at So. 04.06. 22:41


    Regards
    fnu

    HowTo: APT pinning

  • Und irgendwie ist die Formatierung dieser Zeile komisch, PID und ":" vertauscht:


    Die Zeile wird in cStateLockLog::Dump() nach stderr geschrieben, was bei dir anscheinend auch im Log landet. Auf die Formatierung hat VDR hier keinen Einfluß.


    Klaus