yaVDR 0.5. bei einigen Sendern seg. fault...???

  • Hi, nachdem ich den VDR geöffnet habe um zu schauen was für ein Netzteil eingebaut ist, habe ich noch kurz den Staub mit viel Luft ausgetrieben.

    Seit dem haben ich auf SAT1 HD, kabel HD, Pro7 HD. immer einen seg. fault.



    Die zweite DVB-S Karte habe ich schon ausgebaut, Kabel getestet, richtiger Sitz der Kabel und und und... so ganz verstehe ich nicht, warum bei diesen Sendern. Andere HD Sender gehen doch und warum nach dem Entstauben... Ach so, epg daten auch schon gelöscht... nutze aber SAT Empfang.


    Einer noch einen Vorschlag woran es liegen kann?


    Scheinen alle Sender auf 11464 Hor. zu beteffen. Gibt es da irgendwas wie ich das testen kann???


    {code]

    SAT.1 HD;ProSiebenSat.1:11464:HC23M5O35P0S1:S19.2E:22000:255=27:0;259=deu@106:32:1830,1843,9C4,98C,1860,186A,98D,186D,500:61300:1:1017:0

    kabel eins HD;ProSiebenSat.1:11464:HC23M5O35P0S1:S19.2E:22000:767=27:0;771=deu@106:34:1830,1843,9C4,98C,1860,186A,98D,186D,500:61302:1:1017:0

    ProSieben HD;ProSiebenSat.1:11464:HC23M5O35P0S1:S19.2E:22000:511=27:0;515=deu@106:33:1830,1843,9C4,98C,1860,186A,98D,186D,500:61301:1:1017:0

    SIXX HD;ProSiebenSat.1:11464:HC23M5O35P0S1:S19.2E:22000:1023=27:0;1027=deu@106:35:1830,1843,9C4,98C,1860,186A,98D,186D,500:61303:1:1017:0

    Pro7 MAXX HD;ProSiebenSat.1:11464:HC23M5O35P0S1:S19.2E:22000:1279=27:0;1283=deu@106:36:1830,1843,9C4,98C,1860,186A,98D,186D,500:61304:1:1017:0


    [/code]

    Gruß Martin (linuxdep)

    Dieser Beitrag wurde bereits 2 Mal editiert, zuletzt von linuxdep ()

  • Hi,


    Einer noch einen Vorschlag woran es liegen kann?

    liegt vmtl. an VDR-2.0.6 ...mit VRD-2.3.8 alles Ok!

    Auch bei uns im Forum hat ein User das gleiche Problem mit VDR-2.0.6

    Siehe > http://www.easy-vdr.de/thread-…ost-178250.html#pid178250


    Gruss

    Wolfgang

  • nee, oder....

    haben die was geändert an den Sendern??? Und ich dachte, da befreit man den VDR vom Staub der geschichte und dann das...Jetzt ist das neue netzteil zumindest unterwegs, nu muss ich aber doch wohl einen neuen VDR aufsetzen...

    Aber das gibt doch nicht nur zwei User die noch einen alten VDR benutzten???

    Gruß Martin (linuxdep)

  • Hi Martin,


    die müssen irgendwas geändert haben. Am Donnerstag lief bei mir noch alles perfekt und am Freitag ging nix mehr.


    Gruß und schönes WE

    Peter

    easyVDR 2.1 (stable)
    Das isser:

    Asus M3N78-EM, AMD X2 240e, GT630 Grafik, 6GB RAM, Systemplatte: Sandisk SSD 64GB, Media: Samsung 2TB, Tunerkarten: Cine S2, TT S2-1600, FB: One For All URC-7960, atric Rev.5, Display 240x128, GLCD t6963c
    FS: LCD Toshi 40ZF355D über AV Receiver YAMAHA RX-A 2050

  • aber nur bei uns zwei??? Oder sind wir die letzten mit der alten Version? ...

    Gruß Martin (linuxdep)

  • Bei mir und 2 Freunden gab es auch SEGfaults,

    Haben jetzt auf yavdr0.61 umgestellt und alles wieder schick :) (sprich vdr 2.20 tut es :)


    Gruß Micha

  • Hallo Leidensgenossen,


    Bin auch gerade dabei aus meinem Kellerrechner mit YAVDR 0.5 eine 0.6.1 zu machen.;)

    >> SERVER: Silverstone LC20S; ASUS P5N7A-VM;Core2Duo E7400;Scythe Shuriken;2GB Kingston; Tevii S460; Technotrend S2-3200, Samsung EcoGreen F2 1TB, Atric Einschalter; yaVDR 0.4
    >> Client: TechSolo TC2200S; Asrock H61M/U3S3; Celeron G530 boxed; 4GB RAM; Sparkle G520 passiv; Harmony 555; yaVDR 0.5
    >> AV-Reciever:Onkyo TX SR 606 mit Harman Kardon HKTS 11
    >> LCD:Samsung LE40C650

  • Habt ihr neu installiert oder den alten upgedatet?

    Gruß Martin (linuxdep)

  • Einen VDR 2.2.0 gäbe es auch noch in testing-vdr: https://launchpad.net/~yavdr/+…eld.series_filter=precise - natürlich sollte niemand mehr yaVDR 0.5 (Ubuntu 12.04 ist ja schon seit Monaten EOL) nutzen, aber wenn man etwas Luft braucht wäre das noch eine Möglichkeit.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • yavdr ist nicht für ein Update gedacht. Wenn jemand auf 0.6 umsteigen möchte, dann bitte frisch installieren.


    Lars

  • Einen VDR 2.2.0 gäbe es auch noch in testing-vdr: https://launchpad.net/~yavdr/+…eld.series_filter=precise - natürlich sollte niemand mehr yaVDR 0.5 (Ubuntu 12.04 ist ja schon seit Monaten EOL) nutzen, aber wenn man etwas Luft braucht wäre das noch eine Möglichkeit.

    Ich hab seit Ewigkeiten einen 0.5er als Headless-Server unter ESXi in Betrieb, irgendwann mal angefangen einen 0.6.1er neu einzurichten, aber mangels Freizeit dann halbfertig liegen gelassen. Die Clients laufen schon länger mit der 0.6.1 ...


    Ich wollte jetzt beim 0.6.1er Server weitermachen, kriege aber meine alten cineS2 (eine V5 und eine bei der der Treiber nicht mal eine Version angezeigt) nicht ans rennen (irgendwie will er von den 4 Tunern nur 2 verwenden und er findet die Kanäle dann auch nicht), weder mit den Kernel-Treibern, noch dddvd-dkms noch der media-build-experimental-dkms.

    Bevor ich da jetzt noch mehr Stunden investiere (spätestens zum Tatort muss das rennen, sonst gibt's Ärger ;-) ) ... was muss ich denn beachten, wenn ich den den vdr 2.2 aus dem Testing auf dem alten 0.5er verwenden will?


    Danke!

    Hab den neuen 0.6.1er Headless-Server dann doch noch zum Laufen gebracht, musste den ganzen ESXi rebooten, anscheinend waren die cineS2 "strubbelig", denn als ich den 0.5er nochmal gestartet habe, lief da auch nix mehr ...

  • was war das Problem in dem beitrag, habe nur schnell überflogen, aber 10 Seiten schaffe ich heute nicht mehr...


    Habe jetzt einen MLD 5.4 testing laufen, rennt ganz gut. Nach dem zweiten mal aufsetzen bekomme ich routine drin.
    Muss man nur höllisch aufpassen wohin man sein Backup schreiben will... gleiche Platte kommet nicht gut. :§$%

    Gruß Martin (linuxdep)

  • Also ich kann den Effekt bestätigen, bin aber kein yavdr user. Habe den VDR 2.0.3 auf meiner Kiste.


    Erstmals Freitag Abend, P7S1-Transponder (HD-), segfault. Zunächst im Log immer zu sehen "retuning" und erneuter Switch auf den gleichen Kanal, gefolgt vom segfault. Habe dann Code etwas angepasst (channels.h CHANNELMOD_RETUNE auf 0, so dass er sozusagen wegen keiner Änderung im Kanal einen retune macht), damit verschwand der retune/re-switch, das Problem aber nicht wirklich (wobei auch nicht klar war weswegen der retune passiert, Logausgabe zeigt in der Version wohl das nicht an). S1 kann ich live hinschalten, erst nach dem Wegschalten segfault/restart. P7 sofort segfault. Aufnahmen gehen bei beiden (und wohl auch weiteren Sendern des Bouquets), aber mit segfault/restart je bei Aufnahme-Start und Aufnahme-Ende. Es dürfen also jeweils keine anderen Aufnahmen laufen, jedenfalls wenn man bei denen keine 20s-Lücken haben möchte.


    Segfault sehr ähnlich zu dem im oben erwähnten Thread zu ntv (muss ich noch reinlesen):

    kernel: [9603.298457] vdr[2668]: segfault at 7fff2a76d000 ip 00007f2afccd6abb sp 00007fff2a769c18 error 6 in libc-2.13.so[7f2afcc4c000+18a000]


    Da meine Kiste nicht mal eben upgedatet werden kann (uralte OS-Basis), aber jederzeit der vdr im Source im Detail modifiziert und rekompiliert, wäre ich interessiert, wenn jemand weiss, woran das eigentlich liegt - und wo im Source man also vielleicht die Ursache beheben könnte..

  • Für verschlüsselte Sender gab es schon vor längerer Zeit einen Fix, der müsste eigentlich im vdr 2.2.x drin sein.


    Lars.

  • Für verschlüsselte Sender gab es schon vor längerer Zeit einen Fix, der müsste eigentlich im vdr 2.2.x drin sein.


    Lars.

    OK, aber ich kann den halt nicht (jedenfalls nicht mal eben / nicht so bald) einfach updaten / neu installieren. Daher würde ich gerne versuchen die entscheidende Änderung selbst in meinen 2.0.3 zu patchen. Aber welches ist diese Änderung. Evtl. das mit dem zu kleinen Buffer (ntv-Thread S.4, Änderung in ci.c)? Tatsächlich sind da gegenüber vor einigen Monaten (vielleicht aber auch erst seit Donnerstag) neue CA-IDs hinzugekommen in der channels-config.

  • Merci, dann komme ich hoffentlich heute Nacht mal dazu das zu probieren.

  • Also, Halleluja, die segfaults sind weg! Danke!

    (die Änderung in channels.h habe ich wieder rückgängig gemacht, retuning / re-switching darf wieder geschehen)


    Für alle die hier drüber stolpern kurz zusammengefasst:

    Änderungen in ci.c

    • an zwei(!) Stellen Buffer-Grösse hochsetzen
      uint8_t caDescriptors[512]; ---> uint8_t caDescriptors[1024];
    • in Funktion (weiss nicht wie essentiell das für das Problem hier konkret ist)
      void cCiCaPmt::AddCaDescriptors(int Length, const uint8_t *Data)
      oben einfügen: if (Length < 0) return;


    Jetzt bin ich nur gespannt, ob es auch bei der Kiste mit dem noch älteren VDR 1.7 auftritt (Wochenende)..


    (Der Richtext-Editor hier funktioniert ja mehr so mittel..)