Nicht, dass man DNS bräuchte bei IP - aber im Log steht halt "resolve" auch bei der IP (vielleicht kann ich mir das Mal im Quelltext ansehen
Ich habe mir das im Quelltext von Nexus 20.2 angesehen. Meine Vermutung, dass es an Name resolution liegt, war falsch (hätte ich eigentlich auch ohne Quelltext sehen können ...). In der Tat macht Kodi kein "resolve" bei reiner IP - da ist nur der Log-Text ("connect replacing configured host 192.168.222.10 with resolved host 192.168.222.10") missverständlich.
Was im Programm (im Quelltext) passiert, zwischen dieser Meldung, und 20 s später ("MYSQL: Connected to version 10.3.29-MariaDB") ist nur wenig vereinfacht beschrieben:
1. mysql_init() - MySQL API Funktion, halte ich für unkritisch, macht nix im Log. Macht noch keine Verbindung zur DB, nur intern im Client
2. mysql_ssl_set() - MySQL API Funktion, halte ich für unkritisch, macht nix im Log
3. WakeUpHost() - Kodi interne Funktion für WOL, kann je nach Situation was loggen - sieht man hier im Log aber nix.
4. mysql_real_connect() - MySQL API Funktion
Und jetzt sind 20 s vergangen im Log seit der Meldung mit "resolved". Wirklichen Traffic zur DB gab es noch nicht, nur administratives Zeugs/Anmeldung. Meine Verdächtigen: 3. und 4. Bei 3. im Quelltext gibt es in einem Schritt ein Default Timeout von 20 s!
Was du testen könntest: WOL ausschalten in Kodi, falls das an (Wake on lan - Official Kodi Wiki)
Und falls du dich damit auskennst, einen DB-Connect außerhalb von Kodi probieren (das würde 4. adressieren). Da kann ich dir aber auf Anhieb nicht helfen.
Jetzt OT zum eigentlichen Problem.
Was mir auffiel und mich überraschte: Kodi scheint (z.B. für Nameresolution) lediglich IPv4 Funktionen zu nutzen, und nicht die moderneren (mittlerweile auch schon Jahrzehnte-alten) Funktionen die mit IPv4 und IPv6 funktionieren. Z.B. gethostbyname() (IPv4 only) statt getaddrinfo() (IPv4 und IPv6). Ist es wirklich so, dass Kodi nicht designed/implementiert ist, mit IPv6 zu funktionieren? Z.B. @DaVu könnte das wissen.
Was mir beim Durchsehen des Quelltexts noch auffiel, ein Fehler in einer - welch Ironie - Fehlerbehandlungs-Routine. (Oder ich habe grade Aussetzer bzgl. meiner C++ Kenntnisse). Hat hier mit dem Problem aber nix zu tun. Vielleicht hat jemand Lust das zu verifizieren und Pull Request zu kreieren.
int MysqlDatabase::setErr(int err_code, const char* qry)
{
switch (err_code)
{
// Einiges gelöscht zur Veranschaulichung hier im Forum - buers
[...]
default:
// char array err mit lokaler Gültigkeit innerhalb des switch-Blocks
char err[256];
snprintf(err, 256, "Undefined MySQL error: Code (%d)", err_code);
// Zeiger auf das Array mit lokaler Gültigkeit im Block
error = err;
}
// Zeiger wird hier genutzt, worauf gezeigt wird hat aber außerhalb des Blocks keine Gültigkeit!
error = "[" + db + "] " + error;
[...]
return err_code;
}Korrekt wäre err außerhalb des switch-Blocks zu deklarieren.
int MysqlDatabase::setErr(int err_code, const char* qry)
{
char err[256];
switch (err_code)
{
[...]
default:
snprintf(err, sizeof err, "Undefined MySQL error: Code (%d)", err_code);
error = err;
}
[...]
}Datei xbmc/dbwrappers/mysqldataset.cpp
