Patch: Programmübersicht für vdr-live

  • Moin,
    ich habe das selbe Problem auf meiner PogoPlug.
    Der Patch von Rolf bringt bei mir keine Verbesserung.


    Da ich kein segfault bekomme, konnte ich auch kein coredump erstellen.


    live:
    commit 6304bd11852dc998d28ecc9d5ae23a239300144d


    tntnet:
    ii libtntnet-dev 1.6.3-4 Tntnet library development headers
    ii libtntnet8 1.6.3-4 Tntnet libraries
    ii tntnet 1.6.3-4 modular, multithreaded web application server for C++
    ii tntnet-runtime 1.6.3-4 Tntnet runtime system

  • Hi


    Um die entstandene Verwirrung aufzulösen:


    Zitat

    Original von winni
    im Anhang der erwähnte Patch von Rolf. Ich bin noch nicht so richtig dazugekommen mir das anzusehen.


    Ich habe mir den Patch angeschaut und verglichen was für Änderungen mit dem finnischen Locale-Update noch hinzu gekommen sind.


    Demnach ist der Patch, den Winni in seinem vorigen Post hier angehängt hat auch im GIT mit drinnen. Erneutes Anwenden des Patches führt zu Rejects.


    Das Problem scheint damit noch nicht behoben zu sein. Happy debugging :schiel


    Grüße
    Tadi

  • Hallo


    hmm, das einzige was ich in dem Patch gefunden habe, was etwas machen kann ist dies:


    Aber wenn dieser Patch was ändert würde ich den Grund gerne besser verstehen und das anders lösen. Mit diesem Patch werden die Kanalgruppen jedes mal neu berechnet, was nicht notwendig ist.


    Wenn hier nur hohe Last habt, aber keinen Crash, dann könnt ihr auch mit "kill -11 PIDvomVDR" einen Crash und damit einen Core dump provozieren ("ulimit -c unlimited" nicht vergessen).
    Mit dem Core dump kann man dann ein Backtrace machen, das würde mir sehr helfen zu verstehen was passiert. Weil das kein echter crash ist, kann es sein, dass man die Stelle nicht genau trifft, deshalb wäre es gut 2-3 Backtraces zu haben. Und vom richtig Thread muss das Backtrace auch noch sein... am besten gleich von allen Threads die Backtraces machen. Das wird einiges an Daten sein.


    Viele Grüße,


    Martin

  • Hmm, hab ich das nun falsch verstanden, der Bug tritt auf sobald man Multischedule anklickt, sorgt für quasifreeze der cpu bishin zum vdr restart? Hier nicht. Hab jetzt nur ein paar mal wild hin und her geklickt, dabei keine höhere cpu-last bemerkt und schon gar keinen restart.


    dpkg -l "*tnt*"|grep ii
    ii libtntnet-dev 1.6.3-4 Tntnet library development headers
    ii libtntnet8 1.6.3-4 Tntnet libraries
    ii tntnet-runtime 1.6.3-4 Tntnet runtime system


    live:
    commit 6304bd11852dc998d28ecc9d5ae23a239300144d
    Sun Jan 23 20:10:07 2011 +0100


    Ein fettes DANKE an alle Beteiligten auf live wie auf patchseite, SUPER ARBEIT Jungens :portal1


    mfg


    midas

    plugin-block: Download, Thread im Portal, Wiki
    plugin-sleeptimer: Download, Thread im Portal, Wiki
    VDR-Chat: Web-Chat, IRC
    [size=8]ASUS M2N-E, Athlon X2 4450B, 2GB DDR2, Technisat Skystar HD (TT-3200), Technisat Skystar HD2, Hauppauge WinTV Nova-T USB, GigaByte GT-630 - 4TB RAID5 + 6GB externes Journal @50 GB Crucial Adrenaline SSD DP-CT050M4SSC2 - BeQuiet SystemPower7 300W - wheezy/vdr2.0.1 - xbmc 13

  • Hi,


    forget the the live-20110123-finnish2.patch. This one is a real fix for empty initial values in the multischedule.


    Btw, I'm unable to trigger anymore those deadlocks, but my earlier fixes were only "plasebo" ones that only hides the real bug (hey! they do work for me :)).


    Edit: The patch has now been merged into GIT.

  • Hi


    Zitat

    Original von rofafor
    forget the the live-20110123-finnish2.patch. This one is a real fix for empty initial values in the multischedule.


    English:
    Thanks rofafor tor the patch. I just applied it to the main LIVE git repository.


    Deutsch:
    Vielen Dank an rofafor für den Patch. Ich habe ihn gerad im LIVE git angewendet.



    Grüße
    Tadi

  • Zitat

    Originally posted by mwaAber wenn dieser Patch was ändert würde ich den Grund gerne besser verstehen und das anders lösen. Mit diesem Patch werden die Kanalgruppen jedes mal neu berechnet, was nicht notwendig ist.


    There's a bug in the current channel group implementation: if you modify your channel groups via the setup page/tab, the modifications won't be available until next restart of VDR. I find it quite frustrating and the quick fix is to regenerate the channel groups everytime. I agree, there should be some kind of signaling mechanism to check whether configuration has changed: one could always check whether the timestamp of last LiveSetup modification has changed.

  • hi all,


    danke! auch wenn ich nicht von problemen betroffen war ist es doch nun ein sichere gefühl nicht doch noch davon überrollt zu werden :P


    multishedule ist übrigens HAMMER vielen dank dafür!


    greetz

    SZVDR HD: Intel e5300@1,2ghz - Gigabyte GA-EP41-UD3L - 2GB ddr2 800 - Gainward G210 512mb - Silverstone LC16MR - Tevii s480 - Astra 19,2 - MLDHD-5.4 testing


    WZVDR HD: Intel g1610@1,6ghz - Intel DH61BE - Scythe Big Shuriken 2 - 4GB ddr3 1333 - Asus GT610 1024mb - Chieftec Hi-Fi HM-02 - Tevii s480 - Astra 19,2 - MLDHD-5.4 testing

  • Hi Rolf,


    thanks for fixing the bug with the channel groups and the other fixes :)


    Zitat

    Originally posted by rofafor


    There's a bug in the current channel group implementation: if you modify your channel groups via the setup page/tab, the modifications won't be available until next restart of VDR. I find it quite frustrating and the quick fix is to regenerate the channel groups everytime. I agree, there should be some kind of signaling mechanism to check whether configuration has changed: one could always check whether the timestamp of last LiveSetup modification has changed.


    Your are right I haven't thought about that, and I like your solution.


    Martin

  • Hi

    Zitat

    Original von rofafor
    Here's a minor patch to get rid of those little layout quirks related to the multi schedule.


    Yeah.. another patch. I like it to see progress... applied :)


    Greetings
    Tadi

  • The StringEscapeAndBreak() function messes up the HTML encoding in multischedule.ecpp as TNTNET's reply.sout() method does it automatically.
    "A&B" -- StringEscapeAndBreak() ---> "A&B" --- reply.sout() --> "A&B"
    Notice that the multischedule isn't the only place where the method is used, so the same bug can be found elsewhere too.


    I also fixed a few compilation warnings and modified the finnish translation a bit.


    Edit: The patch has now been merged into GIT.

  • Hi rofafor


    Zitat

    Original von rofafor
    The StringEscapeAndBreak() function messes up the HTML encoding in multischedule.ecpp as TNTNET's reply.sout() method does it automatically.
    "A&B" -- StringEscapeAndBreak() ---> "A&B" --- reply.sout() --> "A&B"
    Notice that the multischedule isn't the only place where the method is used, so the same bug can be found elsewhere too.


    Yes the statement about StringEscapeAndBreak() function is true. It was meant to be used with reply.out() (not reply.sout()). If I remember correctly it also translates some VDR special characters (haven't looked at it now).


    As before, thanks for the patch. I applied it to LIVE git.


    Greetings
    Tadi

  • ich weiss es ist nicht weihnachten, aber wenn eh gerade so fleissig an live gearbeitet wird, einen kleinen wunsch von mir. (oder 3)
    (weiss nicht ob es einfach umzusetzen ist. wie, weiss ich eh nicht)


    1. aufnahmen : anstatt bei jeder aufnahme ein button zum löschen, lieber checboxen zum markieren "mehrerer" aufnahmen. und einen button oben/unten welchen dann gleich alle auf einen rutsch mitnimmt.


    2. bessere sortiermöglichkeiten der aufnahmen


    3. die ordner sollten nach dem löschen nicht gleich zugeklappt werden, sondern wie vor dem löschen wieder auffpoppen.


    4.umbenennen der aufnahmen ermöglichen ?


    5. verschieben der aufnahme



    :versteck

Jetzt mitmachen!

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