Beiträge von maluhi

    Mein Gott dann lass es auch per Cron ausführen und gib es in eine Datei aus. Dann hast Du sogar ein Log und siehst wann genau es Feed-Updates gab. Wenn Du dann die Software aktualisierst, weisst Du ja wann Du das machst und dass das System danach aktuell ist.


    Du kannst Dir auch einfach das Datum von /var/lib/dpkg/status anschauen. Dann weisst Du wann Du das letzte mal Pakete installiert hast. Kannst Dir auch die .list Files in /var/lib/dpkg/info/ anzeigen und nach Änderungsdatum absteigend sortieren. Dann weisst Du sogar wann genau welches Paket aktualisiert wurde.


    Das kannst Du aber auch sein lassen und hier noch mehr Haare in der Suppe suchen. Aber ohne mich. Bin jetzt auch raus aus der Diskussion :face_with_tongue:

    Siehe mein Edit. Hab beim Kreieren des Satzes nicht nachgedacht. Kommt halt davon, wenn man etwas nebenbei macht :smiling_face:
    Das IST das Datum an dem zuletzt neue Updates auf dem Feed gefunden wurden.
    Pack Dir "apt-get update" in den cron und lass es jede Stunde laufen. Dann weisst Du auf eine Stunde genau, wann es das letzte mal Updates auf dem Feed gab. Ob das jetzt so sinnvoll ist, sei mal dahin gestellt...

    Code
    # echo 'Zuletzt nach Updates gesucht "'`LANG=de_DE ls /var/lib/apt/lists/dreamboxupdate.com_opendreambox_2.5_unstable_r0_*_deb_*_._Release -l | awk '{print $6 " " $7 " " $8}' | sort -r | head -n1`'". Es stehen '`apt-get dist-upgrade -s | grep ' upgraded, ' | cut -d" " -f1`' Updates aus.'
    Zuletzt nach Updates gesucht "Mär 28 17:15". Es stehen 0 Updates aus.

    Bitteschön :grinning_squinting_face:


    Edit: "Zuletzt nach Updates gesucht" ist falsch. Es müsste "Zuletzt wurden neue Updates gefunden" heißen. Aber das könnt ihr sicher selbst in dem Einzeiler ersetzen.

    Selbst Microsoft macht das bei Windows so wie DMM das handhabt. Da gibt es auch bei Windows Updates nicht jedesmal eine neue Build #.
    Bei Windows genügt Otto-Normal-User doch auch eine Angabe ala "X Update-Pakete stehen aus" und "Updates wurden zuletzt gesucht am d.m.h". Sowas könnte man vllt. in der Info noch mit aufnehmen (obwohl das auch bei Win nur unter Windows Updates und nicht in der Versionsinfo steht).
    Und es verwirrt dort niemanden, bzw. Microsoft setzt keine Extra-Wünsche einzelner User um.

    Gute Idee! Aber warum nicht gleich jedesmal einen kompletten Neuflash erzwingen, um sicher zu gehen, dass auch alle Pakete geupgradet werden?
    Dann einfach das Datum des Flashens anzeigen und die Installation von einzelnen Paketen ganz verbieten. Schließlich würde eine falsche Datums/Versionsangabe Otto-Normal-User sonst nur durcheinander bringen.

    Und jetzt gerade bekomme ich nach ein wenig zappen nur noch Ton - egal auf welchem Kanal. Auch nach komplettem Disconnect und somit Neustart des dreamliveservers ist das unverändert.


    Ich musste die Server-Box komplett rebooten! Schätze mal da hing irgendwas am Encoder device, was dreamliveserver auch nach Neustart nicht wieder resettet hat.


    Werde dann wohl leider vorerst wieder auf den dreamrtspserver "downgraden". Dass meine Freundin sich, falls ich nicht da bin, per VPN mein Heimnetz einloggen soll und dann remote meine Box restarten muss, wenn es mal nur Ton und kein Bild gibt, gäbe nur Komplikationen, schätze ich :winking_face:

    Ok, ich gebe es auf. Habe oben doch schon erklärt, warum ein zusätzliches Versionspaket nicht hilfreich wäre.


    Schlägt ein Upgrade bspw. fehl und es werden einige Upgrades nicht ausgeführt, würde in der Info trotzdem die neue Version angezeigt, falls das Versionspaket bereits installiert wurde, bevor die anderen Upgrades fehlschlugen. Oder ein User macht "apt-get install versionspaket".. oder oder oder. Es bringt NICHTS.


    Das einzige, das etwas bringen würde wäre eine Anzeige: "X ausstehende Paket-Updates auf dem Feed". Das gehört aber meiner Meinung nach eher in den Softwareaktualisierungs-Bereich und nicht in die Info über die aktuelle Version von enigma2.

    Die aktuelle Version auf dem offiziellen DMM unstable Feed IST 4.3.1r27-r0.0!!!
    Es gab seit dem 20.03. kein neues enigma2 Paket. Zumindest nicht auf dem offiziellen Feed.
    Wenn ein Teamimage da r0.1 oder höher hat, dann hat das Team wohl enigma2 nochmals gebaut (das Paket - NICHT die Binary) aufgrund von Team-Internen Änderungen. Das hat aber genau NICHTS mit der enthaltenen enigma2 Binary zu tun, deren Datum in der Info ausgegeben wird.


    Edit: Und bei jeder Pups-Änderung von Plugins das enigma2 Paket neuzubauen wäre Schwachsinn.
    Und selbst wenn es ein Paket geben würde, das einen Counter enthält, der bei jeder neuen Änderung hochgezählt wird, dann sagt das noch lange nichts darüber aus, ob auch alle anderen Pakete wirklich aktualisiert sind. Das liegt in der Natur der Paketverwaltung. Überprüfen kann man das nur, indem man apt-get update && apt-get dist-upgrade ausführt bzw. im GUI eine Aktualisierung startet. Aber wenn man das eh machen muss, braucht man auch keinen Counter, der sowieso nichts aussagt...

    Was soll denn da als Datum eurer Meinung nach angezeigt werden?
    Auf eurer Box sind unzählige unterschiedliche Pakete. Und es gibt einfach nicht DAS Datum, auf dessen Stand das System gerade ist. Ein User kann
    1) Einzelne Pakete per apt-get installl paketname installieren, ohne den Rest zu updaten
    2) Einige Pakete auf hold setzen und alle anderen trotzdem aktualisieren
    3) .debs aus Foren installieren
    4) GP3 installiert haben, das einen zusätzlichen Feed hinzufügt.
    4) noch einiges mehr...


    Was soll da jetzt angezeigt werden? Das Datum des letzten vollständigen Updates? Wird das dann aktualisiert, nur weil sich auf dem GP3 Feed ein Picon-Paket geändert hat? Wird das auch aktualisiert, obwohl ein bestimmtes Paket per hold zurückgehalten wurde? Spielt die Installation eines .debs aus einem Forum eine Rolle? Was wenn nur ein Paket aktualisiert wurde und der Rest nicht?


    Stellt euch das OS eurer Box vor wie ein Auto und enigma2 ist die Karosserie. Das Auto hat ein Baujahr. Und das wird nicht geändert, nur weil ihr euer Radio/Seitenspiegel/Sitzbezüge austauscht/upgraded. Kommt ein Facelift für euer Modell raus, kauft ihr euch ein komplett neues Auto bzw. besorgt euch irgendwo eine neue Karosserie (im Fahrzeugschein steht immer das Baujahr der Karosserie). Erst DANN habt ihr ein neues Baujahr im Fahrzeugschein, und nicht nur, weil ihr eure neuen Scheibenwischer anbaut...


    Ist das echt so schwer zu verstehen? :smiling_face:

    Du verstehst einfach nicht, dass es einen core gibt, dessen Update-Stand in Info angezeigt wird und zusätzlich viele verschiedene Pakete auf dem Feed liegen, die unabhängig davon aktualisiert werden können.
    Nimm Dir doch einfach die Stable-Version, da ändern sich die zusätzlichen Pakete nicht so oft.

    Sehr gut!
    Ich kann bestätigen, dass die alte Verbindung beim Zappen nun nicht mehr 1 Minute weiter besteht.
    Allerdings ist gerade nach mehrmaligem hin- und her-zappen der dreamliveserver mit SEGV abgesoffen. Da ich vor ein paar Tagen schonmal das Speichern von Core-Dumps aktiviert hatte, kann ich euch gern den dump schicken, wenn ihr mir sagt wie ich euch das 160MB File am besten bereitstelle.


    Edit: Danach hat die Client-Box natürlich versucht wieder zu connecten, aber jedes mal ist der dreamliveserver wieder abgeschmiert - ohne core-dump o.ä. Hat sich ohne sichtbaren Log-Eintrag einfach immer sofort wieder beendet. Nach Umschalten auf einen anderen Kanal war das Problem behoben.


    Hier das Log vom Umschalten und dem SEGV:




    Und nach Umschalten ging es dann wieder:



    Nein, so sage ich das nicht. Kam vielleicht falsch rüber.
    Wenn man zappt, wird durchaus der Kanal gewechselt. Man "kann" aber nicht gucken, weil ein Haufen Bildfehler entstehen. Sieht dann so aus wie das Bild im Anhang. Und das liegt daran, dass die Bandbreite aufgebraucht ist und der Stream nicht vernünftig übertragen wird. Die Bandbreite ist aufgebraucht, weil der dreamliveserver den gleichen Stream zweimal raussendet. Einmal an den neuen Client und einmal an den alten, der gar nicht mehr existiert. Die Client-Box schickt daraufhin auch dauernd ICMP port unreachable Pakete an den Server, weil der versucht den alten Client auf einem inzwischen geschlossenen Port zu kontaktieren. Nach einer Minute wird die alte Clientverbindung auch vom Server geschlossen und die Bildfehler verschwinden, weil wieder genug Bandbreite zur Verfügung steht.
    Workaround wäre z.B. das Senden von Daten abzubrechen sobald icmp port unreachable zurück kommt. Dadurch wären dann auch alle anderen kaputten Clients gefixt.

    Das Ding heisst zwar tcpdump, aber damit kann man sich Pakete jeglicher Art anschauen - auch UDP. Und ich möchte mir ja lediglich anschauen, was da beim teardown gesendet wird.

    Ja das ist mir klar. Habe doppelt und dreifach kontrolliert, dass BEIDE Boxen auf dem neusten Stand sind, diese auch beide neugestartet.

    Hast du denn auch das gstreamer update gemacht?Ohne wird das Problem nicht verschwinden :). (es geht um diesen commit hier: https://github.com/opendreambo…ccfea1a90d48fb8077349108e )

    Habe vorher extra alles mit apt-get update && apt-get dist-upgrade auf den neusten Stand gebracht und auch gesehen, dass gstreamer aktualisiert wird. Geht also bei mir auch mit diesem Commit nicht.
    Der Server schickt fröhlich weiter UDP Pakete und ignoriert sogar die ICMP port unreachable Antworten eine Minute lang.

    Also bei mir läuft's immer noch nicht rund.


    Mit 6000 bit streamen funktioniert zwar jetzt, aber beim Kanalwechsel sendet der server immer noch eine Minute lang an die alte Client-Verbindung weiter. D.h. man muss nach jedem Kanalwechsel eine Minute warten, bis ein vernünftiges Bild kommt. Vorher hat man sehr viele Bildfehler.


    Beide Boxen haben ein aktuelles orig unstable image. Hier mal ein Log vom Kanalwechsel:


    Client:


    Server:


    Hast Du evtl nich eine alte Version?
    Man kann nämlich, seit ich NetworkBrowser Automount erzwingt udp gemeldet habe, wieder im Mount Manager tcp einstellen. Auch wsize und rsize kann man da einfach in den options angeben und diese werden in die fstab übernommen. Ich habe das zwar nicht im lokalen Netzwerk getestet, konnte aber damit eine NFS-Verbindung über das Inet bis an die Bandbreiten-Grenze vernünftig optimieren.

    Das ist super, dass es doch schneller geht, als Ghost vorraus sagte.
    Aber ich baue an meinem Plugin ja nicht (nur), weil es irgendwo Problem gibt (könnte ja auch erstmal nicht weiter updaten, da ich die neuen Features sowieso im Moment nicht brauche), sondern weil das ein guter Grund ist mich mehr mit python zu beschäftigen. Ich komme eigentlich von anderen Sprachen und habe vor ein paar Wochen die erste Python-Zeile geschrieben und finde es einfach interessant mich mit python und enigma2 näher zu beschäftigen.
    Von daher würde ich mich trotz eurer Fixes freuen, wenn mir die Frage beantwortet wird :smiling_face: