Beiträge von udo1toni

    Hallo liebe Mitstreiter!


    Nachdem ich vor einigen Tagen ein apt-get dist-upgrade ausgeführt hatte, verschwand mein geliebter epg. Soweit ich es verstanden habe, liegt das am aktualisierten epg2vdr, der nun Stand vdr 2.2.0 epg2vdr 1.1.56-GIT (24.03.2017) ist. Also habe ich nach Anleitung den aktuellen epgd gebaut (Stand epgd 1.1.114-GIT (23.03.2017) ), zusammen mit dem passenden Plugin. ;)
    Anschließend habe ich die Datenbank gedroppt, neu anlegen lassen und die Funktionen aus mysqlepglv.so neu in MariaDB bekannt gemacht.
    epgd läuft bei mir auf einem debian jessie ohne weitere vdr-Komponenten, was bisher auch wunderbar funktionierte.


    Seit der Umstellung gibt es nun das Problem, dass systemd glaubt, epgd liefe nicht korrekt. Konkret macht sich das so bemerkbar, dass ich, wenn ich epgd mittels sudo systemctl start epgd.service starte, 5 Minuten auf ein Prompt warte, anschließend behauptet systemd, der Dienst sei nicht erfolgreich gestartet worden. Wenn ich aber per sudo journalctl -f ins Journal schaue, sehe ich epgd fröhlich werkeln, auch die Datenbank füllt sich.
    Das eine ist also, dass systemctl status epgd.service folgende Ausgabe ergibt:

    Code
    udo1toni@sql:~$ systemctl status epgd.service
    
    
    ● epgd.service - vdr-epg-daemon manages EPG data in a MySQL database
       Loaded: loaded (/lib/systemd/system/epgd.service; enabled)
       Active: activating (start) since Do 2017-04-06 10:28:59 CEST; 3min 35s ago
     Main PID: 13567 (epgd)
       CGroup: /system.slice/epgd.service
           	└─13567 /usr/bin/epgd -n


    Die andere Konsequenz ist, dass epgd so niemals bis zum Ende durchläuft, weil es ja nach 5 Minuten immer wieder von vorne beginnt. Genauso lässt sich der Dienst auch sauber nicht anhalten (nach systemd-Meinung). Das gleiche Verhalten zeigt epghttpd auf dem gleichen Rechner. Witzigerweise reicht es aber, einfach von der Kommandozeile aus epghttpd aufzurufen und die Seite ist umgehend erreichbar.


    Eine weitere Merkwürdigkeit ist, dass Bilddateien speziell aus tmdb nur ab und zu erfolgreich geladen werden, oft gibt es ein http Code 429, was laut API Doku eine Überschreitung des Downloadlimits wäre. Ich habe mir einen eigenen API-Key besorgt, aber die Fehlermeldung bleibt. Allerdings scheint immer mal wieder eine Datei erfolgreich in der Datenbank zu landen, früher (ich hab es, glaube ich, Anfang 2016 in Betrieb genommen, noch mit der Nicht-epghttpd-Variante) sind die Bilder gefühlt "sofort" in der Datenbank gewesen.


    Irgendetwas muss ich falsch machen, aber ich hab keine Ahnung, wo der Fehler liegt, der epgd-Dienst läuft ja "irgendwie" schon erfolgreich.



    Bei epghttpd habe ich auch noch eine Frage: Muss ich auf den vdr-Rechnern, die die Aufnahmen ausführen, irgendwas konfigurieren, damit epghttpd dort Timer anlegen kann (also wenn ich die Suchtimer im epghttpd anlege)? Wenn epghttpd auf einem anderen Rechner läuft, wie kommen dann die Timer auf die angegebenen vdr-Maschinen? holen die sich die Timer direkt aus der Datenbank, oder muss das irgendwie angestoßen werden? Oder lasse ich die Suchtimer lieber unangetastet, solange meine vdr-Rechner noch nicht auf epghttpd umgestellt sind?

    Ah, jetzt, ja.


    Ich hätte natürlich auch selbst drauf kommen können, dass quasi von jedem Paket, welches benötigt wird, auch die passende dev-Version benötigt wird. Naja, die Doku ist da etwas ... ungenau, weil schließlich einige dev-Pakete explizit angegeben sind, andere aber nicht.


    curl fehlte auch noch, das ist überhaupt nicht erwähnt. Jetzt sieht es aber so aus, als liefe es (jedenfalls wird die Datenbank fröhlich mit Informationen gefüllt) :)


    Der Tipp mit apt-file war jedenfalls super...

    Also, build-essential habe ich natürlich schon installiert :)
    was die Abhängigkeiten betrifft, bin ich mir nicht sicher, ob ich überall das richtige erwischt habe:



    Und die Fehlermeldung sieht heute irgendwie zumindest etwas logischer aus (vielleicht war es gestern einfach zu spät...) aber wo die fehlenden Dateien sein sollen?


    Ich habe in meinem Netz einen Rechner, auf dem ich für verschiedene Anwendungen MariaDB zur Verfügung stelle. Nun dachte ich, dass ich 'einfach' epgd auf diesem Rechner laufen lassen könnte, jedoch handelt es sich um ein debian Jessie als Unterbau, für das ich bisher keine Pakete vdr-epg-daemon finden kann.
    Ich habe auch schon versucht, nach der Anleitung im git-Repository den daemon selbst zu kompilieren, jedoch bricht make direkt mit einem Fehler ab, da ich kein Entwickler bin und die Fehlermeldung eher unspezifisch ist, stehe ich jetzt wie der Ochse vor dem Berg ?(


    Vermutlich suche ich nur falsch und es gibt massig Informationen dazu... hat hier jemand erhellende Informationen extra für mich?

    Ich hab ein seltsames Phänomen.
    Mein Rechner hängt über hdmi (ASUS Nvidia GeForce EN210 SILENT/DI/512MD2) an meinem Verstärker
    (Yamaha RX-575), dessen Ausgang wiederum am Fernseher angeschlossen ist (Loewe Xelos40)


    Weil ich beim Update Probleme hatte, den Stick zum Booten auszuwählen, habe ich die Grafikkarte direkt am Fernseher angeschlossen und fröhlich auf 0.6 upgedatet.


    Nach dem Update habe ich wieder auf den Verstärker umgesteckt. Jetzt funktioniert die Grafikausgabe nur noch, wenn der Rechner beim booten direkt am Fernseher angeschlossen ist. Wenn ich im laufenden Betrieb auf den Verstärker umstecke, funktioniert die Grafik bis zum nächsten booten, ist der Rechner beim booten am Verstärker angeschlossen, gibt's kein Bild mehr.


    Ich gehe jetzt mal davon aus, dass es für dieses Phänomen keine Konfigurationsoption gibt, also werde ich die Karte wohl tauschen müssen. Gibt es da irgendwelche Karten, die keine Probleme bei oben beschriebenem Szenario haben?

    Hallo allerseits,


    irgendwas muss ich falsch gemacht haben...


    Also zuallererst mal ein super großes Lob, die Neuinstallation auf meinen drei Systemen lief vollkommen problemlos, bis auf... ?(


    Auf dem headless Server habe ich - wie vorher auch auf den anderen Systemen - ganz normal yavdr 0.6 vom Stick installiert, was soweit auch gut lief. Da ich verständlicherweise meine alten Aufnamhen behalten wollte, habe ich die alten Partitionen nur vom Installer formatieren lassen, natürlich bis auf die mit den Aufnahmen.
    Nach der Installation war die Platte mit den Aufnahmen nicht eingebunden, was ja erstmal nichts macht. vdr angehalten, umount der Freigaben, die alte Partition unter /srv eingehängt, fertig (auf der Platte sieht es also so aus:


    Nach einem Reboot wurden die Aufnahmen unterhalb video.00/ auch gefunden. Allerdings ist im WFE im linken oberen Quadranten (Titel VDR) bei Disk usage: sum: 0.00GB, used: 6.41GB, free: 0.00GB zu lesen.


    Bei der Partition handelt es sich um ein LVM mit 8TB :D und da ist auch noch ein bisschen Platz drauf. Der vdr nimmt auch schon brav auf der Partition auf, aber warum stimmt die Anzeige so gar nicht?


    Ach ja, an einem anderen vdr habe ich die Aufnahmeplatte direkt unterhalb /srv/vdr/ in ein Verzeichnis video.00 eingebunden, das war allerdings vorher als Symlink vorhanden und verwies auf das Verzeichnis /srv/vdr/video Ich hab die Anleitung jetzt so verstanden, dass es egal ist, wie rum der Symlink geht und habe entsprechend /srv/vdr/video.00 angelegt, dort die Platte gemountet und einen Symlink /srv/vdr/video angelegt, der auf /srv/vdr/video.00 verweist. Ist das korrekt so?

    Ich hole das Thema noch mal hoch...


    Ich dachte immer, dass die Kernelquellen (bzw. die Header) automatisch mit installiert würden? Bis vor kurzem musste ich jedenfalls nicht jedesmal nach einem dist-upgrade die Kernel-Header von Hand nachinstallieren, oder täusche ich mich da?

    Hallo,


    Ich nutze mehrere yavdr, alle sind über gbit-LAN verbunden. Die Aufnahmen liegen normalerweise auf dem yavdr-Server (headless), der so gut wie immer läuft. Seit einigen Wochen ist nun der Zugriff auf die Aufnahmen extrem langsam, wenn ich die Aufnahmeliste aufrufe, passiert mehrere Sekunden scheinbar gar nichts, dann erst erscheint die Liste. Wenn ich in die Verzeichnisstruktur absteige, dauert das Aufrufen jedes Verzeichnisses ebenfalls mehrere Sekunden. Beim Löschen einer Aufnahme aus der angezeigten Liste bleibt die Sicherheitsabfrage stehen, obwohl die Aufnahme schon aus der Ansicht entfernt ist (nur sofern es nicht die letzte Aufnahme der Liste war). Erst wenn ich in der Liste einen anderen Eintrag auswähle, verschwindet die Abfrage wieder.
    Wenn ich die Wiedergabe einer Aufnahme per Back-Taste verlasse, dauert es ca. 10 Sekunden, bis das Live-Signal wieder angezeigt wird, obwohl der betreffende yavdr eine eigene Tunerkarte besitzt. Wenn ich die Wiedergabe per Stop-Taste beende, ist das Bild 'sofort' da (also mit wenigen 1/10sec. Verzögerung).


    Alle yavdr sind Version 0.5 und mittels

    Code
    sudo apt-get update && sudo apt-get dist-upgrade

    auf dem neuesten Stand. Das Problem trat - soweit ich mich erinnere - erstmals mit Kernel 3.2.0-68 auf. Ich habe zu dem Zeitpunkt (wissentlich) nichts außer dem Paket-Update gemacht, also auch keine Idee, was ich falsch gemacht haben könnte. :(


    PS: Ich sollte mal meine Signatur überarbeiten...

    Zum Schluss fehlt noch der zu den yavdr Paketen gehörige Public Key (ID 389216F8 - kann aus einem laufenden yaVDR exportiert werden) welcher auch in dem Verzeichnis abgelegt werden muss.

    Hmm... Ich stehe ehrlich gesagt, auf dem Schlauch. Wie kann ich denn den key exportieren?


    EDIT:Ach mann... wenn man sein Gehirn einschaltet, klappt's auch mit dem Denken...

    Code
    apt-key export 389216F8 >>public.key


    So geht das :)

    Arghh... ich muss irgendwie schlecht gesucht haben. Asche auf mein Haupt!


    Und Danke für die Informationen, die mich trotzdem mit gemischten Gefühlen zurück lassen :)
    Immerhin ist es momentan nur der 2. vdr, so dass ich das morgen Vormittag riskieren kann - zur Not muss ich halt neu aufsetzen ;)

    Wird es dafür (zeitnah) eine Lösung geben? Ich nehme mal an, es ist nicht mit dem

    Code
    sudo apt-get install linux-image-generic-lts-trusty

    getan, oder doch?

    Ich habe yaUsbIR v3 seit ein paar Wochen erfolgreich in Betrieb (als reiner Empfänger). Nun fehlte bei mir (bis heute 8)) eine 5v-Dauerversorgung, weshalb ich erst heute versuchte, dem Modul die Powertaste zum Einschalten beizubringen.
    Mein System ist ein frisch installierter yavdr 0.5a (von Hybrid-Datenträger per USB-Stick installiert - Klasse!).


    Lirc-Support habe ich über die WS eingeschaltet und yaUsbIr (MCE remote) ausgewählt, damit spielte die Fernbedienung sofort.


    Allerdings:

    Code
    udo@vdr-schlaf:~$ irsend SEND_ONCE yaUsbIR_control C_IR 1 1 0 C_END    	
    irsend: timeout
    udo@vdr-schlaf:~$ lircd -v
    lircd 0.9.0

    also fehlt offensichtlich der Patch. Aber irgendwas muss bei der Beschreibung zum patchen fehlen - wahrscheinlich ist es zu naheliegend, so dass nur jemand mit Halbwissen drüber stolpert ;)


    lirc-0.9.0_ya_usbir_v3.4.diff liegt in meinem home-Verzeichnis (dort ist es beim entpacken gelandet). rufe ich es von dort mit

    Code
    patch -p1 lirc-0.9.0_ya_usbir_v3.4.diff

    auf, passiert gar nichts - nach einigen Minuten warten beende ich den Versuch mit Strg-C. - Ein Verzeichnis lirc-0.9.0 habe ich nach dem Entpacken nicht.
    Muss ich eventuell noch irgendwelche Pakete installieren, also z.B. lircd-Quellen oder so?

    Trotzdem irgendwie schade, dass das nicht funktioniert (ich war schon am verzweifeln, dass es nur an meiner Dusseligkeit liegen könnte) wäre schon schick, die Installation über Netzwerk hochziehen zu können, zumal die pxe-Umgebung bei mir schon vorhanden ist (wahlweise desinfect, Ubuntu oder Windows 7 32bit/64bit Installation - so praktisch, wenn man nur den Rechner einstöpseln muss, um ihn zu putzen...

    Hallo, liebe yavdr-Gemeinde,


    ich habe hier das Problem, dass (mindestens) innerhalb der Live-Oberfläche die imdb-Suche kein Ergebnis liefert, weil die Suchanfrage immer mit

    Code
    ;s=tt

    endet. Das ist so seit der Neuinstallation mit yavdr 0.5.


    In dem Zusammenhang frage ich mich schon seit ich yavdr nutze (Januar '12, v0.4), wo (ob?) ich einstellen kann, dass statt der englischen die deutsche imdb durchsucht wird (bzw. deutschsprachige Ergebnisse kommen). Wie immer hab ich bestimmt Tomaten auf den Augen...


    LG
    Udo