Posts by M-Reimer

    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.


    Pi 4 Ethernet Network fails to connect to some 100Mb Switches · Issue #3122 · raspberrypi/linux
    We make a 100Mb switch which we used with Pi 2's and Pi3's... Its a "Hat", based on Realtek RTL8306MB. We have shipped thousands of them with…
    github.com

    Raspberry Pi 4: Network non-functional directly after (re)boot · Issue #3108 · raspberrypi/linux
    Describe the bug If I boot directly to an up-to-date Raspbian, then the network starts up in some kind of "no-functional" state. Means that dhcpcd…
    github.com


    Beide Bugs betreffen zwar speziell den Fall "Direkt nach dem Boot", aber es ist schon bezeichnend das man solche Workarounds braucht:

    net: bcmgenet: Workaround for Pi 4B network issue by pelwell · Pull Request #3121 · raspberrypi/linux
    Some combinations of Pi 4Bs and Ethernet switches don't reliably get a DCHP-assigned IP address, leaving the unit with a self=assigned 169.254 address.…
    github.com

    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.

    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.

    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:

    Quote

    ABVERKAUF - 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.

    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.