Rein aus Neugier, den VDR kann man ja auch via Keyboard steuern, ganz ohne LIRC, wo kommen da dann die Events her?
Von STDIN. Das ist aus Zeiten wo man den VDR noch auf ein VT (Terminal) gemappt hat. Das geht heute eigentlich nur noch selten weil die Display-Lösung oft auch direkt Eingaben verarbeitet.
Was meinst du mit "Internet geht noch". Kann der fragliche Raspberry noch auf's Internet zugreifen?
Es gibt einige Bugs bezüglich des LAN-Interfaces am Raspberry Pi 4. Am Compute Module 4 haben sie dann ein besseres Modul verbaut, aber das am "Single Board Raspberry Pi 4" ist teilweise etwas zickig.
Beide Bugs betreffen zwar speziell den Fall "Direkt nach dem Boot", aber es ist schon bezeichnend das man solche Workarounds braucht:
Letztlich ist das eigentliche Thema hier angesiedelt: RE: Registrierung kaputt
Stand aktuell kann man das VDR-Wiki als tot betrachten. Besser die Infos dezentralisieren. Statt alle Plugin-Infos an einer Stelle zusammenzutragen besser die Info direkt beim Plugin auf dessen Projektseite ablegen.
Wenn jemand da Infos zu Plugins pflegen will die im Kontext von https://github.com/vdr-projects/ liegen, dann kann ich da ggf. gerne Wikis anlegen und Rechte vergeben.
USB 3 Hubs haben teilweise auch größer dimensionierte Netzteile.
Bei mir wäre an der Stelle vermutlich der Punkt erreicht wo ich dem Modell gar nicht mehr traue.
Und je nach Händler machen die das mit dem Austauschen auch nicht ewig mit.
Ich würde mal einen SMART full check triggern und durchlaufen lassen.
Ich hoffe ja seit Jahren auf einen großen Durchbruch, der so große Kapazitäten mit nur einer Scheibe ermöglicht.
Noch geht es ja stetig voran mit der Datendichte. Ich glaube im Bereich "große Datenmengen" bleiben die magnetischen Datenträger noch ne Weile "Stand der Technik". Und die SSDs holen stetig auf und nehmen den "drehenden Platten" von unten her die Existenzberechtigung weg.
Die "externen" sind letztlich auch normale 3,5" SATA-Platten. Ob die jetzt "minderwertiger" sind kann ich aber nicht beurteilen. Haben aber sehr viele von ihrem Gehäuse "befreit" und dann in PCs oder NAS eingebaut. Die Gehäuse sind dann auf eBay gelandet. Hab selber einige davon gekauft und da Platten aller möglicher Marken drin verbaut. Man kann die Gehäuse, wo nötig, sogar mit einem kleinen Lüfter nachrüsten.
Ich würde ja sagen wie wäre auch in dem kleinen Innenkarton schon ausreichend verpackt gewesen. Den großen Karton außen rum hätte es gar nicht gebraucht. Versandaufkleber auf den kleinen Karton und gut.
Festplatten sind keine rohen Eier. Wenn die in Parkposition sind und sich nicht drehen vertragen die schon bisschen was.
Wenn du bei einem Wiring nur zwei Pins tauschen musstest, dann kannst du auch genau dieses Wiring nehmen ohne es zu verpatchen und stattdessen die dazu passenden Leitungen in deiner Verkabelung tauschen.
Eigentlich braucht es genau ein Wiring. Am besten du nimmst, wenn du selber lötest, immer "Standard". Es gibt nur mehrere weil es tatsächlich mal eine Zeit gegeben hat wo man fertige Displays mit Parallelport-Stecker dran kaufen konnte. Während die Daten-Pins üblicherweise jeder "korrekt" verbunden hat gab es bezüglich Displays und dieser Status-Pins nie einen Standard. Hat jeder anders gemacht.
Jetzt wäre noch interessant gewesen ob es klappt wenn du mit dem Wissen das es im Prinzip läuft und was es mit dem Wirings auf sich hat einfach ein bestehendes Wiring nachgebaut hättest. Die 4 Anschlüsse müssen eigentlich elektrisch gleich sein und noch ein neues Wiring sollte gar nicht nötig sein.
Ich würde mich nicht zu sehr am "Invertieren" aufhängen. Man kann graphlcd sagen das die Ausgabe invertiert erfolgen soll.
Andere Pinouts werden auch kaum helfen. Wenn die Kommunikation steht, dann passt auch das Pinout.
Nur durch diese Diskussion kommt es nun Worst Case dazu das es gar keine separate APIVERSION mehr gibt und man wirklich ohne Not ständig neu bauen muss. Dann hätte ich lieber den aktuellen Stand behalten und eben besser dokumentiert das die APIVERSION eben nicht zwingend der VDRVERSION entsprechen muss.
Aber stimmt schon. Letztlich entscheidet Klaus. Ich würde mich auf jeden Fall freuen wenigstens noch einen Hinweis in Changelogs zu sehen wenn kein Neubauen zu Version X nötig ist. Ich würde, wenn keine bessere Lösung kommt, dann lieber die APIVERSION auf diese im Changelog genannte Version zurück patchen statt unnötig neu zu bauen.
Wie schon versucht es irgendwie klar zu machen: Die Versionsnummern können nicht "weg". Auch wenn das definitiv meine liebste Alternative wäre. Ein stabiles API für Plugins das sich möglichst lange nicht mehr ändert und dann auch weg mit dem ständigen Plugin-Neukompilieren. Würde mir so verdammt viel Aufwand sparen beim VDR updaten... Aber auch klar: Der VDR ändert sich stetig (was ja auch gut so ist) und um alle internen Änderungen auch mit Plugins nutzen zu können ist direkter Zugriff auf VDR-Interne Strukturen sehr vorteilhaft.
Ich kann nur immer wieder betonen: Ich habe mich wahnsinnig gefreut bei diesem VDR-Update ausnahmsweise mal nicht stundenlang kompilieren zu müssen. Von mir aus gerne öfter Releases bei denen Plugins nicht neu gebaut werden müssen. Ärgerlich das hier über eine wirkliche Annehmlichkeit dann gemeckert wird. Ich weiß nicht wie viele Plugins speed kompilieren muss, aber ich habe bei jedem VDR-Update so irgendwas um die 80 Plugins zu bauen. Und nutze davon selber vielleicht 3 oder 4.
Vermutlich wäre eine von der VDR version unabhängige Nummerierung tatsächlich das optimale. Wegen mir einfach eine hochlaufende Zahl und gar keine Versionsnummer mehr. Das würde auch ein anderes Problem fixen das sich ergeben hat. Als es noch Entwickler-Versionen (die "ungeraden Versionsnummern") gegeben hat, dann wurden Plugins zu Entwickler-Versionen automatisch inkompatibel wenn eine neue Entwickler-Version mit API-Änderung gekommen ist. Das ist, wenn man regelmäßig vom GIT baut, nun nicht mehr so. Der Entwicklungsstand könnte schon inkompatible Änderungen drauf haben, aber die APIVERSION wurde nicht angepasst weil ja eben nur Entwicklungsstand. Mit einer hochlaufenden Nummer könnte Klaus theoretisch bei jeder für die API inkompatiblen Änderung diese Nummer einfach einmal hochzählen. Auch beim Bauen vom GIT werden dann inkompatible Plugins nicht mehr geladen.
Wenn die APIVERSION letztlich wirklich hart auf die VDRVERSION gemappt wird, dann würde ich mir zumindest einen Hinweis wünschen ob sich eine API-Änderung ergeben hat. Ich würde dann nämlich für Arch gerne hart zurück patchen um mir die ganze Kompiliererei zu sparen. Dafür das ich es selber kaum noch nutze ist mir der ganze VDR-Kram nämlich langsam echt zu viel Aufwand.
Diese RA8835 sind allerdings recht günstig zu haben.
Und unten das entscheidende:
QuoteABVERKAUF - Lieferung solange Vorrat reicht
EOL
Etwas ist mir letztens noch aufgefallen:
https://lcdstore.de/WebRoot/St…AG320240C0-FMI-T_v1.0.pdf Seite 13 steht etwas von einem Widerstand der das Protokoll bestimmt. Den vielleicht mal checken.
Und ansonsten zeitnah, bevor die Rückgabefrist durch ist, an einem Arduino testen und ggf. zurückgehen lassen.
Ich werde auf jeden Fall nicht nochmal irgendwelche alten LCDs aufwändig nach USB mappen. Beim T6963C hatte ich eigentlich auch gehofft der wäre noch ne Weile gut verfügbar.
Was her muss ist eine schöne Lösung mit modernem TFT. Und wenn man's schon kann, dann auch gleich auf farbige Darstellung gehen.
Achtung! Mein Projekt läuft nicht auf einem ESP!
Nummern gibt es dann immer noch. Optimal wäre wenn man Plugins gar nicht neu bauen müsste. Aber letztlich bauen Plugins eben gegen interne Interfaces im VDR.
An der Stelle bin ich leider raus. Ich kann nur sagen das die Treiber für ks0108 und t6963c funktionieren. Die hab ich nämlich schon selber benutzt.
Um das zu debuggen müsste ich erstmal so ein Display haben. Und bei den Preisen sehe ich das nicht ein.
Mein usbserlcd ist ausschließlich für t6963c gedacht. Und auch die bekommt man nur noch zu Apothekenpreisen.
Niemals würde ich in ein neues System noch einen Parallelport nachrüsten nur für ein LCD. Heute ist USB modern. Allerdings sind monochrome LCD mittlerweile teurer als farbige.
Aktuell tendiere ich dazu sowas für graphlcd tauglich zu machen: https://www.amazon.de/Tarente-…l+ardu%2Caps%2C223&sr=8-3
wie wäre es mit einer einstellbaren Option --build-always-plugins in der vdr.conf. Das wäre für Distributionsbauer sinnvoll, denn sie wissen nicht, was für Pluginversionen der Anwender ggf. schon hat.
Den Sinn davon verstehe ich jetzt aber nicht. Wo ist der Vorteil davon? Die Pakete werden doch nicht auf dem Anwendersystem gebaut.
speed Warum hast du etwas dagegen das man sich das Neubauen von Plugins sparen kann?
Vielleicht auch eine denkbare Lösung: APIVERSION zweistellig. Immer wenn sich die letzte Versionsstelle ändert ist kein Plugin Neubau nötig. Eine Änderung an der Plugin API dann nur noch wenn sich die vorletzte Versionsstelle ändert.
