Beiträge von M-Reimer

Zitat von rüsseltier

Wieviele USB-Wandwarzen aus der MicroUSB-Ära >2018 sind denn noch im Einsatz?

Bei mir? Alle! Ich habe die USB-Wandwarze von meinem ersten Smartphone (Galaxy S5) nach wie vor im regelmäßigen Einsatz. Die Original Samsung-Lader waren tatsächlich von guter bis sehr guter Qualität, wurden aber leider im großen Stil billig geclont. Und Handys kommen tatsächlich immer seltener noch mit Ladegerät. Eben mit dem Ziel das man bestehende Netzteile weiternutzt.

Und ja: Reparatur lohnt da wirklich nicht. An dem Punkt sollte man sowas tatsächlich zum Recyclinghof geben.

Ich würde auch sehen das man eine andere App findet.

Android ist von Google eigentlich auch so geplant das man sich möglichst stark von Google abhängig macht. Mit ein paar Verrenkungen kann man das dort aber ganz gut umgehen. Bei mir gehen z.B. möglichst wenige private Daten tatsächlich an Google. Sämtliche Sync-Optionen sind bei mir aus und ich synchronisiere stattdessen zu einem kleinen deutschen Anbieter (CardDAV, CalDAV und WebDAV). Einen Großteil der Google-Apps habe ich bei mir bewusst deaktiviert.

Zitat von MegaV0lt

Ich hatte 2014 den Fall, dass so ein Netzteil in einem scsi-gehäuse, meine Platte gegrillt hat. Zum Glück konnte man die Platte durch Tausch der zvs Diode wiederbeleben... Läuft heute noch

Nochmal dazu. Du kannst nicht Äpfel mit Birnen vergleichen und Netzteil ist eben nicht gleich Netzteil.

Erstmal: Natürlich ist ein Fehler, bei dem die Ausgangsspannung des Netzteils unkontrolliert ansteigt, nicht unmöglich. Die meisten Netzteile bieten am Ausgang eine konstante Spannung an. Und damit die konstant bleibt muss die irgendwie geregelt werden. Ohne jetzt zu tief in Details gehen zu wollen, aber in aller Regel wird die Ausgangsspannung mit einer bekannten Referenz verglichen. Diese Rückführung wird auch "Feedback" genannt. Wenn sie wegbricht oder irgendwo fehlerhaft funktioniert, dann denkt der Schaltregler das die Ausgangsspannung zu niedrig ist und fährt bis zum physikalisch möglichen hoch.

Bei extrem vielen Netzteilen geht man das Risiko tatsächlich ein und trotzdem sterben nicht stapelweise Geräte weg. Nicht wenige Handy-Ladegeräte (wahrscheinlich sogar die meisten) haben z.B. keinerlei Absicherung gegen Überspannung am Ausgang. Trotzdem tauschen wir nicht auf Verdacht nach einer gewissen Zeit alle USB-Netzteile aus.

Aber zurück zum Thema. Je nachdem wie wertvoll die nach dem Netzteil geschalteten Verbraucher sind (beim PC in aller Regel doch eher wertvoll) steht es dem Netzteil-Hersteller natürlich frei nicht auf die erste "Sicherungs-Schicht" zu vertrauen sondern eine oder mehrere nachzuschalten. Netzteile-Hersteller sprechen da kurz von "OVP" (Over Voltage Protection). Als Beispiel: https://landing.coolermaster.c…-opp-ocp-scp-otp-and-bop/

Zitat

It is generally activated when the voltage output exceeds 110% to 130%.

Richtig gemacht ist das eine zweite Schutzschicht. Wenn die Spannungsregelung aus welchem Grund auch immer versagt, dann springt die "OVP" ein und schaltet das Netzteil ab. Im Idealfall ist diese vom Rest möglichst autonom aufgebaut und wirkt auch dann noch wenn große Teile des eigentlichen Netzteil fehlerhaft sind. Die Wahrscheinlichkeit, dass dieser Schutzmechanismus auch was taugt, steigt natürlich mit der Qualität des Netzteils.

Danach könnte man nun eine dritte Schutzschicht schalten. Zum Beispiel eine TVS-Diode die so stark dimensioniert ist, dass sie den maximal möglichen Ausgangsstrom sicher kurzschließen kann. Die Tatsache, dass eine TVS-Diode normalerweise im Fehlerfall einen Kurzschluss bildet, wirkt zusätzlich als Schutz, deaktiviert das Netzteil dann aber dauerhaft.

