[behoben, aber nicht verstanden][epgd] keinerlei EPG-Infos mehr via WebIF oder VDR, aber in der DB

  • Ho *,

    ich habe aktuell (seit letzter Woche) das Problem, dass weder über das WebIF Programminfos verfügbar sind, noch Daten an den VDR weiter gereicht werden. Die EPG-Daten wurden immer scheinbar weniger und waren am Ende ganz weg.

    In der Datenbank sind allerdings alle Events und auch die Channelmaps vorhanden, wenn man sich das Ganze per SQL ansieht.

    Ich habe auch scon mal alle Tabellen truncated und alles neu einlesen lassen. Dabei treten keine Fehler auf, lt. Journal läuft alles sauber durch. Danach sind auch die Tabellen wieder gefüllt - nur das Ursprungsproblem ist leider nach wie vor da.


    Hat Jemand ne Idee?

    Hat sich evtl. die Datenstruktur von epgdata wieder mal geändert, wo meine EPG-Daten primär herkommen?


    Danke und ciao.

    Michael.

  • Was sagt denn das Syslog? Sind epgd und epg2vdr auf dem selben Rechner?

    Kürzlich irgendwo ein Update gemacht?

    Epgdata-Abo abgelaufen?


    Gruß Jan

    1:Dell PoweEdge T20; Xeon E3-1225 v3; 16GB RAM; Proxmox 5.4; MLD 5.4 als Server; Cine S2;
    2:Intel NUC i3 Passiv; 4GB RAM; 120GB SSD; easyvdr 3.5 als client; Harmony Hub

    3:Raspberry Pi 3B; MLD

  • Was sagt denn das Syslog? Sind epgd und epg2vdr auf dem selben Rechner?

    Kürzlich irgendwo ein Update gemacht?

    Epgdata-Abo abgelaufen?


    Gruß Jan

    Danke für deine Antwort, aber wie geschrieben: Keinerlei Fehler in irgendeinem Log - weder im Journal, aka syslog noch im Log von epgd selber.

    Kein Update, kein abgelaufenes Abo, da auch alles geholt und in die DB geschrieben wird nach einem Truncate der entsprechenden Tabellen.

    Ich hab jetzt *alle* bis auf die für mich wesentlichen (vor allem searchtimers und parameters) Tabellen truncated, danach hat epgd alles brav wieder eingelesen und jetzt geht auf einmal wieder alles.

    Kann man so machen, macht aber keinen Spass.

    Mich würde nur mal interessieren, was sich da verstrubbelt hatte, denn wie gesagt - gemeldet wurden keinerlei Fehler.


    Ciao.

    Michael.

  • Falls noch irgendjemand über das epgd-tool hinaus irgendwelche backup/recovery/reset Routinen braucht, hänge ich mal mein Script an.

    Wie immer - ohne Gewähr.


  • Hi,


    genau das habe ich gerade gesucht für ein Upgrade von einem alten epgd.

    Ich hätte noch die timers und timersdone mitgenommen, aber nach kurzem Nachdenken wird die timers nicht funktionieren, aufgrund der Referenz zur eventid.

    Und ich denke, die Timer werden später von allen VDR noch eingesammelt.

    Bei der timersdone habe ich auf die Schnelle nichts gefunden, was dagegen spricht, oder übersehe ich etwas?


    Danke und Grüße

    Zabrimus

  • ja timersdone sollte man übernehmen. Dazu noch users, parameters und searchtimers.

    Im Prinzip die Tabellen welche beim droppen mittels des Skripts epgs-dropall gesichert werden.

  • und zu der Timers Tabelle gibt das drop Skript das hier aus:

    Code
    1. echo "Now you have two choices for timers and timersdone (only the pending ones):"
    2. echo " 1. Automatic (without dropping the timers table):"
    3. echo " All created timers will be marked for delete action to force VDRs to remove them"
    4. echo " 2. Drop table timers - you have to cleanup the timers.conf of your VDRs by hand"
    5. echo " "
    6. echo "In both cases all still pending timers will removed from timersdone to force epgd to create it again!"
    7. echo " "
    8. echo "Proceed with 1 (otherwise 2 will done)? [y/N] "

    kurzum das verwenden dieses Skriptes ist zum 'platt' machen eine gute Idee. Ich versuche auch immer daran zu denken das zu pfelgen wenn sich etwas ändert.

  • und zu der Timers Tabelle gibt das drop Skript das hier aus:
    [...]

    kurzum das verwenden dieses Skriptes ist zum 'platt' machen eine gute Idee. Ich versuche auch immer daran zu denken das zu pfelgen wenn sich etwas ändert.

    Was mache ich eigentlich falsch, wenn ich von den epgd-Tools gesagt bekomme "Access denied for user 'epg2vdr'@'localhost' (using password: YES"?

    Ich habe DBPass in epgd.conf geändert, aber eigentlich auch im passenden File "~/.ssh/mysqlpasswd" die Variable "PASSWORD" entsprechend gesetzt.

    Irgendwie ist mir nicht klar, wie hier PASSWORD und MYSQL_PWD im Script zusammenspielen sollen.

  • Du machst nichts falsch, das im .ssh Ordner ist für das epgd-tool welches einen anderen Autor hat als der epgd und die restlichen Skripte, daher etwas unterschiedlich ticken.


    Die Skripte von mir gingen bislang immer stumpf davon aus dass das Passwort 'epg' ist und nicht geändert wurde :saint:


    Ich habe es jetzt (git) so erweitert das die Variable MYSQL_PWD sofern schon gesetzt nicht mehr geändert wird. Diese Variable wird - sofern gesetzt - von dem mysql Tools entsprechend auch dem 'mysql' Kommando herangezogen.


    Soll heißen bei abweichendem Passwort MYSQL_PWD setzen.


    Grüße Jörg

  • Hm, ich peils grad net - ich meinte die Scripten in <src>/scripts.

    Welche meinst du? Die anderen im selben Verzeichnis bis auf epgd-tool?


    Und noch ne Frage:

    Magst du deine Scripten nicht auch ein wenig genereller bauen, also nicht alle Views und Tabellen namentlich aufführen, sondern sowas wie ich in meinem Script da oben gemacht habe, d.h. die Views und Tabellen dynamisch zusammensuchen? Das mit dem "if exists" werde ich bei meinem Script auch noch einbauen - das kannte ich noch nicht.


    Danke und ciao.

    Michael.

  • Zitat

    Welche meinst du? Die anderen im selben Verzeichnis bis auf epgd-tool?

    ja

    Zitat

    Magst du deine Scripten nicht auch ein wenig genereller bauen, also nicht alle Views und Tabellen namentlich aufführen, sondern sowas wie ich in meinem Script da oben gemacht habe, d.h. die Views und Tabellen dynamisch zusammensuchen? Das mit dem "if exists" werde ich bei meinem Script auch noch einbauen - das kannte ich noch nicht.

    nein hab ich eigentlich nicht vor, welchen Vorteil hätte das beim verwenden?

  • nein hab ich eigentlich nicht vor, welchen Vorteil hätte das beim verwenden?

    War nur so ne Idee, wollte dir nicht zu nahe treten.

    Beim Verwenden ist es nicht von Vorteil, aber evtl. beim Pflegen des Codes und beim Lesen durch Dritte.


    Ciao.

    Michael.

  • kein Problem so hatte ich es auch nicht aufgefasst wollte nur das Ziel verstehen.


    Das könnte man machen aber nicht mit nur einer Tabellen Liste, es gibt eine Gruppe die immer gedropt wird und eine andre nur auf wunsch.

    Dann noch eine Gruppe von Tabellen mit User Eintellungen die noch seltener gedropt werden sollen und dann noch eine mit vermutlich überschneidender Menge an Tabellen welche man vermutlich vorher sichern möchte.


    Finde es für mich so recht einfach zu pflegen.

  • Ok :)