epgd mit TVDB API 4
-
-
Dann lasse halt zwei sqld laufen:
Code
Alles anzeigen# my1.cnf # epgd # systemctl enable mysql@1 [mysqld] server-id = 1 bind-address = 192.168.1.4 log-error = /var/log/mysql/mysqld.log secure_file_priv = /var/lib/mysql-files innodb_file_format=Barracuda innodb_file_per_table=ON character-set-server = latin1 innodb_large_prefix = ON datadir = /home/mysql sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
Code
Alles anzeigen# my2.cnf # NextCloud # systemctl enable mysql@2 [client] default-character-set = utf8mb4 [server] skip-name-resolve = 1 innodb_buffer_pool_size = 128M innodb_buffer_pool_instances = 1 innodb_flush_log_at_trx_commit = 2 innodb_log_buffer_size = 32M innodb_max_dirty_pages_pct = 90 query_cache_type = 1 query_cache_limit = 2M query_cache_min_res_unit = 2k query_cache_size = 64M tmp_table_size= 64M max_heap_table_size= 64M slow-query-log = 1 slow-query-log-file = /var/log/mysql2/slow.log long_query_time = 1 [mysqld] server-id = 2 bind-address = 192.168.1.8 port = 3307 socket = /run/mysql2/mysql.sock datadir = /home/database/mysql2 log-error = /var/log/mysql2/mysqld.log character_set_server = utf8mb4 collation_server = utf8mb4_general_ci transaction_isolation = READ-COMMITTED binlog_format = ROW innodb_large_prefix=on innodb_file_format=barracuda innodb_file_per_table=1 !includedir /etc/my2.cnf.d
-
Danke, das muss ich mir mal anschauen. Da tun sich einige Fragen auf:
- Warum 2 verschiedene IP's?
- Warum nicht die epgd-Datenbank als 2.? Auf der ersten laufen noch andere Sachen wie "WebTrees"
- Datadir in /home/mysql; Warum nicht /var/lib/mysql2
- Muss der mysql-Service deaktiviert werden?
- Was ist mit der Performance/Speicherverbrauch wenn 2 Instanzen laufen?
-
- Warum 2 verschiedene IP's?
-> Muss nicht sein, ist hier halt so ausgekommen (aus historischen Gründen).
- Warum nicht die epgd-Datenbank als 2.? Auf der ersten laufen noch andere Sachen wie "WebTrees"
-> Das kannst du machen, wie dir spassig ist - auch das ist hier halt so.
- Datadir in /home/mysql; Warum nicht /var/lib/mysql2
-> Selber Grund - alles historisch. Allerdings würde ich keine Datenbank nach /var/lib packen. Irgendwie gehört sowas da nicht hin, weil man im Normalfall /var/lib in / hat und / eigentlich keine Daten halten sollte. Auch sonst ist ein lib-Verzeichnis nach meinem Verständnis für libs und sonst nix.
- Muss der mysql-Service deaktiviert werden?
-> Macht Sinn, ja.
- Was ist mit der Performance/Speicherverbrauch wenn 2 Instanzen laufen?
-> Das ist ziemlich egal. Das hängt mehr von der Nutzung von Nextcloud ab und da ist es wurscht, ob eine oder zwei Instanzen. EPGD hat eh kaum Ansprüche an die Datenbank.
-
Klasse! Vielen Dank für die Erklärungen. Werde versuchen das bei gelegenheit umzusetzen.
epgd konnte ich am Server schon mal bauen.
-
"Es gibt keinen Grund, warum irgendjemand einen Computer in seinem Haus wollen würde."
Dem stimme ich uneingeschränkt zu, wenn man das so ändert:
"Es gibt keinen Grund, warum irgendjemand *einen* Computer in seinem Haus wollen würde."
-
Hallo und frohe Ostern!
Nach der Aktualisierung meines mariadb-servers auf Version 10.5.15 (lief bis vor einigen Tagen fehlerfrei) und dem Bauen des epgd aus dem git erhalte ich nun folgende Fehlermeldungen:
Code
Alles anzeigenepgd: SQL-Error in 'execute(stmt_execute)' - Lost connection to MySQL server during query (2013) 'Lost connection to MySQL server during query' [select actor_id, episode_id, inssp, lfn, media_content, media_height, media_rating, media_type, media_url, media_width, season_number, series_id, updsp from series_media where actor_id = ? and episode_id = ? and lfn = ? and media_type = ? and season_number = ? and series_id = ?;] Apr 10 14:32:55 fhempi3 epgd: Fatal, lost connection to mysql server, aborting pending actions Apr 10 14:32:55 fhempi3 epgd: SQL-Error in 'find()' - Lost connection to MySQL server during query (2013) Apr 10 14:32:55 fhempi3 systemd[1]: mariadb.service: Main process exited, code=killed, status=6/ABRT Apr 10 14:32:55 fhempi3 epgd: Fatal, lost connection to mysql server, aborting pending actions Apr 10 14:32:55 fhempi3 systemd[1]: mariadb.service: Failed with result 'signal'. Apr 10 14:32:55 fhempi3 epgd: Closing mysql connection and calling mysql_thread_end(12381) Apr 10 14:32:55 fhempi3 systemd[1]: mariadb.service: Consumed 4min 17.720s CPU time. Apr 10 14:32:55 fhempi3 epgd: Trying to re-connect to database! Apr 10 14:32:55 fhempi3 epgd: Calling mysql_init(12381) Apr 10 14:32:55 fhempi3 epgd: SQL-Error in 'connecting to database' - Can't connect to local MySQL server through socket '/run/mysqld/mysqld.sock' (111) (2002) Apr 10 14:32:55 fhempi3 epgd: Fatal, lost connection to mysql server, aborting pending actions Apr 10 14:32:55 fhempi3 epgd: Error, connecting to database at 'localhost' on port (3306) failed Apr 10 14:32:55 fhempi3 epgd: Closing mysql connection and calling mysql_thread_end(12381) Apr 10 14:32:55 fhempi3 epgd: Could not access database 'localhost:3306' Apr 10 14:32:55 fhempi3 epgd: Could not access database 'localhost:3306' (tried to open vdrs) Apr 10 14:32:55 fhempi3 epgd: Retry #1 failed, retrying in 60 seconds! Apr 10 14:32:55 fhempi3 epgd: Closing mysql connection and calling mysql_thread_end(12381) Apr 10 14:32:56 fhempi3 epgd: Trying to re-connect to database! Apr 10 14:32:56 fhempi3 epgd: Calling mysql_init(12381) Apr 10 14:32:56 fhempi3 epgd: SQL-Error in 'connecting to database' - Can't connect to local MySQL server through socket '/run/mysqld/mysqld.sock' (111) (2002) Apr 10 14:32:56 fhempi3 epgd: Fatal, lost connection to mysql server, aborting pending actions Apr 10 14:32:56 fhempi3 epgd: Error, connecting to database at 'localhost' on port (3306) failed Apr 10 14:32:56 fhempi3 epgd: Closing mysql connection and calling mysql_thread_end(12381)
Wenn ich den epgd manuell starte, holt dieser auch epg-Daten ab. Es kommt zu der oben dargestellten Fehlermeldung. Dann kommt es dazu, dass der Server nicht mehr konstant durchläuft und in regelmäßigem Abstand neu gestartet wird. Schalte ich den epgd ab, läuft die mariadb störungsfrei durch.
Die mariadb wird parallel auch von einer Nextcloud-Instanz verwendet. Ich hänge die mariadb.cnf zur Erläuterung an (vielleicht kommt es dadurch zu unterschiedlichen Konfigurationsanforderungen?!)
Hat jemand eine Idee, wo der Fehler liegen könnte?
-
Die loader plugins hattest du gegen die aktuelle epgd Version gebaut?
-
Eigentlich schon. Zumindest epgd-plugin-tvm und epgdata hatte ich ebenfalls neu gebaut.
-
epgdata ist doch out-of-order? Würde ich deaktivieren. Und falls noch ein altes tvsp-Plugin (nicht neu gebaut) rumkullert, auch aktualisieren oder weg damit.
Den epglv auch aktualisiert? Das klemmte irgendwie nach dem mariadb-update bei mir, ich glaub ich mußte den Ordner für epglv "rumbasteln".
-
Danke für den Hinweis! Aber leider schmiert die mariadb auch mit dem neu gebauten epglv weiterhin ab. Habe aber an epglv keine Änderungen vorgenommen, sondern nur ein "make install" in diesem Verzeichnis ausgeführt. Hast Du dort für die mariadb noch was angepasst?
Code
Alles anzeigenpr 11 20:43:23 fhempi3 epgd: Update of series and episodes done in 23 s, downloaded 0.000 KB Apr 11 20:43:24 fhempi3 epgd: --------------------- Apr 11 20:43:24 fhempi3 epgd: Series for 6543 new events to scrap Apr 11 20:43:24 fhempi3 epgd: Series episode 1 / 6543 scraped, continuing ... Apr 11 20:43:25 fhempi3 epgd: Series 'Zu Tisch' not found by aliases, using first of (1) search results -> 'Cuisines des terroirs'(140511) Apr 11 20:43:27 fhempi3 epgd: lookup 140511/22/9 'Kastilien - León - Spanien' Apr 11 20:43:31 fhempi3 epgd: lookup 291180/8/2 'Ein schwarzer Tag' Apr 11 20:43:31 fhempi3 epgd: lookup 291180/17/19 'Hals über Kopf' Apr 11 20:43:31 fhempi3 epgd: lookup 72073/4/9 'Das Schwert des Kahless' Apr 11 20:43:34 fhempi3 epgd: lookup 167231/18/1 'Stolpersteine' Apr 11 20:43:34 fhempi3 epgd: lookup 369212/2/8 'Auge um Auge …' Apr 11 20:43:34 fhempi3 epgd: SQL-Error in 'execute(stmt_execute)' - Lost connection to MySQL server during query (2013) 'Lost connection to MySQL server during query' [select actor_id, episode_id, inssp, lfn, media_content, media_height, media_rating, media_type, media_url, media_width, season_number, series_id, updsp from series_media where actor_id = ? and episode_id = ? and lfn = ? and media_type = ? and season_number = ? and series_id = ?;] Apr 11 20:43:34 fhempi3 epgd: Fatal, lost connection to mysql server, aborting pending actions Apr 11 20:43:34 fhempi3 epgd: SQL-Error in 'find()' - Lost connection to MySQL server during query (2013) Apr 11 20:43:34 fhempi3 epgd: Fatal, lost connection to mysql server, aborting pending actions Apr 11 20:43:34 fhempi3 epgd: Closing mysql connection and calling mysql_thread_end(25664) Apr 11 20:43:34 fhempi3 epgd: Trying to re-connect to database! Apr 11 20:43:34 fhempi3 epgd: Calling mysql_init(25664) Apr 11 20:43:34 fhempi3 systemd[1]: mariadb.service: Main process exited, code=killed, status=6/ABRT Apr 11 20:43:34 fhempi3 epgd: SQL-Error in 'connecting to database' - Can't connect to local MySQL server through socket '/run/mysqld/mysqld.sock' (111) (2002) Apr 11 20:43:34 fhempi3 systemd[1]: mariadb.service: Failed with result 'signal'. Apr 11 20:43:34 fhempi3 epgd: Fatal, lost connection to mysql server, aborting pending actions Apr 11 20:43:34 fhempi3 systemd[1]: mariadb.service: Consumed 2min 54.542s CPU time. Apr 11 20:43:34 fhempi3 epgd: Error, connecting to database at 'localhost' on port (3306) failed Apr 11 20:43:34 fhempi3 epgd: Closing mysql connection and calling mysql_thread_end(25664) Apr 11 20:43:34 fhempi3 epgd: Could not access database 'localhost:3306' Apr 11 20:43:34 fhempi3 epgd: Could not access database 'localhost:3306' (tried to open vdrs) Apr 11 20:43:34 fhempi3 epgd: Retry #1 failed, retrying in 60 seconds!
-
Was sagt das mysql-Log dazu (mysql/error.log) bzw. nur "systemctl status mariadb/mysql" nach dem Ausfall des Servers?
Startet der dann selbst wieder bzw. ist im Service ein Restart= Parameter gesetzt?
-
kannst du mal versuchen von der epg2vdr DB ein fullbackup rauszufahren - ich hatte das schon mal das eine Tabelle nach einem Stromausfall defekt war, das Backup sollte dann an der Stelle auch stolpern.
Gerade wenn du sagst der Server wäre nicht mehr ansprechbar gewesen...
-
Es sieht so aus, als ob es hier einen Speicherüberlauf bei der mariadb gibt:
Code
Alles anzeigenpr 23 13:51:57 fhempi3 kernel: [1300236.372612] Out of memory: Killed process 20666 (mariadbd) total-vm:540068kB, anon-rss:229984kB, file-rss:0kB, shmem-rss:0kB, UID:109 pgtables:318kB oom_score_adj:0 Apr 23 13:52:01 fhempi3 systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL Apr 23 13:52:01 fhempi3 epgd: SQL-Error in 'execute(stmt_execute)' - Lost connection to MySQL server during query (2013) 'Lost connection to MySQL server during query' [select actor_id, episode_id, inssp, lfn, media_content, media_height, media_rating, media_type, media_url, media_width, season_number, series_id, updsp from series_media where actor_id = ? and episode_id = ? and lfn = ? and media_type = ? and season_number = ? and series_id = ?;] Apr 23 13:52:01 fhempi3 systemd[1]: mariadb.service: Failed with result 'signal'. Apr 23 13:52:01 fhempi3 epgd: Fatal, lost connection to mysql server, aborting pending actions Apr 23 13:52:02 fhempi3 systemd[1]: mariadb.service: Consumed 12min 38.694s CPU time. Apr 23 13:52:02 fhempi3 epgd: SQL-Error in 'find()' - Lost connection to MySQL server during query (2013) Apr 23 13:52:02 fhempi3 epgd: Fatal, lost connection to mysql server, aborting pending actions Apr 23 13:52:02 fhempi3 epgd: Closing mysql connection and calling mysql_thread_end(15839) Apr 23 13:52:02 fhempi3 epgd: SQL-Error in 'store()' Apr 23 13:52:02 fhempi3 epgd: SQL-Error in 'store()'
Die Folge ist, dass der Server abgeschossen wird und dann neu gestartet wird.
Das ganze scheint nach dem Aufruf von "mergeepg" zu passieren.
Codepr 23 13:57:12 fhempi3 epgd: Calling sd_notify(STATUS=Ready) Apr 23 13:57:12 fhempi3 epgd: Starting 'update' episode download ... Apr 23 13:57:13 fhempi3 epgd: Connected to eplist server at 'www.eplists.de' Apr 23 13:57:13 fhempi3 epgd: Requesting episode changes of last 121 minutes Apr 23 13:57:33 fhempi3 epgd: Error: SVDRPCL: Timeout waiting server reply 'www.eplists.de' Apr 23 13:57:33 fhempi3 epgd: Received 0 episode files Apr 23 13:57:33 fhempi3 epgd: Update episodes.combinedcomp Apr 23 13:57:33 fhempi3 epgd: Starting episode lookup ... Apr 23 13:57:41 fhempi3 epghttpd: SQL-Error in 'SELECT SYSDATE();' - MySQL server has gone away (2006) Apr 23 13:57:41 fhempi3 epghttpd: Fatal, lost connection to mysql server, aborting pending actions
Das mysql error.log zeigt Folgendes:
Code
Alles anzeigen2023-04-23 14:00:20 0 [ERROR] InnoDB: Space id and page no stored in the page, read in are [page id: space=20885, page number=0], should be [page id: space=20885, page number=262144] 2023-04-23 14:00:20 0 [Note] Plugin 'FEEDBACK' is disabled. 2023-04-23 14:00:20 0 [Note] InnoDB: Rolled back recovered transaction 90867803 2023-04-23 14:00:20 0 [Note] InnoDB: Rollback of non-prepared transactions completed 2023-04-23 14:00:20 0 [Note] Server socket created on IP: '192.168.178.28'. 2023-04-23 14:00:20 0 [Note] Reading of all Master_info entries succeeded 2023-04-23 14:00:20 0 [Note] Added new Master_info '' to hash table 2023-04-23 14:00:20 0 [Note] /usr/sbin/mariadbd: ready for connections. Version: '10.5.15-MariaDB-0+deb11u1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 Raspbian 11 2023-04-23 14:00:24 0 [Note] InnoDB: Buffer pool(s) load completed at 230423 14:00:24 2023-04-23 14:01:53 6 [Note] InnoDB: Resetting invalid page [page id: space=20885, page number=262144] type 8 to 9 when flushing. 2023-04-23 14:01:55 6 [ERROR] InnoDB: Space id and page no stored in the page, read in are [page id: space=20885, page number=0], should be [page id: space=20885, page number=262144] 2023-04-23 14:01:55 0x607cdf80 InnoDB: Assertion failure in file ./storage/innobase/btr/btr0cur.cc line 7391 InnoDB: Failing assertion: block != NULL InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to https://jira.mariadb.org/ InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/ InnoDB: about forcing recovery. 230423 14:01:55 [ERROR] mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. To report this bug, see https://mariadb.com/kb/en/reporting-bugs We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. Server version: 10.5.15-MariaDB-0+deb11u1 key_buffer_size=16777216 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=3 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 351836 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x377c470 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x607cd90c thread_stack 0x4ac00 Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x3bc2ed0): insert into series_media set actor_id = ?, episode_id = ?, inssp = ?, lfn = ?, media_content = ?, media_height = ?, media_rating = ?, media_type = ?, media_url = ?, media_width = ?, season_number = ?, series_id = ?, updsp = ? Connection ID (thread ID): 6 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains information that should help you find out what is causing the crash. Writing a core file... Working directory at /var/lib/mysql Resource Limits: Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size 0 unlimited bytes Max resident set unlimited unlimited bytes Max processes 6858 6858 processes Max open files 32768 32768 files Max locked memory 8388608 8388608 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 6858 6858 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us Core pattern: core
Ich meine, dass ich InnoDB für den Betrieb von Netxcloud benötige, welches auch auf die mariadb zugreift, in die auch die epg-Daten geschrieben werden.
-
Wie viele speicherressourcen hat die dB denn und wie viele Sender hast du in der kanalliste
-
Es sind nur 30 Sender in der channelmap.
Für die mariadb sind folgende Einstellungen in der "50-server.cf" gesetzt:
key_buffer_size = 16M
max_allowed_packet = 16M
thread_stack = 299K
thread_cache_size = 256
query_cache_limit = 1M
query_cache_size = 16M
-
-
Ich habe aber an anderer Stelle nicht festgestellt, dass die Platte korrupt ist.
-
Ich habe aber an anderer Stelle nicht festgestellt, dass die Platte korrupt ist.
Naja, evtl. Memory?
-
Naja, evtl. Memory?
Ich denke, dass es dies nicht die Ursache ist. Alle anderen Dienste laufe ja ohne Probleme.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!