Und hier fehlt eigentlich eine entscheidende Info am Anfang: Welches Netzteil ist denn aktuell verbaut? Wenn das ein Netzteil von guter bis sehr guter Qualität ist, dann kann man den Schutzmechanismen tendentiell auch vertrauen. Andernfalls hätte es möglicherweise sicherheitshalber längst getauscht werden sollen.

Aber zurück zu der Story mit dem SCSI-Gehäuse: Da war mit sehr großer Wahrscheinlichkeit ein eher einfaches Netzteil ohne jegliche zusätzliche Überspannungs-Schutzmechanismen verbaut. Deshalb auch der Hinweis auf "Vergleich Äpfel mit Birnen". Das 0815-Netzteil aus einem Festplatten-Gehäuse ist eben nicht vergleichbar mit einem guten PC-Netzteil von einem Hersteller, der Schutz nicht nur verspricht sondern auch hält.

Auch das kann dir bei einem nagelneuen Netzteil passieren.

Das heute kaum noch repariert wird ist die eine Sache, aber was spricht dagegen Elektronik solange zu verwenden bis sie tatsächlich Probleme bereitet? Schont Umwelt und Geldbeutel.

Nur weil ein Netzteil ein gewisses Alter hat bedeutet noch lange nicht das es demnächst ausfällt. Ich habe Netzteile da die schon deutlich länger als 10 Jahre gute Dienste leisten und ich hatte auch schon welche die sich noch in der Garantiezeit zerlegt haben. Das Alter hat damit nicht unbedingt direkt zu tun.

Muss ja auch nicht an dem Patch liegen. Beim Durchlesen der Änderungen ist mir nur das free() ins Auge gesprungen. Dazu kam das zwei Plugins wegen der Änderung nicht mehr kompilieren wollten (was nicht an der Änderung sondern an den verwendeten Compiler-Parametern gelegen hat). Vielleicht ein Zufall, vielleicht bringt es irgendwen auf eine Idee. Und wenn nicht, dann halt Pech gehabt.

Das ist jetzt wirklich nur ein Schuss ins Blaue, aber kannst du bei einer 2.6.6 mal den Commit rückgängig machen?

Klaus Schmidinger's git trees - vdr.git/commitdiff

Sind bei 2.6.5 auch die Warnings weg? Dann sollte man das relativ easy bisecten können. Muss ich nur mal schauen ob ich beim Kompilieren auch diese Warnings bekomme.

Unabhängig davon spinne ich bereits an einer vermutlich etwas blöden Idee. Mal sehen ob ich mal Zeit und Geduld dafür finde. Je länger ich mir die PVR-API von Kodi anschaue um so mehr sehe ich da Parallelen zu SVDRP. Allerdings wird es hier und da noch hapern. Mit starkem Performance-Nachteil würde es vermutlich jetzt schon gehen aber ich brauche für LSTE zum Beispiel eine Option um EPG-Events zwischen zwei Zeitstempeln zu erhalten. Bevor ich da Zeit reinstecke würde ich dann kls nochmal anmailen. Patches kann ich ggf. liefern.

Weil der VDR selbst noch keine Video-Streams unterstützt muss ich das erstmal versuchen auf stremdev aufzusetzen. Faktisch ist das genau so tot wie VNSI aber man muss nehmen was man kriegt. Setzt voraus das Streamdev sowohl Live-TV als auch Aufnahmen via HTTP streamt und das man von den Daten aus SVDRP auch auf die entsprechenden Streams schließen kann (also LSTR eine Art Index mitliefert mit der man den zugehörigen Stream erhält).

Wenn ich diese Schnittstelle richtig verstehe, dann kann man damit aber doch nur einem Device verbieten EPG bereitzustellen? Also alles oder gar nichts und nicht wie geplant ab einer gewissen Kanalnummer.

4-adriges Telefonkabel ist durchaus üblich für Sprechanlagen. Vor allem bei den neuen Anlagen, bei denen eigentlich nur noch zwei Adern zum Haustelefon gehen.

beinhart Das ist Einstellungssache. Wenn man aber gerne, ohne extern in der channels.conf zu fummeln, neue Sender eintragen will, dann kommt man um die automatisch hinzugefügten Kanäle nicht herum.

Ja, da könnte auch eine Grenze helfen die der VDR fest definiert. Hätte den Vorteil das auch Plugins die abrufen können. Wenn man irgendwo nur die "Vorzugskanäle" eines Nutzers zur Anzeige bringen will, dann geht das dann.

