Beiträge von minixjr

Ja, das ist was ich auch erwarten würde.

OK, alles klar.
Vielleicht liegt es an der Quelle.
Füg mal Deiner Selektion ", e.source" hinzu.

Hast Du mal die Konfigurationsdateien von epgsearch gecheckt, speziell epgsearch.conf?
epgsearch

Ich bin mir nicht sicher ob "events" die richtige Tabelle ist um das zu prüfen.
In meinem Verständnis werden die "events" in "useevents" zusammengefasst, wenn hier doppelte vorhanden sind, dann stimmt was nicht.
Was zeigt denn:

SELECT FROM_UNIXTIME( cnt_starttime  )
        , u.sub_title
        , u.sub_shorttext 
        , u.cnt_channelid
        , u.cnt_masterid 
        , u.cnt_eventid
FROM    useevents u
WHERE    u.sub_title like '%eureka%'
ORDER BY
        u.cnt_starttime ASC, u.cnt_channelid 
ASC;

In Deinem Suchtimer ist "Wiederholungen vermeiden" aktiv?
Wenn bei mir mal was durcheinander kommt, lösche ich auch die timers.conf auf den Systemen und dann auch aus der epgd History.

Hallo georg3003,
habe noch das angehängte Skript gefunden.
Keine Ahnung ob das funktioniert.
Viel Glück
Frank

Hallo zusammen,
zur Info, vielleicht betrifft es ja jemanden.

https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e2

oss-security - backdoor in upstream xz/liblzma leading to ssh server compromise

https://www.heise.de/news/Hint…Verbindungen-9671317.html
Soweit ich das verstehe dürften hauptsächlich Distributionen betroffen sein, die als Rolling-Release laufen, aber so ganz sicher ist sich da wohl grade niemand.
Trotzdem schöne Ostern
Frank

Dann ist das Wochenende ja gesichert, WAF wieder OK.

Wenn Du mit dem User angemeldet warst, dann macht es Sinn, dass er in dem Home-Verzeichnis sucht.
Mit einem anderen User kann dann aber auch der Fehler ein völlig anderer sein.

Der trace sagt ja am Ende "ERROR: Unable to create GUI. Exiting", das könnte einfach am "falschen" User liegen.

Bleibt für mich die Frage, warum wird in .xbmc gesucht und nicht .kodi (war bei mir auch mit boinic schon .kodi)

Kannst Du strace vielleicht mit dem Aufruf aus Post #9 kombinieren?

Nicht das mir das jetzt wirklich was sagen würde, aber dieser Eintrag irritiert mich etwas.
stat("/home/daniel/.xbmc", 0x7ffdce347520) = -1 ENOENT (No such file or directory)
Kodi wird doch normalerweise als User vdr gestartet oder nicht? Was sucht er dann in diesem Verzeichnis?

Da bin ich dann auch ratlos.
Bliebe noch tracen, aber da kann ich leider auch nicht helfen

Viel Erfolg

Wenn keine i386 Pakete gefunden werden, ist das schon mal gut.

Zitat von davie2000

Dachte, ich hätte das in Kodi "aus ZIP" installiert

Kann ja sein, vielleicht wird da irgendwie ein deb Paket installiert.

Zitat von davie2000

Könnte es was bringen, wenn ich das kodi-inputstream-adaptive mal deinstalliere?

Mal alles zu deinstallieren, was nicht unbedingt notwendig ist, wäre auch meine Vorgehensweise.

Probieren kannst Du auch ob es einen Unterschied macht, wenn Du Kodi manuell startest.
Ich habe es bei mir mit focal per ssh so gemacht:

--> Vdr läuft und Du hast ein Bild, dann per ssh als normaler user verbinden

sudo -u vdr svdrpsend plug softhddevice deta
sudo -u vdr svdrpsend remo off
sudo -u vdr XDG_RUNTIME_DIR=/run/user/$(id -u vdr) systemctl --user start kodi

