Heute so gecodet...

Vielleicht war das ein Bug in früheren .NET Versionen? Ich programmiere im Job ja auch in VB.Net, aber ich hatte noch nie Probleme ohne .Flush() (das benutze ich nur zu Debugging-Zwecken).

Mein neuestes Baby ist der ioBroker Adapter sofarcloud, welcher die SOFARcloud benutzt um die eigenen PV-Daten zu bekommen und nicht SolarmanPV.

Letztere kastrieren den API Datenupload und wollen den kostenpflichtig machen.

Cool für Hauseigentümer, welche eine PV Anlage für 10 Tausende installiert haben...

Die SOFARcloud und App sind brand neu von SOFAR selbst und nur für Kunden dieser Wechselrichter & Solarpanels.

Ich habe heute das erst mal seit längerer Zeit mal wieder an meinem Please login to see this link. weitergearbeitet. Seit Juni habe ich nur Kleinkram gemacht wie das Auslesen der I2C-Sensoren für Temperatur, Druck, Luftfeuchtigkeit und Helligkeit (was einfach) oder das Auslesen der beiden Drehencoder (war unerwartet schwierig auf dem RasPi).

Seit längerer Zeit stand das Ausgeben der "Slideshow"-Bilder auf dem Plan. Als ersten Schritt dazu hatte ich irgendwann im August oder so die "KeystoneCOMM"-Library minimal geändert, um ein empfangenes Bild als Datenpuffer zu übergeben statt die SD-Karte dauernd mit neuen (teils defekten) Bilder vollzumüllen. Das war überraschend einfach, aber vor dem Dekodieren und Ausgeben der Slideshow-Bilder (JPEG und PNG, 320x240) hatte ich etwas Respekt. Zu Recht, wie sich jetzt gezeigt hat.

Ich habe es zwar heute in mehreren Stunden (!) für JPEG hinbekommen, aber er war ein Kampf:

Please login to see this attachment.

(der blaue/graue Gradient kommt noch weg, ist ein Relikt einer Spielerei von vor >10 Jahren oder so)

Was mich echt völlig unerwartet erwischt hat, ist die Fehlerbehandlung der Standard-JPEG-Library "libjpeg": man bekommt nicht einfach einen Fehlerstatus zurück oder bekommt eine Exception.

Nein, Warnungen werden ungefragt in der Konsole ausgegeben und bei Fehlern beendet der normale Fehlerhandler das gesamte Programm mit Fehlermeldung. WTF?

Und dann muß man aus unerfindlichen Gründen "Scanline" für "Scanline" dekodieren usw.

Am Ende habe ich diesen Code gebraucht, um ein blödes JPEG von einem Puffer in einen anderen zu dekodieren:

int read_jpeg(int size) {
    cinfo.err = jpeg_std_error(&jerrMng.pub);
    jerrMng.pub.error_exit = jpegErrorExit;
    if (setjmp(jerrMng.setjmp_buffer)) {
        /* If we get here, the JPEG code has signaled an error. */
        printf("%s\n", jpegLastErrorMsg);
        jpeg_abort_decompress(&cinfo);
        return 1;
    }

    jpeg_mem_src(&cinfo, imgData, size);
    int rc = jpeg_read_header(&cinfo, TRUE);
    if (rc != 1)
        printf("Invalid JPEG.\n");
    else {
        cinfo.out_color_space = JCS_RGB565;
        jpeg_start_decompress(&cinfo);
        int width = cinfo.output_width;
        int height = cinfo.output_height;
        int pixel_size = cinfo.output_components;
        int row_stride = width * 2; //pixel_size;
        printf("JPEG image is %d by %d with %d components\n", width, height, pixel_size);
        while (cinfo.output_scanline < cinfo.output_height) {
            unsigned char *buffer_array[1];
            buffer_array[0] = (unsigned char *)imgDataRGB16 + cinfo.output_scanline * row_stride;
            jpeg_read_scanlines(&cinfo, buffer_array, 1);
        }
        printf("JPEG warnings: %d\n", jerrMng.pub.num_warnings);
        jpeg_finish_decompress(&cinfo);
    }
    return (jerrMng.pub.num_warnings == 0) ? 0 : 1;
}

Diese "setjmp"-Konstrukt am Anfang ist Teil des Umbiegens des Fehlerhandlers auf meinen eigenen.

