Posts by RaHe67

    Durch komplettes neuaufsetzen des Clients und des Servers habe ich zumindest offenbar das Problem mit den asynchronen Timern lösen können.

    Woran es genau gelegen hat, ist mir allerdings nicht 100%ig klar geworden. Eine Ursache war zumindest, dass der Client bei mehreren meiner Konfigurationsversuche, die bereits auf dem Server angelegten Such-Timer nochmals durch den Client angemeldet hat (obwohl in der Suchtimer Eingabemaske der richtige VDR angegeben war). Es ergaben sich dann doppelte Timer und in der Folge wohl auch inkonsistenzen in der Datenbank.


    Was die Magazin-Ansicht angeht bin ich nicht weitergekommen.

    Im Moment fehlen mir die kompletten EPG Daten von ARD HD + wieder One HD. Alle anderen Sender sehen auf den ersten Blick ok aus.


    Hat jemand Erfahrungen oder ist die Einstellung nur TVM u. TVSP Daten zu verwenden ungünstig?


    Gruß Ralf

    Habe gerad noch zufällig gesehen,

    auf dem Server zeigt das live-Plugin an mehreren Stellen auch keine EPG Daten an. Z.B. bei RTL hat er für Freitag komplett keine Daten (für Samstag aber wieder).

    Die Konfiguration für das EPG abholen sieht so aus, bin mir nicht sicher ob die Einstellungen so aus der epgd.conf hervorgehen:




    Ich lese also komplett aus dem Web. Spricht da was gegen?


    Gruß Ralf

    Client Conf:


    Server epgd.conf


    Server Channelmap:



    Server setup.conf:


    Hallo,


    ich versuche schon einige Zeit die EPGd Übersicht sauber ans laufen zu bekommen. Es scheinen aber immer wieder (Datenbank) Update Problem aufzutauchen:

    Die Einträge für RTL u. Vox zb. werden nicht sauber nachgeladen siehe Screenshot (Zeiten sind z.b. auch verschoben):



    Aus Suchtimern resultieren immer wieder asynchrone Aufträge die nie selbsttätig verschwinden (merkwürdigerweise u.A. auf Kanälen die im Magazin sauber aussehen)


    Die Datenbank hatte ich schon einmal komplett gelöscht. Der (Daten) Aufbau dauert relativ lange bis die Scraper durch sind (11-15 Stunden). Die Fehler tauchen aber wieder auf.

    Hat jemand eine Idee was ich noch tun kann?


    Szenario:

    VDR Server MLD 5.4 Unstable (OMV4 und VirtualBox), Epgd, epg2vdr

    VDR Client MLD 5.4 Unstable, epg2vdr



    Server Status:

    Code
    1. VDRServer> epgd-tool -show-stats
    2. +----------------------------------------------------------+-------+--------+--------------+----------+----------------------------+----------------------------+----------------------------+
    3. | version | dbapi | master | ip | state | last touch | last download | next download |
    4. +----------------------------------------------------------+-------+--------+--------------+----------+----------------------------+----------------------------+----------------------------+
    5. | vdr 2.4.0 epg2vdr 1.1.98-GITv217-5-g6280831 (15.10.2018) | 7 | Y | 192.168.2.4 | attached | 30th January 2019 20:18:51 | 30th January 2019 08:44:56 | NULL |
    6. | vdr 2.4.0 epg2vdr 1.1.98-GITv217-5-g6280831 (15.10.2018) | 7 | n | 192.168.2.50 | attached | 30th January 2019 20:18:37 | 27th January 2019 03:58:38 | NULL |
    7. | epgd 1.1.146-GITv57 (21.10.2018) | 7 | - | 192.168.2.4 | standby | 30th January 2019 08:44:51 | 30th January 2019 08:44:51 | 30th January 2019 20:44:51 |
    8. +----------------------------------------------------------+-------+--------+--------------+----------+----------------------------+----------------------------+----------------------------+


    Server Log:

    Der webIf Error unten scheint aufzutreten, wenn man auf die fehlerhaften Stellen scrollt, bzw. diese Daten angezeigt werden sollen.

    Client Log:


    Gruß Ralf

    Die geänderten Konfigurationsdaten sind gesichert - hab ich beim anlegen vor 5 Jahren schon dokumentiert. Das sind ca. 2 Handvoll angepasste konfirurationsdaten also nicht das Riesen Problem. Ein komplettes Backup habe ich nicht, da mir der Aufwand zum (regelmäßigen) Erstellen größer als das Neuaufsetzen erschien.


    Und einfach mal nach auto-remove und yavdr suchen, da gibt es schon diverse Beiträge.


    Nun lese ich schon permanent hier mit und die Finger waren doch zu schnell - bzw. 'auto-remove' hat nicht meine Aufmerksamschwelle erreicht.



    Ok das heisst ich brauche mich mit

    bitte kein auto-remove auf einem yavdr-System


    das ist von daher unglücklich, da genau das auf meinem (nun gerade aus diesem Grunde plattgemachten) Ubuntu Server von Zeit zu Zeit notwendig war. Dort ist mir nämlich von Zeit zu Zeit die boot Partition mit kernels vollgelaufen (vermutlich original zu klein gewählt) Hat mich jedesmal geärgert nicht rechtzeitig da autoremove aufgerufen zu haben. Dachte ich mache damit (Ubuntu) Systempflege auch auf YaVdr :-( Der Weg war nicht weit.


    Oder noch besser: sich mit yavdr-ansible nebenbei auseinandersetzen. Für den nächsten vdr.

    Hab mich damit noch nicht auseinandergesetzt. Ist der Stand so weit, dass ich beim Neuaufsetzen diesen Weg gehen sollte? Hatte bis jetzt nicht den Eindruck dass die Ansible Installation bis jetzt schon vollständig / fertig ist.



    Ralf

    Hallo,


    nach einem apt-get autoremove

    scheinen mir auf meiner yavdr 0.6 Client installation einige (Yavdr) Pakete entfernt worden zu sein, so dass nicht mehr vollständig gebootet werden kann. Ich lande jetzt auf der Eingabeaufforderung. Das Live Plugin und die Webkonfiguration sind nicht mehr ansprechbar. Vdr Instanzen scheinen zu laufen:


    Code
    1. service vdr status
    2. vdr start/running, process 2035


    Das erste Problem worauf gelaufen wird:


    Code
    1. ralf@Vdr1:~$ dmesg | grep ngene
    2. [ 5.854180] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner (v5)
    3. [ 5.901168] ngene: Device version 1
    4. [ 5.928257] ngene 0000:02:00.0: Direct firmware load failed with error -2
    5. [ 5.928265] ngene 0000:02:00.0: Falling back to user helper
    6. [ 6.402629] ngene: Could not load firmware file ngene_18.fw.
    7. [ 6.402693] ngene: Copy ngene_18.fw to your hotplug directory!
    8. [ 6.403007] ngene: probe of 0000:02:00.0 failed with error -1
    9. ralf@Vdr1:~$

    Ein Bild gibt es so natürlich nicht mehr.

    Code
    1. uname -a
    2. Linux Vdr1 3.13.0-164-generic #214-Ubuntu SMP Wed Dec 5 10:42:33 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
    Code
    1. lsmod | grep ngene
    2. ngene 37231 0
    3. cxd2099 13242 1 ngene
    4. dvb_core 121659 1 ngene

    Gibt es eine Möglichkeit die Yavdr pakete + ngene FW wieder in den Ursprünglichen Zustand zu versetzen oder ist eine Neuinstallation angesagt?


    Versucht habe ich schon ein apt-get update + apt-get dist-upgrade


    Wie finde ich heraus was alles fehlt?


    Ralf

    Files

    • dmsg.txt

      (18.4 kB, downloaded 20 times, last: )

    Ok, auf dem Server ist ja nur das DummyDevice als Ausgabe aktiv. Geht also ins Nirwana.


    Einbindung am Client dann also immer über Shares im Netzwerk.

    Bin nur auf diversen Web-Seiten über "Aufnahmestreaming" gestolpert habe mich aber immer gefragt ob das direkt durch einen VDR-Klient (als Empfänger) unterstützt wird (VDR oder PlugIn).

    Aufnahmen auf dem Server werden soweit angelegt.


    Eine Verständnis Frage:

    Ist es eigentlich immer noch notwendig das Server-Aufnahmeverzeichnis auf dem Client zu mounten bzw. einen Share dafür einzurichten? Oder sollte das Streamen von Aufnahmen mit streamdev-Client/Server direkt gehen?


    Bei mir hat das RemoteOSD -> Server -> Aufnahmen -> Wiedergabe keine Funktion.


    Ralf

    Hurra, jetzt scheint es zu funktionieren. Auch wenn ich mich Wiederhole. Dank an alle!

    Auf Clientseite kann ich das ServerMenü noch nicht aufrufen. Meldung "Server-Menü nicht erreichbar, Verbindung fehlgeschlagen"

    Die Lösung war mir fehlte noch das vdr-plugin-svdrposd auf der Serverseite. Kaum macht mans richtig .... :D

    Zusätzlich hatte ich in RemoteOSD und RemoteTimers die IPAddresse des Servers händisch eingetragen.


    Ralf

    Versuche doch mal die beiden host.conf Dateien mit 192.168.2.0/24 oder 0.0.0.0

    Habe jetzt Serverseitig 0.0.0.0/0 eingetragen. Damit behaupten beide Logs dass die Verbindung erfolgreich war. Danke für den Hinweis - wobei ich dachte die 24 müsste die letzten 3 Bytes der IP ausmaskieren und nur noch auf die 192 prüfen ...


    Die Serverseite zeigt jetzt auch eine Streamdev Verbindung auf 192.168.2.126 an. Die Clientseite nicht.


    Auf Clientseite kann ich das ServerMenü noch nicht aufrufen. Meldung "Server-Menü nicht erreichbar, Verbindung fehlgeschlagen". Gehe ich recht in der Annahme das sich dass dann eher um ein Problem des RemoteOSD handelt? In den Logs finde ich nocht nichts ...


    Ralf

    Ein bisschen weiter bin ich nun gekommen. Habe jetzt den Streamdev Server auf der Server Seite (NAS) und den StreamDev Client auf der Client Seite aktiviert.


    Jetzt passiert folgendes:


    Server-Seite (192.168.2.3)

    Code
    1. journalctl -b -u vdr | grep streamdev
    2. Dez 15 12:41:40 HOMENAS1 vdr[614]: [614] loading plugin: /usr/lib/vdr/plugins/libvdr-streamdev-server.so.2.4.0
    3. Dez 15 12:41:40 HOMENAS1 vdr[614]: [614] initializing plugin: streamdev-server (0.6.1-git): VDR Streaming Server
    4. Dez 15 12:41:41 HOMENAS1 vdr[614]: [614] starting plugin: streamdev-server
    5. Dez 15 12:41:41 HOMENAS1 vdr[614]: [614] loading /var/lib/vdr/plugins/streamdev-server/streamdevhosts.conf
    6. Dez 15 12:41:41 HOMENAS1 vdr[614]: [821] streamdev server thread started (pid=614, tid=821, prio=high)
    7. Dez 15 12:46:59 HOMENAS1 vdr[614]: [821] streamdev: client 192.168.2.126:47354 not allowed to connect
    8. Dez 15 12:46:59 HOMENAS1 vdr[614]: [821] streamdev-server: closing VTP connection to 192.168.2.126:47354


    Client-Seite (192.168.2.126)


    streamdevhosts.conf + svdrphosts.conf sind angepasst (Subnetz: 192.168.0.0/24 bzw. 192.168.0.0/16 freigegeben, auf beiden Seiten).

    Auf der Server Seite hatte ich sonst keine Einstellungen vorgenommen. Fehlt noch was?


    Ralf

    a, das remote-Plugin mag es nicht, wenn es das erwartete Input-Device nicht findet. Ich würde das bei einem Headless-Server weglassen (für den OSD-Zugriff ist es eh nur bedingt geeignet).

    Eigentlich müsste das Ding laufen, wenn das mit dem remote-Plugin erledigt ist.

    Ja sieht gut aus :-) Herzlichen Dank an alle die mitgeholfen habe.


    Die VDR Prozesse bleiben bestehen. Auf die "Live" Seite kann ich zugreifen.


    Wenn ich das richtig verstanden habe benötige ich nun die folgenden plugins (Quelle: http://vdr.schmirler.de/) um das Client Server Szenario anzugehen.


    Server (VDR version 2.4.0):

    svdrposd


    Client (YaVDR 0.6 Testing):

    remoteosd

    svdrpservice

    epgsync

    remotetimers


    Ist damit eine "sanfte" Migration möglich (z.B vorhandene Timer + Aufnahmen auf dem Client zu behalten) + zusätzlich Timer / Aufnahmen auf dem Server zu verwalten?

    Oder sollte ich besser vor der Anbindung alles auf den Server verlagern?


    BTW, sollte ich sinnvollerweise mein Szenario + Installationsbeschreibungen im Wiki, Forum, oder Dokumentation hinterlegen?


    Gruß Ralf

    Lieben Dank für die Hinweise. Brauche einen Kompass der mir sagt in welche Richtung ich weiterlaufen soll :D

    Vielleicht habe ich heute Abend wieder eine Stunde an der Kiste.


    Das sehe ich anders: Mittel-/langfristig sind Config-Dateien wesentlich sinnvoller als irgendwelche grafischen Oberflächen, weil man das scripten kann.

    Naja solange man nichts automatisieren und die Geschichte nur einmal anfassen und wenig pflegen will sind intuitiv benutzbare Oberflächen schon nicht schlecht. Besonders für Anfänger.

    Deshalb habe ich ja auch hier den Debian + OMV4 Unterbau gewählt. Ansonsten gebe ich Dir natürlich recht.


    Die bei Ubuntu enthaltenen VDR-Pakete mögen veraltet sein, aber sie funktionieren. Und sie reichen vollkommen für meinen Bedarf.
    e-tobi hatte ich in der Anfangszeit auch verwendet. Das ist dann aber regelmäßig in einem Chaos ausgeartet. Das mag sich in der Zwischenzeit gebessert haben.

    Was sind den die wesentlichen Unterschiede der Ubuntu vs. e-Tobi (Debian) Pakete (für einen unbedarften Nutzer erklärt)? Mal von der unterschiedlichen Distributionen und den vermutlich unterschiedlichen Versionsständen abgesehen. Oder beziehst Du Dich auf YaVdr Pakete wo noch viel mehr drin ist?


    Ralf

    Bitte nicht gefiltert nach Fehlern. Bitte die ganze Wahrheit

    Wollte Euch natürlich nichts vorenthalten. In den Logs, die ich rausgesucht habe stand auch nicht mehr drin :-(

    Als Linux Anfänger bin ich mir im Moment über die korrekten Startmethoden (SystemD, per Prozess, bzw Service Start) und die verschiedenen logging Outputs etwas verloren.


    --log=3.7 ist in der 00-vdr.conf ergänzt (erzeugt aber keine zusätzliche Ausgabe in dem log siehe unten)


    Nach dem Reboot hat wohl systemd den Vdr einmal erfolglos versucht hochzustarten.


    Also den Octopus unter der Addresse 192.168.2.33 scheint er gefunden zu haben. Das Live Plugin scheint Probleme mit der IPAddress zu haben und für mich sieht es so aus, als wenn ein fehlendes ir-Device den Exit verursacht ....


    Log-Datei als Anhang:

    log.txt


    Ralf