epgsearchs erstellt keine Suchtimer mehr: Error in search template settings

  • Hi,


    ich hab ein Problem mit dem epsearch-plugin: Es werden keine Suchtimer mehr erzeugt. Manuell an der Konsole erhalte ich folgendes:


    Code
    vdr:/var/lib/vdr/plugins/epgsearch# svdrpsend PLUG epgsearch 'NEWT 1:8:2011-05-06:2105:2225:50:99:Serie~The Closer~06.05.11-Voreilige Schl.:<epgsearch><channel>8 - VOX</channel><searchtimer>The Closer</searchtimer><start>1304708700</start><stop>1304713500</stop><s-id>0</s-id><eventid>410861</eventid></epgsearch>'
    220 vdr SVDRP VideoDiskRecorder 1.7.18; Sun May  1 14:48:38 2011; UTF-8
    901 Error in search template settings
    221 vdr closing connection


    Im Syslog erscheint dagegen nur :

    Code
    May  1 14:56:25 vdr vdr: [7098] EPGSearch: command 'NEWT 1:8:2011-05-06:2105:2225:50:99:Serie~The  Closer~06.05.11-Voreilige Schl.:<epgsearch><channel>8 -  VOX</channel><searchtimer>The  Closer</searchtimer><start>1304708700</start><stop>1304713500</stop><s-id>0</s-id><eventid>410861</eventid></epgsearch>' failed
    May  1 14:56:25 vdr vdr: [7098] EPGSearch: error connecting to socket!


    Ich habs auch schon mit einem Update des VDR probiert (war vorher 1.7.17, jetzt 1.7.18 ), ohne Erfolg. Ebenso hab ich alle Seach-Templates gelöscht, was allerding auch keine abhilfe brachte.


    Ich bin nun ratlos wie man die EPG-Seach-Suchtimer wieder ans laufen bekommt?

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

    Einmal editiert, zuletzt von Negge ()

  • Hi,


    ich hab das Problem mitlerweile lösen können. Ab VDR 1.7.15 ist nicht mehr port 2001, sondern port 6419 der Richtige. Damit gehts. Muss beim letzten Update schief gegangen sein, aber die Timer reichten wohl noch weit genug.

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

  • In den Plugineinstellungen. Einstellungen -> Plugins -> epgsearch -> Suche und Suchtimer.


    cu

  • Leider nicht verstanden - bitte konkretisieren:
    Ist da ein Programm gemeint, welches ich aufrufen soll und dort diese Schritte unternehmen soll?


    Ich habe hier (seit Jahren) VDR und vdradm-am. Allein über letzteres bediene ich VDR. Insoweit sind mit im Moment leider keine Programme bekannt, wo ich die empfohlenen Schritte tun könnte.


    Es würde im Grunde auch reichen, wenn ich die entsprechende Konfigurationsdatei erfahre. Dann würde ich das dort händisch erledigen.

  • Ist da ein Programm gemeint, welches ich aufrufen soll und dort diese Schritte unternehmen soll?


    Nein, das sollst du im Menu einstellen. Das du sowas nicht hast solltest du dazu sagen ;)


    Schau einfach mal ob die die Einstellung in der setup.conf des VDR oder in den Configdateien von epgsearch (Im Unterverzeichnis "epgsearch" des Pluginconfig Dirs) findest.


    cu

  • Wenn ich alles erzählen würde, was ich nicht habe - das würde wohl das Forum sprengen. :]
    Also schauen wir mal lieber, was ich habe: Nach einem Systemupdate von 8.04 auf 10.04 gab es Ärger. Auf Hinweis: Fremdpakete VDR und kaffeine rein. Das läuft so einigermaßen - aber nicht optimal. Aktuell kommt hinzu, dass epgsearch nicht mehr funktionabel ist.


    In /etc/vdr/* finde ich auf den ersten Blick nichts; weder in setup.conf noch in epgsearch irgendwo: ich hatte die Hoffnung, dass da irgendwo sowas wie "Port 2001" stehen könnte.


    nmap befragen, welche Ports sind eigentlich offen?
    2001, 2004, 3000, 8001.


    Gut, dann mal mit telnet weiter: 2001 und 2004 melden sich als VDR. 3000 wird in den nächsten Tagen meiner fürsorglichen Behandlung anheimfallen, der sagt nicht, wem er gehört. 8001 ist klar: Das ist http von vdradmin-am.


    Meine Suche ist erschwert durch ein Verständnisproblem meinerseits:
    Wer verhandelte mit wem denn bisher auf 2001? Wer von beiden möchte ab sofort auf 6419 verhandeln? Beziehungsweise: Wer spielt auf 2001 eigentlich Server? VDR doch wohl? Wer aber will da (nun wohl nicht mehr) Klient spielen?


    Nachtrag:
    Das sieht mir sowieso hinreichend vermanscht aus: Einerseits /etc/vdr/* , andererseits /var/lib/vdr/* - und in allen Unterverzeichnissen werden fröhlich symlinks ausgetauscht. Nun aber nicht nur in eine Richtung ...

  • Bissher hat der vdr auf Port 2001 gelauscht, aber weil bei neueren Linuxen da gewohnheitsmässig was anderes drauf läuft liegt er jetzt per default bei 6419.


    Aber wo der VDR denn nun lauschen soll wird ihm per Kommandozeile mitgeteilt, bei Debian wird er üblicherweise per Script /etc/init.d/vdr gestartet, Defaultwerte für das liegen in /etc/defaul/vdr.


    Programme die SVDRP nutzen wollen müssen natürlich wissen auf welchen Port der VDR denn nun lauscht, also muss man die passend einstellen.


    Auf Debian liegt die VDR Config üblicherweise unter /etc/vdr und die Pluginconfig unter /var/lib/vdr...



    Aber ich habe gerade für dich nachgeschaut, n der setup.conf (üblicherweise unter /etc/vdr zu finden) steht
    --
    epgsearch.SVDRPPort = 2001
    --


    Das bei gestoppten vdr ändern.



    BTW: Bei der Jammerei fair bleiben ;) Das Leute den VDR ohne OSD benutzen, dafür kann der VDR nix ;)


    cu

  • Aber ich habe gerade für dich nachgeschaut, n der setup.conf (üblicherweise unter /etc/vdr zu finden) steht
    --
    epgsearch.SVDRPPort = 2001

    Einen derartigen Eintrag finde ich in /etc/vdr/setup.conf nicht. Es gibt dort lediglich einen einzigen, der auf epgsearch überhaupt hört. Testweise trug ich dort nun "epgsearch.SVDRPPort = 6419" ein - selbstredend unter Beachtung, dass vdr nicht läuft. Das Ergebnis ist nicht so sehr beeinruckend: nmap (andere Maschine schaut mal) findet weiterhin 2001 offen, von 6419 weiß er nichts.


    Alle mir verdächtigen Verzeichnisse hatte ich schon einem "grep 2001" unterzogen. Da ist (oder ich habe was übersehen) aber nichts. Das ist nun die allerdümmste Voraussetzung: Software setzt default, weil erwartete Option nicht gesetzt wurde. Args.


    Eigentlich wollte ich ein Bonmot einstreuen - also bzgl. der Jammerei. Ich verkneife mir das mal lieber momentan: Ich bin auf dem ganz schmalen Fuß: Das Drecksding tut nicht, was es tun soll. Und ich weiß leider nicht, wo der Schalter ist. Das ist sehr ärgerlich.

  • Naja, irgendwo wird die config schon sein, nicht aufgeben, dann findest du sie ;)


    Schau mal in /etc/init.d/vdr ins Starscript welcher Parameter fürs VDR Konfigverzeichnis übergeben wird.
    ---
    -c dir, --config=dir
    Read config files from directory dir (default is to read them from the video directory).
    ---


    Oder du ermittelst mit "pidof vdr" die PID des laufenden vdr und schaust dann per "cat /proc/<vdr PID>/cmdline" nach.


    cu

  • Zitat

    Naja, irgendwo wird die config schon sein, nicht aufgeben, dann findest du sie


    Das ist schwieriger als erwartet. VDR läuft mit Option -port=2001; das holt er sich von einer Variable $SVDRP_PORT, allerdings finde ich die nirgends. Und so setzt sich das dann fort: Debugging gestaltet sich unerwartet schwierig: Da wird vermittels symlinks fröhlich zwischen Verzeichnissen und runter den Verzeichnissen auch noch mit Dateien hin- und hergelinkt. Und dann kommen auch noch Verzeichnisse ins Rennen, an die denkt man im Traume nicht: Unter /usr/sbin/vdr bzw vdradminam sind noch Scripte, die mit default-Ports daherkommen: Auch da ist unklar, wer denen die Optionen übergibt. Uswusf. Eigentlich wäre an der Stelle ein fetter Rant fällig; der Krempel ist faktisch nicht wartbar. Jedenfalls nicht für jemanden wie mich. Und Updates, die an Optionen in Configs ohne Vorwarnung rumschrauben - sind ausnehmend böse. Mache ich nicht: Andreas hatte mich vor Jahren mal zur Brust genommen; da rantete ich in ähnlicher Sache. Gna.


    Du hattest gesagt, ich darf nicht jammern. An einer Stelle fand ich tatsächlich 2001 - mit dem Ergebnis, dass in der Folge vdr und vdradminam (via Browser Port 8001) nicht mehr zusammenspielten: vdradminam frug dann auch auf 6419 an. SUMMA: vdr sowie vdradminam spielen auf 2001; epgsearch spielt auf 6419. Also muss ich sogar zwei Kandidaten auf 6419 holen.

  • Tja, ich weiss schon warum ich komplett von Quellen gebaut habe ;) Da liegen alle Configs an einen Platz und es gibt nur ein Startscript in /etc/init.d was alles macht.


    Aber du nutzt die e-Tobi Packete? Ich kann mir jetzt garnicht vorstellen das er das so unordendlich macht. Ich würde jetzt erwarten das das alles sehr aufgeräumt und Debian like ist.


    cu

  • Zitat

    Aber du nutzt die e-Tobi Packete?


    Vermutlich nicht; ich kann das im Moment leider schlecht prüfen; Erklärung unten. / Die derzeitigen Pakete sind von launchpad.net. Hilfreich ist vermutlich folgende Erklärung:


    Ich nutze vdr/vdradminam primär als System, welches mir automatisiert ein Videoarchiv füllt. Sekundär schaue ich natürlich "Tim Mälzer" und lösche Tim nach dem Ansehen. Primär aber geht es um ein privates Videoarchiv für Recherchezwecke; sagen wir mal: Tagesschau vor xy Jahren. Insoweit habe ich auch NULL Plan zu Hinweisen der Art Fernbedienung, Schlafzimmerfernseher uswusf: Alles Browser/8001 und vdr.


    Das alles lief auf 8.04 longterm, mit den kleinen Macken lebte ich. Das schwere Update auf 10.04 longterm lief bezogen auf das System schick, Ärger gab es nur bzgl. Kaffeine. Auf Hinweis ebenhier kamen dann zwei Paketquellen von launchpad.net ins Spiel. Vermutlich ein schwerer Fehler: Die eigentliche Idee meinerseits war immer, das System möglichst nahe an den offiziellen Quellen zu führen - und somit auf einige Späßchen zu verzichten: Das ist aus meiner Sicht kein Geikel - sondern ein Produktivsystem, welches jahrelang zu laufen hat: Da wird nicht gespielt oder mal fix "neu installiert".


    Ich könnte insoweit das sicherheitshalber erstellte iso von 8.04 wieder restaurieren und neu updaten. Das ginge. Vermutlich ist aber der bessere Plan, den ganzen VDR-Schmonzes neu aufzusetzen, direkt jetzt auf 10..04 - und so wieder ein sauberes System zu bauen. Dagegen spricht, dass sich das alles in allen möglichen sowie unmöglichen Ecken eingenistet hat; gern darf ich da "cache" auch noch erwähnen. Grummel.

  • Weniger Grummeln, mehr Informationen posten ;)
    Schreib doch einfach nochmal, dass du wohl wie hier angegeben diese Paketquellen nutzt, dann kommt auch keiner auf die Idee, du würdest die originalen etobi-Pakete nutzen...

    Code
    deb http://ppa.launchpad.net/yavdr/stable-vdr/ubuntu lucid main 
    deb-src http://ppa.launchpad.net/yavdr/stable-vdr/ubuntu lucid main 
    deb http://ppa.launchpad.net/mtron/kaffeine-stable/ubuntu lucid main
    deb-src http://ppa.launchpad.net/mtron/kaffeine-stable/ubuntu lucid main


    Den Port für epgsearch kann man doch spielend in der /etc/vdr/setup.conf angeben, das ist die Variable epgsearch.SVDRPPort = 2001
    Dann muss man auch nicht vdradmin-am umkonfigurieren.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Aber Port 2001 kann doch nicht benutzt werden. Hat ja nen Grund warum das geändert wurde, auf aktuellen Linuxen ist der wohl durch was anderes belegt.


    cu

  • Aber Port 2001 kann doch nicht benutzt werden. Hat ja nen Grund warum das geändert wurde, auf aktuellen Linuxen ist der wohl durch was anderes belegt.


    cu


    Mein VDR #1 lauscht für SVDRP noch auf Port 2001. Und Epgsearch läuft bei mir mit dieser Einstellung auch ohne Probleme.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)


  • Mein VDR #1 lauscht für SVDRP noch auf Port 2001. Und Epgsearch läuft bei mir mit dieser Einstellung auch ohne Probleme.


    Seltsam, auf meinem frisch installierten Squeeze wollte der VDR mit der alten Config nicht mehr, dann hatte ich den Port auf die neue "Norm" Umgestellt, dann lief das. Deswegen dachte ich das (weil der Port halt üblicherweise durch was anderes belegt ist) ist der Grund für die Defaultportänderung bei den neuen VDRs.


    cu

  • Hi,


    wenn ich es richtig verstehe, läuft Dein VDR nun auf Port 2001 und vdradmin funktioniert damit auch. Also würde ich das dann der Einfachheit halber auch dabei belassen. Die Änderung des Default-Ports war eh mehr eine "philosophische" Diskussion in der ML ;)
    Somit sollte es nur noch darum gehen, den Port für epgsearch ebenfalls auf 2001 zu setzen. Wenn Du die setup.conf wirklich nicht findest und auch kein OSD hast, dann wäre noch die Fernbedienung von vdradmin eine Notlösung. Du könntest ja darüber in die Plugin-Einstellungen wechseln und den Port eingeben.


    Gruß,
    winni

  • Zitat

    Schreib doch einfach nochmal, dass du wohl wie hier angegeben diese Paketquellen nutzt, dann kommt auch keiner auf die Idee, du würdest die originalen etobi-Pakete nutzen...


    Ich bitte um Entschuldigung. Mein Provider war einen Tag lang unpäßlich, sodass ich mit Netbook im Forum war; da waren die Arbeitsbedingungen etwas eingeschränkt.


    Zitat

    Den Port für epgsearch kann man doch spielend in der /etc/vdr/setup.conf angeben, das ist die Variable epgsearch.SVDRPPort = 2001
    Dann muss man auch nicht vdradmin-am umkonfigurieren.


    Das habe ich nun umgesetzt. Und damit tut er sehr schön. Jedenfalls bis zum nächsten Update. Ich darf mich bei allen freundlich bedanken!


    Bitte noch eine Frage: etobi vs. ppa-lanchpad (beides bezogen auf lucid/64): Kann jemand ganz kurz die Vor- und Nachteile abwägen?

  • Bitte noch eine Frage: etobi vs. ppa-lanchpad (beides bezogen auf lucid/64): Kann jemand ganz kurz die Vor- und Nachteile abwägen?


    Schau dir die Unterschiede einfach an: http://www.henningpingel.de/fi…/vdr/vdr_package_tracker/
    hanno-vdr-lucid vs. yavdr-stable-vdr für Lucid 64-Bit


    Die yaVDR-Repos sind i.d.R. aktueller, d.h. näher an den aktuellen (Entwicklungs-)Versionen des VDR und seiner Plugins dran.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!