Das Paket kodi-inputstream-adaptive wurde manuell installiert oder vielleicht aus einem Repository, das es nicht mehr gibt.

Vielleicht stimmt da was nicht.
Ansonsten fällt mir auf, dass Mulltiarch aktiv ist, also möglicherweise auch i386 Pakete installiert sind, die u.U. stören.

Kannst Du mit dpkg -l | grep -i i386 prüfen.
Ich habe kein bionic mehr und kann daher nicht prüfen wie es bei mir war. Mit focal sind, mit der yaVDR-Standardinstalltion, keine i386 Paket notwendig und Multiarch nicht aktiv.

Laut Google kann es alles mögliche sein, vom Kernel bis zu einzelnen Bibliotheken, z.B. auch Python.

Kernel glaube ich jetzt eher nicht, dann würde das Problem sicher auch an anderen Stellen auftauchen.
Für eine genauere Analyse müsstest Du das dann aber tracen. Da bin ich aber auch raus.

Findet sich vielleicht noch ein Ansatzpunkt in der apt Historie?

/var/log/apt/history.log

Das die Kodipakete alle aus dem selben Repository kommen, hast Du ja sicher schon gecheckt, nicht das es einen Versionsmischmasch gibt.
Als erstes springt mir da "inputstream + amazon vod" aus Deiner Signatur ins Auge.

Hilft vielleicht das Kodi Logfile?

/var/lib/vdr/.kodi/temp/kodi.log

Ist beim letzten Update vielleicht was schief gelaufen?

sudo apt -f install

(vermutlich nicht sonst hätte er beim -- reinstall was gemeldet)

Super Klasse, Danke.

Wie immer prompte Bedienung

seahawk1986 ,

könntest Du bitte, bei Gelegenheit, einen Blick auf das o.g Repository werfen?

Fast alle Pakete haben den Status "Failed to build"

Oder sollte ich ein anderes Repository für focal nutzen?

Gruß

minixjr

Was genau meinst Du mit

Zitat von cduerr

Allerdings bootet die nfs-Freigabe vom vdrserver nicht.

Ich vermute mal es geht um avahi, bzw. autofs?
Vielleicht hilft dieser Thread?

So ein Ärger.

Dann bin ich leider auch ratlos.

Schade.

Ich will nicht klugscheißen, aber Du bist sicher, dass epgd epghttpd und vdr beendet waren als Du die epg.data gelöscht hast?

Bringen diese beiden Abfragen in Deiner Datenbank noch ein Ergebnis?

SELECT title from events where source = 'epgdata';
SELECT sub_title from useevents where cnt_source = 'epgdata';

Wie sieht denn jetzt so ein Eintrag für den VDR in der channelmap.conf aus?

Ein ähnliches Verhalten, vielfache Wiederholung eines (Such-)Timers habe ich auch wenn ich eine Sendung Suche die kürzer als die Vor- und Nachlaufzeit des Timers ist, z.B Kalkofes Mattscheibe (dauert tlw. nur 5 Minuten)

Wenn ich solche, nicht ganz nachvollziehbaren, Probleme habe, nachdem ich etwas an den EPG Providern geändert habe, lösche ich immer das EPG auf den VDR und lasse es neu einlesen. Die Funktion im VDR OSD (neu laden) hilft hier i.d.R. nicht.

epg und epghttpd stoppen:

systemctl stop epgd epghttpd

Alle VDR stoppen (also auf jedem einzeln auführen):

systemctl stop vdr

Auf jedem VDR die EPG-Daten löschen:

rm /var/cache/vdr/epg.data

Danach epgd, epghttpd und VDR wieder starten:
systemctl start epgd epghttpd

systemctl start vdr

Jetzt sollten die EPG-Daten neu auf die VDR verteilt werden.

Vielleicht einen Versuch wert und die Datenbank wird nicht gelöscht.