Ich hab die Verlinkung für satip auf https://vdr-projects.github.io/ jetzt mal auf das Repo von wirbel umgezogen.
Zur Erinnerung: Das Ziel ist es den Nutzern zu zeigen wo ein Plugin aktuell aktiv gepflegt wird. Ich habe versucht den aktuellen Stand bezüglich des Plugins zu erfragen, die Anfrage blieb aber unbeantwortet.
Hab ich jetzt mal übernommen. Wobei letzterer Patch noch etwas wie "Testen ob es hilft" wirkt. Aber ich habe das im Post auch so verstanden das es genau darum erstmal geht. Um das Problem auf diese Stelle einzugrenzen.
Weitere Patches dann bitte ausgehend vom Stand hier: https://github.com/vdr-projects/vdr-plugin-vnsiserver
Wenn ich irgendwie helfen kann, dann bitte melden. Ich sehe jetzt erstmal noch davon ab Patches ins Repo zu übernehmen. Ansonsten mache ich erstmal den stillen Zuschauer und verfolge die Gedankengänge derer, die sich mit C++ definitiv deutlich besser auskennen als ich.
Kann man sich in sehr vielen Editoren so konfigurieren. Oft reicht schon wenn man die Whitespaces "sichtbar schaltet". Also das Tabs und Leerzeichen durch "dezente Punte oder Pfeile" signalisiert werden. Wenn dann hinter einer Zeile ein oder mehrere graue Punkte sind weiß man bescheid.
Ich hab mir das im Emacs so eingestellt das er "Trailing Whitespace" als fetten roten Balken darstellt. Da sieht man sofort. Aber nein, ich empfehle niemandem Emacs zu verwenden. Das ist bei mir aus der Historie raus. Nutze den schon ewig. Aber es gibt definitiv besseres.
Kann mal bitte jemand auflisten welche Patches aktuell sind? Dann würde ich die gegen Abend in einem neuen Branch mal einbauen.
Nur mal als Historie falls nicht bekannt. Eventuell hilft es etwas beim Debuggen.
VNSI-Server wurde ursprünglich mal hier vom ursprünglichen Entwickler gepflegt: https://github.com/FernetMenta/vdr-plugin-vnsiserver
Etwas später wurde die Entwicklung zeitweise hier fortgeführt: https://github.com/mdre77/vdr-plugin-vnsiserver
Und im zweiten Repo wurde, soweit ich weiß, vor allem zusätzliche Threads eingeführt um diverse Bugs zu fixen:
Vielleicht ist in diesem Schritt vom "Original-Code" zu "verbesserter Code" irgend ein Bug mit eingebaut worden der jetzt erst für Probleme sorgt.
Die interessante Frage ist, ob neben den Warnings auch die Crashes weg sind.
Hi,
Da solltest du dich mal im Kodi Forum umsehen. Hier geht es um VDR und dessen Streaming Tauglichkeit ist schlecht. Deshalb integrieren unsere VDR Distris auch Kodi dafür.
Und da alles verdongelt und verschlüsselt ist darf hier eh nicht darüber gesprochen werden.
MfG Stefan
Stimmt nur zum Teil.
Kodi kann schon eine ganze Weile DRM-geschützte Streams ganz legal abspielen. Dafür nutzen sie das DRM-Modul das auch in Browsern eingesetzt wird. Oft zwar mit Einschränkungen. Extra zahlen für Full HD kannste dir z.B. auch schenken weil das bei vielen Diensten dann in Kodi nicht in Full HD ankommt. Aber technisch ist das schon machbar.
Es wäre zumindest einen Versuch wert mal zu schauen ob etwas mit dem Locking falsch läuft. Wobei das schon komisch wäre wenn Plugins, die da bisher keine Probleme hatten, jetzt Locking Fehler werfen.
Vielleicht nochmal ein unqualifizierter Einwurf aber nehmen wir an der Move Operator hat einen Einfluss (was ja wahrscheinlich ist). Kann man den mit wenig Aufwand so patchen das man geloggt bekommt in welcher Situation (Kontext) er aufgerufen wird?
Ich werde dann wohl die Tage für Arch erstmal einen Patch einbauen der den Move-Operator wieder rausnimmt. Wenn ich damit wieder volle Plugin-Kompatibilität erhalte, ist es mir das erstmal wert. Ich will in Kürze für einen guten Freund einen neuen VDR-Server aufbauen und bei denen läuft praktisch alles mit (vielen) LibreElec-Clients. Stabile VNSI-Unterstützung ist da also absolute Voraussetzung.
Soll keine Kritik an der Änderung an sich sein. Egal wie viele Beispiele ich lese, mit dem letzten Vorschlag von SHF ist die Implementierung praktisch "wie aus dem Fachbuch". Aber ob das eine Race-Condition oder gar ein GCC-Bug ist, kann wohl auf die Schnelle auch keiner rausfinden. Bei Sprachen wie C++ ist man halt schnell auch an einem Punkt wo man Fehler im Assembly-Code suchen muss. Linus hat das wohl ein paarmal veranstaltet und den GCC-Entwicklern dann genau sagen können wo sie Bockmist gebaut haben.
Je mehr Clients desto mehr parallel laufende Threads. Eventuell doch eine Race-Condition.
Knickerig ist eher der, der nach 10 Jahren nicht mal 50-100€ für ein neues Mittelklasse-Netzteil in die Hand nehmen will.
Das hat nichts mit "Knickerig" zu tun sondern es macht schlicht wenig Sinn gerade PC-Netzteile "auf Verdacht" zu tauschen. Ich hab hier im VDR sogar Hardware stecken (Mainboard, Speicher, ...) die 10 Jahre schon überschritten hat. Das läuft alles noch zu meiner Zufriedenheit also sehe ich den Grund nicht den Elektroschrott-Müllberg ohne Not noch größer zu machen. Ich hab die CPU vor einigen Jahren sogar nochmal durch eine gebrauchte ausgetauscht und so für wenige Euro auf das Maximum aufgerüstet was das Mainboard verträgt.
Gängiges Fehlerbild ist, dass ein (hinreichend hochwertiges) Netzteil sang und klanglos den Geist aufgibt. Gut, ich hatte tatsächlich auch schon "Knalleffekte" inklusive ausgelöstem Leitungsschutzschalter aber nie hat es irgendwelche nachgeschaltete Hardware negativ beeinflusst.
Wenn es zur Steigerung der Zuverlässigkeit eines "PC-Systems" eine erfolgversprechende Lösung wäre, Netzteile auf Verdacht oder nach festem Schema zu tauschen ohne das etwas ausgefallen ist, dann würde es kaum Server mit zwei Netzteilen geben. Gleiches gilt auch für die "Angst", dass ein ausfallendes Netzteil die sonstige Hardware beschädigt. Wäre das üblich wären Doppelnetzteile auch sinnlos.
Jemand mit dem Problem bitte mal diese zwei Zeilen kopieren: https://github.com/vdr-project…51e62/tools.c#L1102-L1103 und an dieser Stelle (vor dieser Zeile) einfügen: https://github.com/vdr-project…31b4dc51e62/tools.c#L1111
Hier ist diese Absicherung auch drin: https://www.geeksforgeeks.org/…nment-operator-in-cpp-11/
Vielleicht gibt es auch irgendwelche "Sonderfälle" bei denen so eine Zuweisung stattfindet ohne das man so direkt "a = a" schreibt. Finde ich eh etwas bedenklich wie viel man über die interne Funktionsweise von C++ bescheid wissen muss um mit der Sprache keine Unfälle zu bauen.
Wenn man in diesen Edge-Case rennt, dann gibt man auf jeden Fall den internen Pointer frei. Ich hätte dann aber eher einen Crash wegen Zero-Pointer-Dereference erwartet.
Performance ist schon auch wichtig. Und ob der move Operator wirklich die Ursache ist, war ja erstmal auch nur ein Bauchgefühl. In der Tat scheint es aber zumindest in einem Fall das Problem mit VNSI zu fixen. Man darf nicht vergessen das es ja scheinbar auch irgendwo mit der Compiler-Version zusammen hängt.
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.
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.
