Posts by SHF

    Wenn ich für Lancom dann allerdings noch ewige Konfig hab, bin ich nicht viel besser dran, als mit OpenWRT.

    Von der Konfiguration finde ich OpenWRT angenehmer und logischer als die Fritzboxen.


    Zum SMS-Send via HTTP empfehle ich einfach mal in deren Forum die Frage zu stellen. Kostet ja nichts und ist schnell gemacht.

    Da wird sicher jemand LTE verwenden und sich besser auskennen als ich DSL-User.

    "Local server" ist korrekt gesetzt?


    Interessant ist, dass hier die Domain mit angehängt ist, obwohl ich die beim nslookup nicht angegeben habe.

    "Expand hosts" macht das, falls aktiviert (Advanced Settings).


    Ist eventuell "All Servers" oder "Strict order" aktiviert? Sollten beide aus sein.


    Die domain 'tvdr.de' ist öffentlich. Das könnte die Ursache sein, warum "Filter private" nicht geht.

    Bei mir OpenWRT 19.7 tritt das Problem nicht auf, allerdings hab ich ein 192.168.x.x Subnetz eingerichtet.

    SMS-Versand per Shell-Befehl soll bei OpenWRT gehen, ich hab eben mal geschaut.

    Aus dem Webinterface kann man Shell-Befehl ausführen. Man kann so auch einen Befehl beim Aufruf einer URL ausführen, das verwende ich selber. Irgendwie soll man da auch Parameter übergeben können, damit habe ich mich aber noch nicht beschäftigt.

    Das Senden einer vorgefertigten SMS an immer die gleiche sollte also auf dem Weg also schon mal gehen. Eigentlich müsste man auch Nummer und Text als Parameter an das Skript übergeben können, der Text ist bei einer SMS ja nicht so lang. Muss ich bei Gelegenheit mal Probieren, was da geht, wollte ich eh mal machen.


    Der Zusammenbau und das Aufspielen der Software war übrigens Problemlos und schnell erledigt (ich klammere jetzt mal die Virtualisierung aus).

    OpenWRT soll auf dem Board auch von einer SD-Karte laufen können, habe ich irgendwo gelesen. Da erübrigt sich die Installation.


    Das Einzige Problem, auf das ich bei OpenWRT gestossen bin, ist, dass PPPOE ondemand nicht ging. Sobald man ondemand aktivierte, fehlte die default Route und er baute deswegen die Verbindung nicht auf.

    Ich hab das inzwischen hingebogen, die Ursache muss ich aber im Winter mal ergründen. (Auch bei mir ist derzeit die Zeit knapp ;))

    Ich habe seit über 15 Jahren einen von Bauckhage laufen und bin zufrieden damit.

    Verbrauch inklusive LNB etwa 5W.

    Das dürfte der Nachfolger sein, sieht sehr ähnlich aus: https://www.reichelt.de/multis…eil-bms-508nt-p72615.html


    Inzwischen würde ich aber ein getrenntes Nezteil bevorzugen:

    https://www.reichelt.de/multis…il-bms-508dc-p211421.html

    Da ist man in der Wahl des NT frei und kann ein effizientes nehmen.

    https://www.reichelt.de/stecke…-mw-gst25e18-p171100.html

    Ohne NT wäre nicht mein Ding, da dann immer die Receiver / VDR den Multischalter und LNB speisen müssen.

    Der Nachteil ist die "feste Verdrahtung".

    Das ist aber auch der Vorteil!


    PARTLABEL und UUID dürfen nur einmal im System vorkommen, sonst passiet Chaos mit unvorhersehbarem Ergebnis.

    Einen 1:1 Clone von der Rootpartition, zB. zu Testzwecken oder als Sicherheit, auf einer anderen Partition liegen zu haben geht also nicht.

    In die Falle bin ich damals getappt :motz4.


    PARTLABEL ist halt so lang oder so kurz wie gewünscht, nicht diese elend langen Zeichenketten in der fstab

    Neben der Optik in der fstab lässt sich ein selbstausgesuchtes PARTLABEL auch geringfügig besser merken :lachen2.

    Was ändert sich für eine gemountete Partition, wenn dahinter noch eine oder mehrere neue Partitionen angelegt wurden ?

    Dass man an einer Platte mit gemounteten Partitionen nicht rum partitionieren soll, war schon "immer" so. Quelle hab ich aber leider keine mehr.

    Gpartet weigert sich AFAIK auch so eine Platte zu bearbeiten.


    Nachtrag:

    Die Variante PARTLABEL in Verbindung mit der internen Kernel-Commandline (und dem geeigneten fstab Eintrag versteht sich) scheint mir die sinnigste Variante zu sein.

    Das Umstellen auf PARTLABEL habe ich vor einer Weile mal mit dem damals aktuellen Debian probiert.

    So wirklich geklappt hat es aber nicht, da einige Skripte da nicht mit gemacht haben.

    Ob es nach der Umstellung auf systemd besser geht müsste man mal probieren.


    Da inzwischen aber auch schon die Swap-Partitionen mit UUID in der initrd eingetragen sind, befürchte ich, dass es nicht so einfach sein wird die UUIDs los zu werden.

    Eigentlich würde auch ich, zumindest auf einigen Rechnern, gerne wieder auf /dev/sd... zurück zu gehen. Wenn man weiss, was man macht, hat das im handling auch einige Vorteile.

    Da ich liebend gerne eine Variante hätte, die es ermöglicht, quasi aus einem tarball heraus eine Installation vorzunehmen, die dann auch sauber mit ihrem /root bootet, sind Varianten mit UUID nicht so sinnig, weil ich die nicht wirklich beeinflussen kann.

    Die UUID kann auch einfach ändern.

    zB. mit tune2fs oder swaplable einfach ändern.

    Bei einem anderen Partitionstypen wird es mit dem entsprechenden Tools auch irgendwie gehen, denke ich.


    ummerweise scheint cgdisk ein syncing-Problem zu haben, falls man die Physische Disc anpackt, auf der das aktuelle root liegt

    Man sollte nie eine Partitionstabelle bearbeiten, solange eine der Partitionen noch gemountet ist.

    Mit LTE hab ich zwar nicht zu tun, aber ich habe mir kürzlich ein APU2 angeschafft, auf dem (unter anderem) openWRT als Router läuft.

    Die Kombination APU2 / openWRT scheint aber auch als LTE Router recht beliebt zu sein, da liest man öfters davon.


    Ob da der SMS-Versand wie gewünscht geht müsstest aber selber mal schauen, ich kenne mich damit nicht aus.

    Festnetztelefon am APU2 anschliessen ist eher schlecht, ich bin den Weg einer externen VOIP-Box gegangen. Wobei, ist das bei LTE überhaupt VOIP?

    Eventuell gibts da auch einen anderen Router, wo man ein Festnetztelefon anschliessen kann.

    Ich würde mal bei openWRT im Forum vorbei schauen, der Markt ist ja kaum zu überblicken.

    Dass jeder, der die Fernbedienung in die Finger bekommt, alles nach Lust und Laune löschen/verstellen kann, ist mir auch schon aufgefallen.

    Eine Art Benutzerverwaltung, mit der man sowas verhindern kann, würde den VDR IMHO wirklich bereichern.


    Es gab da AFAIk mal ein Patch/Plugin, aber ich bezweifele, dass das mit VDR 2.4 noch geht.


    Ob das mit dem chattr +a funktioniert, müsste man mal probieren.

    Mit ACLs habe ich mich aber noch nicht näher beschäftigt, es klingt aber interessant.


    Mit normalen Dateirechten könnte man auch die Verzeichnisse, in denen sich die Videos befinden (also die mit dem Datum im Namen), auf readonly setzen. Besser vielleicht sogar nur die Dateien, die nicht geändert werden (marks zB. nicht).

    Dazu müsste man ein Skript schreiben, was das bei jedem Systemstart tut.

    Oder, falls der vdr durch läuft in gewissen Abständen. In dem Fall muss man aber aufpassen, dass auf die Verzeichnisse nicht gerade zugegriffen wird.

    Wenn man einfach mit make LCLBLD=1 baut wird versucht die Plugins nach /usr/local/lib/vdr zu installieren.

    Besonders unschön ist das wenn man als root arbeitet, da man dann nicht mal eine Fehlermeldung erhält. In dem Fall hat man u.U. Chaos im System angerichtet, ohne wirklich zu merken, was passiert ist.


    Natürlich ist INSTALL korrekt beschieben, dass man den Parameter LCLBLD=1 setzen und Make.config.template nach Make.config kopieren muss.

    Da ich ausser setzen von LCLBLD=1 nichts ändere, bin ich zum wiederholten male in die o.g. Falle getappt.


    Ursache ist, dass ohne Make.config die Verzeichnisse für make LCLBLD=1 nur teilweise stimmen.

    Die Fehlenden sind in der Makefile recht einfach zu ergänzen:

    Jetzt hat man auch mit make LCLBLD=1 das Verhalten der "alten" Makefile, ohne sonst irgendwas ändern zu müssen.


    Es funktioniert sowohl mit Plugins mit neuer als auch "alter" Makefile. Getestet mit VDR 2.4.1.

    Soweit ich es mir angesehen habe, sollten die Defaults, so wie ich sie eingefügt habe, auch mit nichts kollidieren.

    Ja der ist innerhalb von ein paar Minuten von 330 auf 370MB gewachsen.

    Das ist nach den Start normal.

    Scheint am EPG zu liegen.

    Man muss eine Weile warten, bis sich das stabilisiert hat.

    Das ganze EPG glaube ich kaum. Das wäre deutlich mehr.

    Ob es wirklich vollständig ist, hab ich natürlich nicht kontrolliert, aber geschätzt 20% von dem Dump sind EPG.


    370MB kann man sich im Hexeditor nur Stichprobenhaft ansehen. Selbst durchblätter ist nicht in sinnvollem Zeitrahmen möglich!


    Da stehen auch Massenweise Strings drin wie 333333 oder auch Sachen die IBEV oder anderes Kryptisches.

    Das hat so ein Dump an sich ;-).

    333333 ist z.b sehr oft vorhanden

    Ist das normal? Oder schon ein Hinweis auf ein Leck?

    Kann ich nicht beurteilen, "333333" sagt mir nichts.

    Das kann default Wert in irgend einem Datenfeld sein oder sonstwas, was zufällig den String "333333" ergibt.


    Der Speicheranstieg ist bei Bedienung (OSD) viel höher als wenn der VDR so füt Aufnahmen läuft.

    Dann versuch es doch bitte mal ohne Skin-Plugins.

    Wenn dann der Speicheranstieg nicht mehr auftritt, weiss man, dass es an den Plugins liegt.

    Dann kannst du auch die Dumps vergleichen und sehen, ob die "333333" noch so häufig sind.


    Speicheranstieg ist bei Bedienung (Transponderwechsel) kann aber auch am EPG liegen. Das sollte sich aber nach einer Weile Zappen auf einem Niveau einpendeln.

    Bei den Strings steht eine menge zeug drin. Einiges könnte vom skin sein...

    Ich denke der Dump ist vom Block:5645341c6000-56454ac39000 rw-p 00000000 00:00 0 [heap]?

    Der passt von der Grösse und es ist auch einzige, wo sich nennenswert was tut.


    So wie ich das sehe ist da der komplette EPG drin.

    Das Vorgehen hilft also auch nicht weiter.



    Ich empfehle nochmal, die Plugins auf das nötigste zu reduzieren und zu schauen, ob es dann immer noch auftritt.

    Den Skin-Plugin kann man jedenfalls ohne einschränkung Benutzbarkeit zum Test mal raus nehmen.

    Wobei: cArgs::arg ist eine cStringList und kein cString ;-).

    Ups, das hatte mein "grep" dann fälschlicherweise mit erwischt. Mir war die Feinheit auf die Schnelle nicht aufgefallen .

    "Append" kommt ja nicht so selten vor ;-).


    Edit:

    cString::Append wird wohl wirklich nicht benutzt. Ich hab die Funktion auskommentiert und es gibt keine Fehlermeldungen.

    Anscheinend wird die Funktion (zumindest im Core-VDR) nicht benutzt.

    Hatte mich auch schon gewundert, warum der Fehler nicht auch anderweitig aufgefallen ist.

    An einigen Stellen (zB. args.c und sicher noch anderen) ist die Funktion aber schon drin.

    Mit cppcheck habe ich auch schon das eine oder andere gefunden und es gibt noch mehr tools.

    Das tool hatte ich sogar schon installiert.

    Ich denke ich hatte es installiert, weil ich es auf den VDR los lassen wollte, hab es dann aber wohl vergessen.

    Inzwischen ist das nachgeholt und es hat auch prompt was gefunden:

    Code
    1. [ci.c:2885]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
    2. [libsi/si.c:58]: (error) Invalid number of character '(' when no macros are defined.
    3. [tools.c:1108]: (error) Memory leak: p

    Bei den ersten beiden Treffern bin ich mir nicht sicher, ob das wirklich Fehler sind.


    Beim Dritten müsste aber was dran sein.

    Ich denke, der "strcpy" macht da keinen Sinn:

    Wobei das so bei einem Rückgabewert von "NULL" noch immer zu Fehlern führt.




    Dann hab ich den VDR doch noch zum Laufen gebracht. (Irgendwie ist da Durcheinander mir den Headers passiert.)

    Ich hatte den dann jetzt auch ein paar Stunden mit libleak laufen gelassen. Nach ein paar Meldungen ganz am Anfang kam dann aber gar nichts mehr.

    Ohne DVB-Input und mit Dummydevice scheint das Speicherleck also nicht aufzutreten.

    Doch, es läuft bei mir unter Gentoo x64 und vdr-2.4.1 ohne Probleme. Die Quelle kommt von hier: vdr-dummydevice-2.0.0.

    Von da hab ich es auch.

    Ohne dummydevice geht es aber auch nicht, da beendet der VDR wegen fehlendem Ausgabedevice.

    Mehr als die o.g. Fehlermeldung kommt auch nicht. Leider sagt mir die gar nichts.


    - Ein Leak, weil ein Pointer "vergessen" wird, ohne ihn freizugeben.

    - Eine Datenstruktur, die immer mehr Daten sammelt und größer wird, [...]
    Kandidaten für den zweiten Fall sind Listen usw. der Events, Schedules, Recordings, Channels...

    Den ersten Fall müsste libleak doch abdecken?

    Zumindest wenn malloc() ... für die Speicherbereiche verwendet wird.


    Bei Events, Schedules ... hatte ich schon überlegt einen Zähler einzubauen, der die Elemente mit zählt.


    e-fence

    Stimmt, das hauch schon mal gehört.

    Erstmal muss ich den VDR hier aber überhaupt mal zum laufen bringen.



    Den kompletten VDR mit Plugins neu bauen lassen und analysieren?

    Ich würde es erst mal auf das Plugin eingrenzen.

    Als erstes mal nur mit den nötigen Plugins zur Ein und Ausgabe versuchen. Dann nach und nach die Anderen.


    Wenn du das Plugin hast, wirst du die Lösung wahrscheinlich auch bald haben.

    Bei skindesigner und softhddevice gab es immer mal wieder Probleme mit einigen Versionen der verwendeten Bibliotheken (ffmpeg zB.). Ich schätze, dass es da hängen wird.

    Das noepg-plugin wäre auch noch eine Möglichkeit.

    Aktuell hab ich aber eh keine DVB-Karte in diesem Rechner.


    Als erstes wollte ich den VDR überhaupt mal mit dem dummydevice-plugin zum laufen bringen.

    Aktuell scheitert es mit der Fehlermeldung:

    vdr: malloc.c:3760: _int_malloc: Assertion `(unsigned long) (size) >= (unsigned long) (nb)' failed.

    Make lief problemlos durch.

    Kann es sein dass das dummydevice-plugin nicht mehr mit vdr 2.4.1 läuft?

    Ich gehe mal davon aus, dass einfach Sat-Kabel abziehen keine Lösung wäre weil der VDR dann in "Emergency-Exit" geht?

    AFAIK macht der VDR das nur, wenn eine Aufnahme läuft.

    Wegen möglicher Nebenwirkungen des Sat-Kabel abziehens bin ich aber auch nicht sicher.