Saubere Lösung: Telekom beauftragen direkt neben den APL eine neue erste TAE zu setzen. Von APL bis erste TAE ist die Telekom zuständig und wenn an der neuen ersten TAE wieder eine Verbindung geht hast du schonmal eine brauchbare Basis.

Zitat von Joe_D

Was ich jetzt schonmal probehalber eingebaut habe:

• Die Option "Maximale Kanalnummer für EPG-Aktualisierung (0=alle)"
• Einen hübscheren Text für "Zeit bis zur EPG-Aktualisierung"

Auf meinem Test-VDR sind die wichtigen Kanäle bis Nummer 100, danach folgt unsortiertes Zeug.
Da ist es mir egal ob das EPG erst bei Anwahl aktualisiert wird. Interessante Kanäle hole ich dann nach oben.

Das ist eine Änderung die in irgendeiner Form definitiv direkt im VDR landen sollte. kls

Bedingt dadurch wie beim VDR das Kanal-Management gemacht wird, ist sicher bei den meisten Nutzern am Ende nur irgendwelcher Schrott.

Gerne natürlich auch in Form der schon länger diskutierten "Favoriten-Listen". Channels.conf nur als "Müllhalde" wo alles landet was der VDR so findet und in den Favoritenlisten dann nur die "guten Kanäle". EPG dann nur noch für Kanäle die mindestens auf einer Favoriten-Liste gelandet sind. Andernfalls halt mindestens über die vorgeschlagene "Kanal-Endposition" für den Scan.

Und nein, mein Plugin verhindert nicht den Scan. Ich wollte den Daten-Müll auf der Platte vermeiden. Ab einer gewissen Position (ab der halt der Schrott kommt) will ich gar kein EPG speichern. Hauptgrund war für mich aber VNSI, denn wenn man für zig Schrott-Kanäle EPG vorhält, dann dauert das Übermitteln an Clients deutlich länger.

wirbel Wäre für mich schon eine etwas größere Sache weil ich alles selbst kompiliere. Und ich habe eigentlich auch nur ein System das für einen Test in Frage kommt, welches gleichzeitig das Produktivsystem ist. Da ich bei Arch eigentlich nur eine Option habe was Compiler angeht (gcc 13.2.1) und damit wohl ziemlich sicher mein Produktivsystem lahmlege, würde ich erstmal abwarten ob sich jemand anderes findet der einen Backtrace bauen kann.

Ich habe mal noch eine Weile gesucht und immer wieder die Info gelesen, dass diese Warning wohl schon mehrfach ein "False Positive" war. Ich würde mal wagen zu behaupten das diese Warnung nicht 100%ig sicher die Ursache für den seit neuestem auftretenden Crash ist:

malloc(): unaligned tcache chunk detected

Und selbst mit einem Backtrace könnte ich die Ursache selbst nicht finden. Das Kauderwelsch in Backtraces konnte ich eigentlich noch nie lesen.

Alles ein bisschen ernüchternd. Da VNSI eigentlich echt gut funktioniert hatte, hatte ich Hoffnung, dass es reicht das immer nur an neue VDR-Versionen anzupassen. Das bis vor kurzem funktionierender Code dann plötzlich nicht mehr funktioniert stellt für mich das ganze Konzept "VDR" in Frage.

Das "p" ist hier definiert:

vdr-plugin-vnsiserver/videoinput.c at 57e4c71faae7414e15d3e36c4cfb4e7d7f518f72 · vdr-projects/vdr-plugin-vnsiserver

VDR plugin to handle XBMC clients. Contribute to vdr-projects/vdr-plugin-vnsiserver development by creating an account on GitHub.

github.com

Und wenn man mal nach diesem "weak_ptr" sucht, dann findet man auch das "lock"

std::weak_ptr<T>::lock - cppreference.com

Vielleicht hätte man beim Entwickeln von vnsiserver nicht ganz so abgrundtief in die C++-Trickkiste greifen müssen. Dann wäre der Code vielleicht sogar lesbar geblieben

Mit der letzten Version von softhdcuvid hat sich das Problem erübrigt. Jetzt ist im AUR wieder alles auf dem Stand von VDR 2.6.5.

Davon abgesehen das sich wohl irgendwie ein Fehler mit VNSI eingeschlichen hat.

Beitrag

RE: Compile Warnings in vnsiserver

Dann war's das wohl erstmal mit Kodi und VDR. Das einzige das ich bestätigen kann, ist, dass ich diese Warnings auch sehe.

