Ich habe den besprochenen segfault auch ...
Bin leider auf unixoiden Platformen nicht trittsicher 
Versuche gerade gemaess hier:
http://vdr-wiki.de/wiki/index.php/Gdb
> ulimit -c ulimitedDann provoziere ich den Absturz des VDR durch installatino des epg2vdr plugins (MLD 5.5).
Stehe nun leider auf dem Schlauch, wo ich den Dump finde ...
Was ist das angesprochene 'Aktuelle Verzeichnis' oder habe ich ein Rechteproblem? Der VDR ist unter MLD immer als Root unterwegs?
Gruss Ralf
Alles anzeigenDer NUC6CAYH funktioniert hier ohne Probleme. Kann ich empfehlen, sofern kein UHD benötigt wird.
Hallo iNOB,
funktioniert das Einschalten bei Dir? Trotz aktuellem Bios geht bei mir mittels Harmony Hub (Kls 1.6 Profil) nur jedes zweite mal.
Andere Befehle (wie auch ausschalten) funktionieren Problemlos.
Ansonsten benutze ich den auch unter MLD ohne Probleme (SATIP-Client).
Grüße
Ralf
hast Du das Problem noch lösen können?
Das sich die durch Suchtimer generierten Timer doppeln kenne ich gut - und das war auch schon bei verschiedenen Installationen (Distributionen) bei mir zu beobachten... Ich vermute dass da ein Bug in den beteiligten Plugins ist.
Hallo Grillbert,
bei mir taucht dieses Problem nicht mehr auf, nach monatelanger Quälerei mit verschiedensten Problemen habe ich meine Konfiguration anders gewählt:
1. keine Benutzung von Streamdev-Client + Streamdev-Server mehr. Diese Plugins führten bei mir ständig zu instabilen Verhalten (meistens beim Umschalten von Kanälen oder Stoppen von Aufnahmen (Server-Timeouts). Habe mittlerweile mehrere Posts gelesen die hier auf Probleme hinweisen, zusätzlich schien es so, dass sich um diese Plugins keiner mehr kümmert.
2. Als EPG benutze ich jetzt nur noch die selbst vom Tuner eingelesenen EPG Daten und zwar sowohl von client als auch vom Server unabhängig. Den Client nur für Live-View (1 Tuner ohne Epg) zu verwenden hat bei mir auch für viele problem gesorgt (Blockieren von Octopus.nET Tunern), die dann für Live-View bzw. Server nicht mehr zur verfügung standen. Meine Erkenntnis nach funktioniert es nur sauber, wenn der Client min. 2 Tuner belegen darf.
3. Sowohl Vdr-Server als auch VDR-Client bekommen 2 SatIP Devices aus den obengenannten Problemen.
Damit läuft es deutlich besser. Mein ursprüngliches Ansinnen war Devices zu sparen, damit die 4-fach Octopus.NET nicht durch Client u. Server komplett belegt wird (3 hätten meiner Meinung nach gereicht) dann wäre noch 1er für PC bzw. Tablet frei gewesen. Damit habe ich aber keine stabilen Betrieb hinbekommen.
Ich vermute, die doppelten Timer kamen von Punkt 1, kann es aber nicht beschwören.
Ralf
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
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:
VDRServer> epgd-tool -show-stats
+----------------------------------------------------------+-------+--------+--------------+----------+----------------------------+----------------------------+----------------------------+
| version | dbapi | master | ip | state | last touch | last download | next download |
+----------------------------------------------------------+-------+--------+--------------+----------+----------------------------+----------------------------+----------------------------+
| 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 |
| 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 |
| 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 |
+----------------------------------------------------------+-------+--------+--------------+----------+----------------------------+----------------------------+----------------------------+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:
service vdr status
vdr start/running, process 2035Das erste Problem worauf gelaufen wird:
ralf@Vdr1:~$ dmesg | grep ngene
[ 5.854180] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner (v5)
[ 5.901168] ngene: Device version 1
[ 5.928257] ngene 0000:02:00.0: Direct firmware load failed with error -2
[ 5.928265] ngene 0000:02:00.0: Falling back to user helper
[ 6.402629] ngene: Could not load firmware file ngene_18.fw.
[ 6.402693] ngene: Copy ngene_18.fw to your hotplug directory!
[ 6.403007] ngene: probe of 0000:02:00.0 failed with error -1
ralf@Vdr1:~$Ein Bild gibt es so natürlich nicht mehr.
uname -a
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/Linuxlsmod | grep ngene
ngene 37231 0
cxd2099 13242 1 ngene
dvb_core 121659 1 ngeneGibt 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
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
/24 = 255.255.255.000 bei Dir dann 192.168.2.0 bis 192.168.2.255
/16 = 255.255.000.000 wäre dann 192.168.0.0 bis 192.168.255.255
Ja du hast recht. Siehe auch
https://de.wikipedia.org/wiki/IP-Adresse
da ist es ganz gut beschrieben. Ich hab falsch gedacht und damit waren meine Einstellungen verkehrt.
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 ....
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
Jetzt benutze ich schon 7 Jahre das live Plugin und über die Fernbedienungs-Funktion bin ich noch nie gestolpert. Man lernt nie aus.
Die Einstellungen sehen genauso aus wie in Deinem Snapshot incl. VDR-zu-VDR Starten und Binde an IP,
Ralf
Ja, Timer und Aufnahmen, aber Plugin-Streamdev Einstellungen? Auf die hatte ich mich mit (OSD) bezogen.
Das Live Plugin ist jedenfalls bei mir erreichbar.
Ralf
Hier sehe ich nur client-Seitige Einstellungen:
http://vdr-wiki.de/wiki/index.php/Streamdev-plugin
die Datei etc/vdr/conf.d/50-streamdev-server.conf (Headless Server)
enthält keine Einstellungen.
wurde VDR-zu-VDR Server im Setup von Plugin streamdev-server aktiviert?
Auf der Client Seite ja,
auf der Headless Server Seite habe ich eine solche Einstellung nicht gefunden.
Welche Config Datei wäre denn das? OSD habe ich ja dort noch nicht.
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)
journalctl -b -u vdr | grep streamdev
Dez 15 12:41:40 HOMENAS1 vdr[614]: [614] loading plugin: /usr/lib/vdr/plugins/libvdr-streamdev-server.so.2.4.0
Dez 15 12:41:40 HOMENAS1 vdr[614]: [614] initializing plugin: streamdev-server (0.6.1-git): VDR Streaming Server
Dez 15 12:41:41 HOMENAS1 vdr[614]: [614] starting plugin: streamdev-server
Dez 15 12:41:41 HOMENAS1 vdr[614]: [614] loading /var/lib/vdr/plugins/streamdev-server/streamdevhosts.conf
Dez 15 12:41:41 HOMENAS1 vdr[614]: [821] streamdev server thread started (pid=614, tid=821, prio=high)
Dez 15 12:46:59 HOMENAS1 vdr[614]: [821] streamdev: client 192.168.2.126:47354 not allowed to connect
Dez 15 12:46:59 HOMENAS1 vdr[614]: [821] streamdev-server: closing VTP connection to 192.168.2.126:47354Client-Seite (192.168.2.126)
grep streamdev /var/log/syslog
Dec 15 12:46:28 Vdr1 vdr: [5007] stopping plugin: streamdev-client
Dec 15 12:46:55 Vdr1 vdr: [1177] loading plugin: /usr/lib/vdr/plugins/libvdr-streamdev-client.so.2.2.0
Dec 15 12:46:55 Vdr1 vdr: [1177] loading plugin: /usr/lib/vdr/plugins/libvdr-streamdev-server.so.2.2.0
Dec 15 12:46:56 Vdr1 vdr: [1177] initializing plugin: streamdev-client (0.6.1-git): VTP Streaming Client
Dec 15 12:46:56 Vdr1 vdr: [1177] streamdev-client: got device number 13
Dec 15 12:46:56 Vdr1 vdr: [1177] initializing plugin: streamdev-server (0.6.1-git): VDR Streaming Server
Dec 15 12:46:56 Vdr1 vdr: [1177] dynamite: streamdev-client detected, leaving 1 additional slot(s) free
Dec 15 12:47:00 Vdr1 vdr: [1177] starting plugin: streamdev-client
Dec 15 12:47:00 Vdr1 vdr: [1177] starting plugin: streamdev-server
Dec 15 12:47:00 Vdr1 vdr: [1177] loading /var/lib/vdr/plugins/streamdev-server/streamdevhosts.conf
Dec 15 12:47:00 Vdr1 vdr: [1718] streamdev server thread started (pid=1177, tid=1718, prio=high)
Dec 15 12:47:00 Vdr1 vdr: [1177] ERROR: streamdev-client: Didn't receive greeting from 192.168.2.3:2004: 221 Too many clients or client not allowed to connectstreamdevhosts.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