Hallo zusammen,
ich hatte meine Frage zunächt im Frontend-Bereich gepostet (https://forum.fhem.de/index.php/topic,120217.0.html (https://forum.fhem.de/index.php/topic,120217.0.html)), aber vielleicht ist das dort gar nicht so gut aufgehoben und ich habe eher ein Problem mit meiner Datenbank. Daher die Frage nochmal an dieser Stelle.
Ich habe seit einer Weile Probleme mit meinen SVG-Plots. Wenn ich eine Seite mit SVG-Plots aufrufe, werden nicht immer alle Daten angezeigt. Wenn ich die Seite mehrfach aktualisiere, sind irgendwann alle Daten da. Die Daten sind alle in einer SQlite DbLog Datenbank abgelegt und die Probleme haben in dem Moment begonnen, als ich meine alte, total zugemüllte Datenbank gegen eine neue, leere Datenbank ausgetauscht habe.
Hat irgendwer eine Idee, woran das liegen könnte?
Viele Grüße
Philip
ich habe keine idee, aber nach einem update vor kurzem das gleiche problem. sobald es mehr als einen plot auf der web seite gibt werden in den meisten plots nicht mehr alle kurven vollständig gezeichnet. manchmal die plus weiter unten sogar garnicht. meist kurven mit vielen daten. wenn ich den entsprechenden plot auf einer seite alleine öffne gibt es das problem nicht.
Hi,
hab auch keine Ahnung warum, die Symptome sind wie von justme1968 beschrieben, allerdings NICHT mit svg-plots,
sondern mit Grafana-plots (die werden mittels weblink- iframe eingebunden) , grafana macht die sql-queries und die generierung des html-seite,
daher geht meine Vermutung eher in Richtung Datenbank - wo ich nix geändert habe. (DbLog- und SVG-Modul sind m.E. nicht involviert)
Es passiert allerdings nicht reproduzierbar und relativ selten, nach einem reload der page funktionierts (meist).
Könnte allerdings auch ein Browser-Problem sein (js? / mem?)
l.g. erwin
Was SVG betrifft: ich habe "unlaengst" die Voreinstellung auf plotfork (bzw. plotembed=2, was plotfork beinhaltet) geaendert, wenn der FHEM Server mehr als eine CPU hat, damit holen mehrere Prozesse die Daten parallel aus der DB. Es waere ein Test wert, ob mit plotfork 0 das Problem immer noch auftritt.
Grafana holt Daten auch parallel (ein Prozess pro Grafik, mehrere pro Dashboard, aehnlich wie FHEMWEB), man kann die Anzahl der Arbeiterprozesse pro DB eingrenzen.
Betreffend SVG bzw. FHEM-Bordmittel ... könnte ein evtl. zu klein definierter Wert im global attr blockingCallMax damit zusammenhängen ? Bin mir unsicher ob blockingCallMax hier eine Rolle spielt.
Für Grafana ist das natürlich außen vor.
ZitatBetreffend SVG bzw. FHEM-Bordmittel ... könnte ein evtl. zu klein definierter Wert im global attr blockingCallMax damit zusammenhängen ?
Ja, aber nur dann, wenn:
- plotfork explizit auf ein Wert ungleich 0 gesetzt ist UND
- plotEmbed explizit auf 0 gesetzt ist oder man hat nur ein CPU oder das OS ist nicht Linux.
Ich muss irgendwannmal die vielen SVG/plotfork Varianten zusammenstreichen.
ich versuche es mir genauer anzuschauen.
blockingCallMax hätte aber nur auf die anzahl der plots einfluss. d.h. es könnte die fehlenden plots unten auf der seite erklären.
das sollte aber alles nichts mit fehlenden werten in einem plot zu tun haben. nicht mit den fehlen von teilen einzelner kurven innerhalb eines plots.
was ich gerade ebene bemerkt habe weil ich einen screenshot machen wollte: direkt nach einem fhem neustart sind alle plots komplett. wenn fhem länger gelaufen ist fehlen teile.
Zitat
das sollte aber alles nichts mit fehlenden werten in einem plot zu tun haben. nicht mit den fehlen von teilen einzelner kurven innerhalb eines plots.
Das konnte ich bei mir bisher nicht beobachten (MySQL)
Ich habe mal eine Seite mit vielen Plots zusammengestellt und probiert ... kein Mangel zu sehen.
blockingCallMax = 15 eingestellt.
hab mich nicht gemeldet weil nach einem neustart erst mal alles ok ist. nach jetzt 4 tagen fängt es langsam wieder an. es fehlen einzelne oder alle kurven einzelner plots wenn es mehrere plots auf einer seit gibt. bei jedem neuladen der steine etwas anders. je mehr punkte eine kurve hat um so wahrscheinlicher wird es scheinbar. am problematischsten ist meine strom seite mit den pv und verbrauchs werten. der haupt plot hat aktuell 6 kurven und werte alle 20 sekunden.
im ersten screenshot sieht man wie es aussehen sollte, in der anderen vieren vier zufällige varianten nach einem reload der seite.
andere plots bzw. kurven darin reißen zu unterschiedlichen zeitpunkten ab.
ich hatte auch schon die anzahl der offen browser tabs bzw. das limit der gleichzeitigen verbindungen vom browser zum server in verdacht. zumindest erstes macht aber keinen unterschied und letzteres sollte sich nur auf komplette plots und nicht einzelne kurven innerhalb eines plots auswirken.
hast du eine idee wie wir dem problem auf die spur kommen ?
Hallo Andre,
eine Idee habe ich momentan nicht und kann nur mit Vergleichen dienen.
Ich habe jetzt vermuted es liegt vllt. an der Anzahl Linien innerhalb der Plots.
Habe zwei Testchats mit jeweils 7 Werten aus der DB. Das obere Chart ist mit MySQL, das untere mit SQLite.
Beide sind ohne Befund.
Im FHEMWEB habe ich eingestellt:
plotEmbed = 2
plotfork = 1
Im global habe ich testweise sogar nur
blockingCallMax = 6
eingestellt.
Mehr kann ich leider nicht dazu beitragen bzw. hab keine Idee dazu.
ZitatIm FHEMWEB habe ich eingestellt:
plotEmbed = 2
plotfork = 1
Auf einem "normalen" Mehrkern-Rechner ist das die Voreinstellung, und blockingCallMax ist (wie vorhin geschrieben) irrelevant.
@justme1968: Wie sind diese Attribute bei Dir eingestellt?
Ich wuerde als naechstes im "kaputten" Zustand jeweils die beiden anderen Versionen testen:
- plotembed=2 und plotfork=1 => FHEMWEB liefert die Seite ohne SVG aus, JavaScript laedt die SVGs in parallel, bis zu 5 auf einmal
- plotEmbed=0 und plotfork=0 => die Seite wird mit allen SVG seriell berechnet und ausgeliefert
- plotEmbed=0 und plotfork=1 => die SVGs auf der Seite werden mit BlockingCall parallel berechnet, die HTML-Seite wird komplett mit SVG ausgeliefert. Wenn die Berechnung mit dieser Einstellung laenger als 90 Sekunden dauert, wiederholt Chrome den Request, was zu Chaos fuehrt.
die anzahl der kurven in einem plot hat nichts damit zu tun. wenn es anfängt passiert auch bei plots die nur zwei kurven haben. es scheint eher mit der gesamt menge aller daten auf einer seite zu tun zu haben.
ich habe eben diverse Kombinationen von plotEmbed und plotFork probiert. plotEmbed scheint keinen einfluss zu haben, es tritt aber auf sobald plotFork auf 1 gesetzt ist. setze ich es auf 0 kann ich das problem nicht mehr reproduzieren.
was mir eben erst auffällt :( ist das es im log db fehler gibt wenn das problem auftritt:
meist 2021.04.19 09:38:59 1: PERL WARNING: DBD::SQLite::st fetch failed: database disk image is malformed at ./FHEM/93_DbLog.pm line 3671.manchmal auch
2021.04.19 09:38:53 1: PERL WARNING: DBD::SQLite::st execute failed: database disk image is malformed at ./FHEM/93_DbLog.pm line 3626.
das db image ist aber definitiv in ordnung. beim einfügen und wenn ich plotFork ausschalte gibt es keine solche meldung. auch wenn beim refresh die seite zufällig komplett aufgebaut wird (oder wenn der plot alleine auf der detail seite zu sehen ist) gibt es keine meldung.
ich tippe auf ein timing problem oder einen anderen seitenefekt der nur beim forken auftritt.
edit: ich habe fhem eben neu gestartet. danach sind alle plots ok und es gibt keine meldung im log.
das timing scheint also auch noch durch die laufzeit beeinflusst.
Fuer parallele read/write Zugriffe verlaesst sich SQLite auf Filesystem-Locks, die in deinem Fall womoeglich nicht perfekt sind.
Ich wuerde mit WAL Mode experimentieren: https://sqlite.org/wal.html
ich fürchte so einfach ist es nicht. wal mode wird von dblog aktiviert und ist an. vor dem update auch schon und da haben die plots funktioniert.
auch im asynchronous mode der aktuell aktiv ist haben wir ja nur einen writer und mehrere reader. dieser fall sollte funktionieren.
ich glaube eher das irgendetwas dazu führt das beim fork filedescriptoren nicht oder falsch geschlossen werden und sich parent und child in die quere kommen.
Wollte deine Beobachtung jetzt mal provozieren und habe ein SQLITE-Plot sieben mal kopiert und alle 8 Plots mit jeweils 7 Wertelinien in einen Raum platziert.
Auch jetzt konnte ich kein Problem feststellen. Scheint für mich kein allgemeines Problem zu sein.
Mein FHEM ist aktuell.
es liegt ja nicht nur an der reinen datenmenge. nach einem neustart geht ja alles. erst nach etwa 4 tagen fängt es an.
obwohl die datenmenge scheinbar schon mit rein spielt. es sind wie gesagt 7 readings die alle 20 sekunden in der db landen.
die hardware an sich sollte nicht das problem sein. das ist ein 8 core xeon mit 48gig hauptspeicher. und vor dem update (von einer sehr alten fhem version) gab es das problem ja nicht.
die symptome sind halt typisch für unsauberes forken.
wenn es das nächste mal auftritt werde ich versuchsweise erst mal den async mode abschalten. geht es im betrieb? einfach attribut löschen? oder lieber abschalten, neu starten und warten?
Zitatgeht es im betrieb? einfach attribut löschen?
ja, genau.
Hallo zusammen,
ich habe bei mir jetzt im FHEMWEB plotfork = 0 gesetzt (vorher war es nicht explizit gesetzt) und damit scheint das Problem jetzt erstmal behoben zu sein. Danke für Euren Input!
Grüße
Philip
Ich kann das Prob bei mir zwar immer noch nicht provozieren, aber habe zum Test die Get-Routine, welche die Daten für SVG bereitstellt, für SQLITE minimal angepasst.
Die V läuft bei mir ebenfalls tadellos.
Testet die bitte mal bei euch (wen das Prob betrifft).
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:
"wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"
Danach sollte ein "reload 93_DbLog" ausreichen.
@Philip, es ist zwar schön dass plotfork = 0 bei dir hilft, aber hat die unangenehme Eigenschaft dass dein FHEM blockieren / verlangsamt werden könnte wenn deine Datenbank nicht antwortet oder eine schlechte Performance hat.
Es wäre schon gut wenn wir da eine Lösung finden. Finde es halt eigenartig, dass ich es bei mir nicht nachstellen kann. Vllt. ist es auch von der Perl Version abhängig, bei mir die 5.28.1
Ich hatte zuerst die 93_DbLog mit der neuen Get-Routine probiert und das hat nichts gebracht. Danach habe ich ein FHEM update + restart gemacht und nochmal deine 93_DbLog runtergeladen. Jetzt scheint es zu funktionieren.
Beobachte es mal längere Zeit.
Hast du auch wieder plotfork = 1 gesetzt bzw. gelöscht ?
Ja, plotfork habe ich auf 1 gesetzt.
Gibt es weitere Erkenntnisse bezüglich der Testversion ?
Bei gibt es nach wie vor keine Auffälligkeiten.
noch nicht. die 4 tage sind gerade rum und es sollte demächst wieder anfangen. ich achte drauf.
ich habe gerade bemerkt das es wieder anfängt.
die dblog version von oben mit reload nachgeladen hilft leider nicht.
ich habe auch danach noch die oben beschriebenen probleme und sehe die fehler im log.
asyncMode deaktivieren hilft ebenfalls nicht.
ein fhem neustart hilft.
hast du noch eine idee?
Ich hätte mich tatsächlich auch gewundert wenn es etwas geändert hätte aber Versuch war es wert. fragle777 hat sich auch nicht wieder gemeldet. Vllt. läuft es ja bei ihm.
Was mich eben sehr wundert ist die beschriebene Zeitabhängigkeit zu der mir ehrlicherweise nicht einfällt woran so etwas liegen könnte.
Im DbLog kannst du mit den Attributen SQLiteJournalMode bzw. SQLiteCacheSize den WAL Mode ausschalten oder die Größe des WAL Cache verändern. Vllt. kannst du damit experimentieren und es ergibt ein Ergebnis mit einem veränderten WAL.
grad eben gesehen das das problem wieder da ist. nach nur ein paar stunden laufzeit.
ich habe jetzt auf die schnelle mal auf die letzte version zurück gewechselt und neu gestartet. mal sehen ob es damit wieder länger dauert.
das nächste mal spiele ich mal mit den parametern.
Also bei mir läuft es nach wie vor ohne Probleme.
Moin zusammen,
also hat die kleine Veränderung doch zumindest bei fraggle777 etwas bewirkt.
Aber grundsätzlich glaube ich nicht daran das es dafür nur eine einzelne Ursache gibt.
Die bisherigen Erkenntnisse mal zusammengefasst:
* von mindestens 352 Definitionen mit SQLite haben fraggle777, justme1968 und erwin von diesem Problem berichtet,
wobei erwin grafana benutzt und demzufolge SVG bzw. die Get-Funktion von DbLog bei ihm nicht involviert sind
* bei mir und der überwiegenden Mehrzahl der User (sonst gäbe es noch mehr Meldungen) läuft die eingecheckte v4.12.1 tadellos
* die neue Testversion v4.12.3 läuft bei mir ebenfalls klaglos und hat bei fraggle777 offensichtlich das Problem gelöst
* justme1968 hat mit beiden Versionen dieses Problem, wobei es sich nur nach einer Laufzeit von X Stunden oder
Tagen zeigt
Die Get-Funktion im DbLog kann man hier m.M. nach nicht allein "verantwortlich" machen. Möglicherweise spielen hier noch Faktoren wie Perl- bzw. Datenbankversion mit hinein.
Zum Vergleich nachfolgend meine Angaben dazu.
Die Perl/DBI/DBD Versionen seht ihr wenn ihr im DbLog-Device ein
set <> configCheck
ausführt, gleich ganz oben:
* Used Perl version: 5.28.1
* Used DBI (Database independent interface) version: 1.642
* Used DBD (Database driver) version SQLite: 1.62
Im BS "sqlite3 -version":
* SQLite Version: 3.27.2 2019-02-25 16:06:06
Mir fehlt momentan die Fantasie für einen weiteren Ansatz. Vielleicht habt ihr bzw. Rudi noch eine Idee aus einer anderen Richtung.
LG,
Heiko
ZitatMir fehlt momentan die Fantasie für einen weiteren Ansatz. Vielleicht habt ihr bzw. Rudi noch eine Idee aus einer anderen Richtung.
Damit man die Suche etwas einschraenken kann, schlage ich vor eine Log-Zeile in DbLog.pm einzubauen, die PID, bestellten Zeitraum, Anzahl der von der DB zurueckgelieferten Zeilen und Zeitstempel des letzten Datensatzes enthaelt. Dieses Log kann man aktivieren, wenn die SVG-Probleme auftreten, und hilft zu entscheiden, ob DbLog richtig aufgerufen wurde, und ob die DB alles zurueckgeliefert hat. Ich wuerde zusaetzlich die Ausgabe des SQL-Befehls vor dem Absetzen ausgeben, damit kann man evtl. sehen, ob das Problem mit der Reihenfolge zusammenhaengt.
Die meisten dieser Infos gab es schon mit verbose 5. Ich habe es noch mit der PID ergänzt. Dadurch sieht man bei vielen parallelen Abfragen die Zusammengehörigkeit.
Beispiel:
2021.04.29 14:55:19.873 4: LogSQLITE - PID: 32364, Processing Statement:
SELECT
TIMESTAMP,
DEVICE,
READING,
VALUE
FROM history WHERE 1=1 AND DEVICE = 'MyWetter' AND READING = 'pressure' AND TIMESTAMP >= '2021-04-29 00:00:00' AND TIMESTAMP <= '2021-04-30 00:00:00' ORDER BY TIMESTAMP
2021.04.29 14:55:19.874 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 00:22:13, DEV: MyWetter, RD: pressure, VAL: 1002
2021.04.29 14:55:19.874 5: LogSQLITE - SQL-result -> PID: 32367, TS: 2021-04-29 04:50:55, DEV: Dum.Energy, RD: AutarkyQuote, VAL: 0.0
2021.04.29 14:55:19.875 5: LogSQLITE - SQL-result -> PID: 32367, TS: 2021-04-29 04:51:55, DEV: Dum.Energy, RD: AutarkyQuote, VAL: 0.0
2021.04.29 14:55:19.875 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 00:52:13, DEV: MyWetter, RD: pressure, VAL: 1002
2021.04.29 14:55:19.876 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 01:22:13, DEV: MyWetter, RD: pressure, VAL: 1002
2021.04.29 14:55:19.877 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 01:52:13, DEV: MyWetter, RD: pressure, VAL: 1002
2021.04.29 14:55:19.878 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 02:22:14, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.876 5: LogSQLITE - SQL-result -> PID: 32367, TS: 2021-04-29 04:52:55, DEV: Dum.Energy, RD: AutarkyQuote, VAL: 0.0
2021.04.29 14:55:19.895 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 02:52:14, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.895 5: LogSQLITE - SQL-result -> PID: 32367, TS: 2021-04-29 04:53:55, DEV: Dum.Energy, RD: AutarkyQuote, VAL: 0.0
2021.04.29 14:55:19.895 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 03:22:14, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.896 5: LogSQLITE - SQL-result -> PID: 32367, TS: 2021-04-29 04:54:55, DEV: Dum.Energy, RD: AutarkyQuote, VAL: 0.0
2021.04.29 14:55:19.896 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 03:52:15, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.897 5: LogSQLITE - SQL-result -> PID: 32367, TS: 2021-04-29 04:55:55, DEV: Dum.Energy, RD: AutarkyQuote, VAL: 0.0
2021.04.29 14:55:19.897 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 04:22:15, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.898 5: LogSQLITE - SQL-result -> PID: 32367, TS: 2021-04-29 04:56:55, DEV: Dum.Energy, RD: AutarkyQuote, VAL: 0.0
2021.04.29 14:55:19.898 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 04:52:15, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.898 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 05:22:15, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.899 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 05:52:16, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.899 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 06:22:16, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.900 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 06:52:16, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.900 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 07:22:16, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.900 5: LogSQLITE - SQL-result -> PID: 32367, TS: 2021-04-29 04:57:55, DEV: Dum.Energy, RD: AutarkyQuote, VAL: 0.0
2021.04.29 14:55:19.901 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 07:52:17, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.901 5: LogSQLITE - SQL-result -> PID: 32367, TS: 2021-04-29 04:58:55, DEV: Dum.Energy, RD: AutarkyQuote, VAL: 0.0
2021.04.29 14:55:19.902 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 08:22:17, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.902 5: LogSQLITE - SQL-result -> PID: 32367, TS: 2021-04-29 04:59:55, DEV: Dum.Energy, RD: AutarkyQuote, VAL: 0.0
2021.04.29 14:55:19.903 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 08:52:18, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.903 5: LogSQLITE - SQL-result -> PID: 32367, TS: 2021-04-29 05:00:55, DEV: Dum.Energy, RD: AutarkyQuote, VAL: 0.0
2021.04.29 14:55:19.905 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 09:22:18, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.907 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 09:52:19, DEV: MyWetter, RD: pressure, VAL: 1001
2021.04.29 14:55:19.908 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 10:22:19, DEV: MyWetter, RD: pressure, VAL: 1002
2021.04.29 14:55:19.908 5: LogSQLITE - SQL-result -> PID: 32367, TS: 2021-04-29 05:01:55, DEV: Dum.Energy, RD: AutarkyQuote, VAL: 0.0
2021.04.29 14:55:19.909 5: LogSQLITE - SQL-result -> PID: 32367, TS: 2021-04-29 05:02:56, DEV: Dum.Energy, RD: AutarkyQuote, VAL: 0.0
2021.04.29 14:55:19.909 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 10:52:19, DEV: MyWetter, RD: pressure, VAL: 1002
2021.04.29 14:55:19.911 5: LogSQLITE - SQL-result -> PID: 32367, TS: 2021-04-29 05:03:55, DEV: Dum.Energy, RD: AutarkyQuote, VAL: 0.0
2021.04.29 14:55:19.912 5: LogSQLITE - SQL-result -> PID: 32367, TS: 2021-04-29 05:04:55, DEV: Dum.Energy, RD: AutarkyQuote, VAL: 0.0
2021.04.29 14:55:19.912 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 11:22:20, DEV: MyWetter, RD: pressure, VAL: 1002
2021.04.29 14:55:19.913 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 11:52:22, DEV: MyWetter, RD: pressure, VAL: 1002
2021.04.29 14:55:19.916 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 12:22:22, DEV: MyWetter, RD: pressure, VAL: 1002
2021.04.29 14:55:19.917 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 12:52:22, DEV: MyWetter, RD: pressure, VAL: 1002
2021.04.29 14:55:19.919 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 13:22:22, DEV: MyWetter, RD: pressure, VAL: 1003
2021.04.29 14:55:19.920 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 13:52:23, DEV: MyWetter, RD: pressure, VAL: 1003
2021.04.29 14:55:19.921 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 14:22:23, DEV: MyWetter, RD: pressure, VAL: 1003
2021.04.29 14:55:19.922 5: LogSQLITE - SQL-result -> PID: 32364, TS: 2021-04-29 14:52:23, DEV: MyWetter, RD: pressure, VAL: 1003
2021.04.29 14:55:19.923 4: LogSQLITE - PID: 32364, rows count: 30
Die Datensätze mit der PID: 32367 gehören zu der parallelen DB-Abfrage die bereits etwas früher gestartet wurde.
Liegt in meinem contrib.
Hallo zusammen,
gibt es Einwände die Testversion einzuchecken da sie zumindest das beschriebene Problem bei
Philip (fraggle777) wohl offensichtlich gelöst hat ?
Bei mir gibt es nach wie vor keinerlei Auffälligkeiten.
fraggle777 ??
Grüße und einen schönen Feitertag,
Heiko
Oh je, jetzt hat es so lange problemlos funktioniert, aber genau seit heute habe ich wieder Probleme :'(
Danke für die Info. Aber dann kann ich mir beim besten Willen kein Prob mitvdem SVG Funktion vorstellen. ::) Sonst sollte das Prob permanenter auftreten.
Kann ich mir eigentlich auch nicht vorstellen. Es hat ja jahrelang ohne Probleme funktioniert, bis ich meine Datenbank neu gemacht habe.
Guten Morgen,
habe die Version jetzt aber dennoch eingecheckt weil sie erweiterte Log-Informationen (PID) für die Fehlersuche enthält.
Ist dann morgen früh im Update enthalten.
Grüße,
Heiko