(Quelltext, 22 Zeilen)


Und damit bin ich mit meinem Latein auch schon am Ende. Absolut Null Ahnung was der Compiler damit sagen will.

M-Reimer

30. Januar 2024

Vielleicht kann da ja jemand unterstützen.

Dann war's das wohl erstmal mit Kodi und VDR. Das einzige das ich bestätigen kann, ist, dass ich diese Warnings auch sehe.

g++ -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -D_FORTIFY_SOURCE=2 -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -std=c++11 -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"vnsiserver"' -DVNSI_SERVER_VERSION='"1.8.3"'  -o StatusCommands.o StatusCommands.c
In file included from /usr/include/c++/13.2.1/bits/shared_ptr_atomic.h:33,
                 from /usr/include/c++/13.2.1/memory:81,
                 from videoinput.h:27,
                 from videoinput.c:27:
In member function ‘std::__atomic_base<_IntTp>::__int_type std::__atomic_base<_IntTp>::load(std::memory_order) const [with _ITp = bool]’,
    inlined from ‘std::atomic<bool>::operator bool() const’ at /usr/include/c++/13.2.1/atomic:87:26,
    inlined from ‘bool cDummyReceiver::BeenDetached()’ at videoinput.c:428:31,
    inlined from ‘static std::shared_ptr<cDummyReceiver> cDummyReceiver::Create(cDevice*)’ at videoinput.c:468:28:
/usr/include/c++/13.2.1/bits/atomic_base.h:505:31: warning: ‘unsigned char __atomic_load_1(const volatile void*, int)’ writing 1 byte into a region of size 0 overflows the destination [-Wstringop-overflow=]
  505 |         return __atomic_load_n(&_M_i, int(__m));
      |                ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
In static member function ‘static std::shared_ptr<cDummyReceiver> cDummyReceiver::Create(cDevice*)’:
cc1plus: note: destination object is likely at address zero
In member function ‘std::__atomic_base<_IntTp>::__int_type std::__atomic_base<_IntTp>::load(std::memory_order) const [with _ITp = bool]’,
    inlined from ‘std::atomic<bool>::operator bool() const’ at /usr/include/c++/13.2.1/atomic:87:26,
    inlined from ‘bool cDummyReceiver::BeenDetached()’ at videoinput.c:428:31,
    inlined from ‘static std::shared_ptr<cDummyReceiver> cDummyReceiver::Create(cDevice*)’ at videoinput.c:468:28:
/usr/include/c++/13.2.1/bits/atomic_base.h:505:31: warning: ‘unsigned char __atomic_load_1(const volatile void*, int)’ writing 1 byte into a region of size 0 overflows the destination [-Wstringop-overflow=]
In static member function ‘static std::shared_ptr<cDummyReceiver> cDummyReceiver::Create(cDevice*)’:
cc1plus: note: destination object is likely at address zero

Und damit bin ich mit meinem Latein auch schon am Ende. Absolut Null Ahnung was der Compiler damit sagen will.

Zitat von jojo61

Welche Fehlermeldung gibt es denn da ?

Ich musste jetzt erstmal zwischen einer Wagenladung von Warnings suchen aber der erste Fehler ist tatsächlich der, der in diesem Issue genannt wird:

build failure with libplacebo 6.338 · Issue #72 · jojo61/vdr-plugin-softhdcuvid

softhdcuvid.cpp: In member function ‘void cMenuSetupSoft::Create()’: softhdcuvid.cpp:1156:27: error: ‘pl_named_filters’ was not declared in this scope 1156 |…

github.com

Also an der Stelle kein Problem direkt mit VDR 2.6.6 sondern mit libplacebo.

Hab das für Arch gerade auch mal nachgezogen.

Bei "rssreader" und "vompserver" fällt mir jeweils diese Änderung auf die Füße:

Klaus Schmidinger's git trees - vdr.git/commitdiff

Hab die beiden jetzt für Arch erstmal rausgenommen.

Und softhdcuvid baut nicht mehr. Ist jetzt erstmal wieder solange raus bis es ein neues Release gibt.

GitHub - vdr-projects/vdr-plugin-filebrowser: This plugin is a filebrowser with user-defined commands to execute on files

This plugin is a filebrowser with user-defined commands to execute on files - GitHub - vdr-projects/vdr-plugin-filebrowser: This plugin is a filebrowser with…

github.com

Aber frag mich nicht ob das noch was taugt.

Und geht natürlich nur mit Zugriff auf das VDR OSD auf dem Server.