Der zweite größere Teil ist dieser Aktion ist das hier:

void jpegErrorExit(j_common_ptr cinfo) {
    /* cinfo->err actually points to a jpegErrorManager struct */
    jpegErrorManager* myerr = (jpegErrorManager*) cinfo->err;
    /* note : *(cinfo->err) is now equivalent to myerr->pub */
    
    /* Create the message */
    ( *(cinfo->err->format_message) ) (cinfo, jpegLastErrorMsg);

    /* Jump to the setjmp point */
    longjmp(myerr->setjmp_buffer, 1);
}

Man beachte den "long jump" am Ende. Mit dieser kruden Springerei wird so eine Art Exception-Handling in C vorgetäuscht. Sprich: bei einem Fehler spring die Library an die Stelle, an der ich das "setjmp" aufgerufen habe und führt den Code dahinter aus. Aber wer macht sowas im 21. Jahrhundert???

Und die Standard-PNG-Library "libpng" scheint noch viel schlimmer zu sein. Da ist überhaupt nicht vorgesehen, aus einem Puffer zu dekodieren. Man muß also der Library vortäuschen, daß sie die Daten aus einer Datei liest.

Oder so. Dazu hatte ich heute aber keinen Nerv mehr. Stattdessen hatte ich Please login to see this link. ausprobiert aber nach menschlichem Ermessen passiert da überhaupt nichts und es scheint auch keine richtigen Status- oder Fehlerinformationen zu geben.

Auch wenn man in den Quellcode (Libraries ohne Includes benutzt) und die Dokumentation (Bit mit Byte verwechselt usw.) schaut, fragt man sich eh, ob man den Kram benutzen wollte, selbst wenn er funktionieren würde.

Also muß ich mich doch mit libpng rumschlagen, aber das wird wohl wieder ein paar Wochen dauern, bis ich mich in dieses Tal der Tränen wage.

Quote from 0xdeadbeef

Aber wer macht sowas im 21. Jahrhundert???

Na ja, die Library ist schon etwas älter - erste Version von Please login to see this link.

Quote from 0xdeadbeef

Also muß ich mich doch mit libpng rumschlagen, aber das wird wohl wieder ein paar Wochen dauern, bis ich mich in dieses Tal der Tränen wage.

Vielleicht wäre Please login to see this link. weniger schmerzhaft? JPEG geht damit auch.

Ich habe den PNG Decoder tatsächlich schon letzte Woche mit libPng implementiert. Das Problem ist leider, daß ich ihn bislang nicht 100% testen konnte.

Tatsächlich scheint nur ein einziger Sender unter den ~56 gefundenen Senders PNGs zu verwenden und die Empfangsqualität ist da anscheinend so schlecht, daß ich da keine Bilder ohne Bitfehler empfange (obwohl die Empfangsqualität zwischen 44% und 55% hin- und herspringt).

Anscheinend wird da auch nur das Senderlogo geschickt und das wohl auch nicht wirklich sehr oft. Teils wird über Stunden gar kein vollständiger Datensatz empfangen und wenn ich einen empfange, dann bricht libPNG früher oder später mit einer Fehlermeldung ab (meist "bad adaptive filter value" - oft verbunden mit Versuchen, Bytes außerhalb des Empfangspuffers auszulesen).

Beispiel nach fast 2h:

Image Size: 5892
Not a PNG.
Image Size: 20541
PNG image is 320 by 240 with 8 bit depth
read failed: size:20541 pos:17554 len:8192
libpng error: bad adaptive filter value
PNG error/warning.

-> es wurden überhaupt nur zwei S(l)ideshow-Puffer empfangen. Der erste war so defekt, daß nicht mal die ersten paar Bytes OK waren, beim zweiten war der Header OK, aber danach kamen halt Bitfehler.

Ich habe mir die Bilder trotzdem mal ausgeben lassen, insofern bin ich mir relativ sicher, daß der Decoder im Prinzip funktionieren sollte, aber für einen richtigen Test fehlt mir schlichtweg ein (gut empfangbarer) Sender, der regelmäßig PNGs verwendet und wenigsten alle paar Minuten ein Bild schickt.

So oder so werde ich wohl als nächstes eine andere Großbaustelle angehen. Vermutlich erst mal eine Mini-GUI zur Senderauswahl, dann die MP3-Dekodierung und Ausgabe bei Senderausfall und irgendwann das ganze heile I2S-Thema.

Tausende Bits sind richtig, aber am Ende hat der Code Schluckauf bekommen.

Richtig: 0111010011110011100101011001111111001000

Falsch : 0111010011110011100101011001111110100100

Die 01 sind falsch. Da wo sie gelesen werden stehen sie aber als 10 drin.

Diese 40 Bits wurden nicht einzeln gelesen und geschrieben, sondern am Stück.

Ich habe gefühlt schon 100 Logfiles und momentan keine Ahnung wie ich den Fehler finden soll.

Das sind Momente wo Coden keine Freude bereitet...

Quote from oobdoo

Tausende Bits sind richtig, aber am Ende hat der Code Schluckauf bekommen.

Richtig: 0111010011110011100101011001111111001000

Falsch : 0111010011110011100101011001111110100100

Die 01 sind falsch. Da wo sie gelesen werden stehen sie aber als 10 drin.

Diese 40 Bits wurden nicht einzeln gelesen und geschrieben, sondern am Stück.

Ich habe gefühlt schon 100 Logfiles und momentan keine Ahnung wie ich den Fehler finden soll.

Das sind Momente wo Coden keine Freude bereitet...

Display More

Mit einer 6510-CPU wäre das nicht passiert.

Quote from oobdoo

Tausende Bits sind richtig, aber am Ende hat der Code Schluckauf bekommen.

Da geht es (wieder) um Deinen RLE-Packer? Wobei es eher ein Nibbler ist, oder?

Quote from oobdoo

Richtig: 0111010011110011100101011001111111001000

Falsch : 0111010011110011100101011001111110100100

Die 01 sind falsch. Da wo sie gelesen werden stehen sie aber als 10 drin.

Diese 40 Bits wurden nicht einzeln gelesen und geschrieben, sondern am Stück.

Ich weiß natürlich nicht, was Du da treibst, aber die Tatsache, daß die ersten 33Bits OK sind und die letzten 7 Bits nicht, sieht schon ein klein wenig nach einem Problem jenseits der 32bit aus.

Quote from muffi

Quote from oobdoo

Tausende Bits sind richtig, aber am Ende hat der Code Schluckauf bekommen.

Da geht es (wieder) um Deinen RLE-Packer?

Nein. Der hatte nichts damit zu tun.

Quote from muffi

Wobei es eher ein Nibbler ist, oder?

Please login to see this link.

Quote from 0xdeadbeef

Ich weiß natürlich nicht, was Du da treibst, aber die Tatsache, daß die ersten 33Bits OK sind und die letzten 7 Bits nicht, sieht schon ein klein wenig nach einem Problem jenseits der 32bit aus.

Ich hatte vergessen das zwischendurch nochmal was konvertiert wurde und das die Menge an Bits nicht durch acht teilbar war.

Das hatte mich auf die falsche Spur (Gedanken) geführt. Den Fehler hatte ich dann spät in der Nacht wegbekommen.

Quote from oobdoo

Please login to see this link.

Das ist der Packer, bei dem unterschiedliche Bitlängen codiert werden. Der Nachkompressor vom 64er Packer/Happy Packer ist so ein Packer. Das häufigste Byte wird mit einem Bit codiert: 0. Alle anderen erhalten dann immer mehr Bits, die seltensten Bytes werden dabei sogar verlängert.

Nicht ich, sondern der kleinste Zwerg. Er möchte gerne etwas selbst programmieren, scheint irgend ein Windowsclone zu werden... hier ein geheimer SNEAK:

Please login to see this attachment.

Meinen ersten eigenen Code für ein PyTorch Projekt ans Laufen gebracht. Eigentlich nur den Teil wirklich neu geschrieben, der csv Daten in das Pandas DataFrame Format konvertiert, wie es yfinance liefert.

Es ist wirklich eine ganz neue Art von Programmieren für mich, wenn man keinen Algorithmus vorgibt, sondern dem System nur Daten gibt und eine Funktion, die den Fehler berechnet. Ab da muss das System selbst einen Lösungsweg finden.

Hab gelernt, dass mein Laptop nicht gut für KI ist, und man doch so eine Grafikkarte mit Cuda haben sollte, wenn es komplexer wird. Aber ich lerne ja noch.

da bietet sich ein NVidia Jetson Orin für an.

Sag Bescheid.