Ist das vdr-eigene Objekt. Der Autor des Plugins hat den Aufruf mittlerweile entfernt und nun läuft alles normal.
Posts by Frank612
-
-
Hab den Fehler im vnsi Plugin gefunden. Es lag an dem Aufruf von Recordings.Load() Weiß zwar nicht genau warum, aber dieser Aufruf führt zu dem beschriebenem Problem.
-
Liegt wohl doch am VNSI Plugin. Ist dieses nicht aktiv, tritt der Fehler nicht auf. Mir ist nur nicht ganz klar, wo der Bug liegt. vnsi liest Recordings.StateChanged aus und reagiert damit auf neue Aufnahmen. Scheinbar zu früh. Beim durchgehen aller Aufnahmen kann dann auf die RecordingInfo der gerade gestarteten Aufnahme nicht zugegriffen werden (weil diese noch nicht angelegt wurde?) und auch im VDR kommt es dann erst durch die Zugriffe von vnsi zu dem Fehler, dass der vdr die info Datei nicht öffnen kann und somit auch die weiteren infos im OSD nicht anzeigen kann.
Gibt es irgendeine Alternative zu Recordings.StateChanged um auf neue Aufnahmen zu reagieren?
-
Der vdr läuft 24/7, wobei die Aufnahmeplatte bei Inaktivität per hdparm abgeschaltet wird. Startet nun eine Aufnahme während die Platte im standby ist, kommt es zu besagtem Fehler. Ist die Platte gerade aktiv, tritt er hingegen nicht auf.
Im vdr selber bemerkt man fast nichts, d.h. die laufende Aufnahme wird mit korrektem Datum und Uhrzeit im OSD unter Aufnahmen aufgelistet. Es fehelen allerdings sämtliche weiteren Angaben aus der info-Datei der Aufnhame. Also Kurztext, Genre, Beschreibung. In der Datei sind sie vorhanden, im OSD werden sie bis zur Aktualisierung der Aufnahmeliste oder eines Neustarts des vdr aber nicht angezeigt.
Wenn du sagst, der vdr liest erstmal alles in den RAM, könnte ich mir vorstellen, dass es durch die Verzögerung beim Aufwachen der Platte hier zum Problem kommt und die vollständigen Daten dann eben erst wieder beim erneuten einlesen im RAM landen. Bei VNSI gibt es noch das spezielle Problem mit dem Datum, aber grundsätzlich betrifft es auch dort nur die Aufnahmen, die auch im vdr nicht vollkommen korrekt angezeigt werden.
Gruß, Frank
-
Hallo,
ich habe ein kleines Problem mit dem VDR 2.2.0 bei Aufnahmen, bei denen zuerst die Festplatte aus dem Standby geweckt wird. Diese werden bis zur Aktualisierung der Aufnahmeliste nicht korrekt im OSD und im Live-Plugin angezeigt, d.h. die EPG Beschreibungen fehlen dort. Bei Benutzung des VNSI-Plugins werden die Aufnahmen dann mit falschem Datum (Jan. 1970) aufgeführt. Habe das Problem deswegen zunächst im Forum bei kodi.tv angesprochen, aber ich glaube nunmehr, dass es ein Fehler direkt im VDR ist.
Meine Festplatte ist eine WD MyBook USB3 und hat eine etwas längere Anlaufzeit glaube ich. Mit einer WD Green auf meinem Desktop habe ich jedoch denselben Fehler feststellen können.
-
Habe den iLNB jetzt knapp eine Woche in Betrieb und bisher keinerlei Probleme. Es werden jedoch nie mehr als 4 Tuner benötigt, d.h. ich müsste noch ausstesten, wie er sich bei Zugriff auf mehr als 4 Tuner verhält. Ansonsten bin ich aber überrascht, wie reibungslos es läuft. Umschaltzeiten direkt am VDR über xineliboutput sind schneller als mit meiner CineS2. Komischerweise dauerts über VNSI nun aber etwas länger.
-
Hast recht. Habs gerade nochmal ohne LNB gemessen und die CineS2 + DuoFlex brauchen zusammen 5W (bei entladenem Treiber 4W).Hinzu kommt dann die Versorgung für den LNB und da dachte ich eigentlich, dass mein 8-Fach Multischalter den LNB aktiv versorgen würde. Ist aber wohl nicht der Fall.
-
Ich hatte die CineS2 5.5 bei mir mal mit ca. 5-6W aus dem Gesamtsystem rausgemessen, das FlexModul liegt ähnlich, also ca. 10W- für 4 Tuner, habe aber damals einen LNB mit Strom versorgt. Ohne wird es sicher weniger sein und die V6.2 sind auch etwas sparsamer geworden.
Bei meiner CineS2 5.5 + DuoFlex S2 habe ich ähnliche Werte, d.h. so ca. 10-13 Watt. Allerdings hängen die an einem Smart Multischalter, der ja eigentlich den LNB mit Strom versorgen sollte. Zumindest zieht der nochmal konstant 7 Watt. Normalerweise würde ich dann davon ausgehen, dass die Tuner nur so um die 5-6 Watt verbrauchen. Kann es sein, dass die Tuner Strom für den LNB ziehen, obwohl es gar nicht notwendig ist, bzw. kann/muss man das irgendwo einstellen?
-
Welche Probleme gibts denn wenn mehr als 4 Tuner in Betrieb sind? Bildaussetzer oder so könnten ja tatsächlich aufs Netzwerk zurückzuführen sein.
Grundsätzlich würden mir 4 Tuner eigentlich reichen, finde aber die Variante des ILNB interessanter, als einen extra Sat>IP Server mit 4 Tuners. Auch vom Stromverbrauch kommt man wohl besser weg. Werden die Tuner mit dem satip Plugin eigentlich den VDRs fest zugeordnet oder läuft das dynamisch?
-
Mit dem neuesten satip-Plugin und vdr-2.1.7 scheint das ganze jetzt auch stabil zu laufen, zumindest seit gestern. Ich lass das ganze jetzt mal weiter laufen und warte mal ab, ob es dabei bleibt.
Wie stabil läuft es bei dir denn mittlerweile? Bin am überlegen meinen 4 Tuner VDR-Server durch Sat>IP zu ersetzen. Die bisherigen Erfahrungen, die ihr hier mit dem LNB gemacht habt, schrecken mich aber noch ein bisschen ab.
-
Der EPG-Scan geht zyklisch alle Sender der channels.conf durch. Möglicherweise gibt es darin einen Kanal, der einen Treiberbug triggert...
Lade bitte Deine channels.conf als Attachment hoch, ich werde den EPG-Scan damit testen.
Seltsam ist, daß immer Tuner 4 betroffen ist. Treibertechnisch gibt es keinen Unterschied zwischen Tuner 1 und 3 sowie 2 und 4. Kannst Du versuchen, ob sich etwas ändert, wenn VDR mit "-D3 -D2 -D1 -D0" gestartet wird (umgekehrte Reihenfoilge der Tuner).
CU
OliverGerade getestet: Ändern der Reihenfolge der Tuner beim Start ändert auch nichts. Wieder ist nur der 4. Tuner ausgefallen.
Habe meine channels.conf angehängt. Danke fürs testen! -
Habe vor ca. 30 Minuten den EPG scan wieder aktiviert (auf 5h) und schon ist das Bild am 4. Tuner wieder weg. Ich kopiere mal aus dem logfile, vielleicht sieht ja irgendjemand den Fehler/Zusammenhang:
Code
Display MoreAug 31 23:45:10 server vdr: [4373] saved setup to /var/lib/vdr/setup.conf Aug 31 23:46:34 server vdr: [4417] VNSI: Requesting clients to reload channel list Aug 31 23:46:35 server vdr: [4417] VNSI: Requesting clients to reload channel list Aug 31 23:46:56 server vdr: [4402] channel 1 (Das Erste HD) event Sam 31.08.2013 23:35-23:38 (VPS: 31.08. 23:35) 'Das Wort zum Sonntag' status 4 Aug 31 23:48:40 server vdr: [4417] VNSI: Requesting clients to reload channel list Aug 31 23:48:42 vdr: last message repeated 2 times Aug 31 23:48:42 server vdr: [4402] changing portal name of channel 120 from 'S04 - LEV' to 'Samstag LIVE!' Aug 31 23:48:42 server vdr: [4417] VNSI: Requesting clients to reload channel list Aug 31 23:50:03 server vdr: [7536] epg data writer thread started (pid=4373, tid=7536, prio=low) Aug 31 23:50:03 server vdr: [7536] epg data writer thread ended (pid=4373, tid=7536) Aug 31 23:50:04 server vdr: [6796] ecmhandler 1/0 filter thread ended (pid=4373, tid=6796) Aug 31 23:50:04 server vdr: [6797] logger 1/0 filter thread ended (pid=4373, tid=6797) Aug 31 23:50:05 server vdr: [4417] VNSI: Requesting clients to reload channel list Aug 31 23:50:47 server vdr: [4417] VNSI: Requesting clients to reload channel list Aug 31 23:51:30 server vdr: [4417] VNSI: Requesting clients to reload channel list Aug 31 23:52:52 server vdr: [4402] channel 1 (Das Erste HD) event Sam 31.08.2013 23:40-00:25 (VPS: 31.08. 23:40) 'Krömer - Late Night Show (3)' status 4 Sep 1 00:00:04 server vdr: [7564] epg data writer thread started (pid=4373, tid=7564, prio=low) Sep 1 00:00:04 server vdr: [7564] epg data writer thread ended (pid=4373, tid=7564) Sep 1 00:06:33 server dhclient: DHCPREQUEST of 192.168.178.24 on eth1 to 192.168.178.1 port 67 Sep 1 00:06:33 server dhclient: DHCPACK of 192.168.178.24 from 192.168.178.1 Sep 1 00:06:33 server dhclient: bound to 192.168.178.24 -- renewal in 1446 seconds. Sep 1 00:09:01 server CRON[7594]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime$ Sep 1 00:10:05 server vdr: [7605] epg data writer thread started (pid=4373, tid=7605, prio=low) Sep 1 00:10:06 server vdr: [7605] epg data writer thread ended (pid=4373, tid=7605)
Sind alles Meldungen, die immer wieder im log Auftreten, ohne dass der 4. Tuner ausfällt.
-
Was genau läuft da auf dem Streaming-Server?
CU
OliverNeben, xineliboutput läuft noch vnsiserver (habe ich allerdings zu Testzwecken schon mal raus genommen. Der Fehler ist trotzdem aufgetreten), das live plugin und epgsearch. VDR ist 2.0.2 aus den yaVDR Quellen.
Kurzes Update: Aufnahmen auf allen 4 Tunern sind ebenfalls problemlos durchgelaufen, also deutet alles nach wie vor auf den EPG scan hin.
Ich hatte in der Vergangenheit desöfteren mal "lost lock" Meldungen im log (z.B. bei Tele 5), die jedoch nie direkt den Fehler ausgelöst haben. Nach abschalten des EPG scans treten diese Meldungen allerdings nicht mehr auf. Kanns vllt. doch an diesen Sendern liegen? Tele 5 hatte ich zwischenzeitlich auch schon aus der channels.conf entfernt, aber vllt. betrifft es ja noch andere Sender. Werde das nachher überprüfen. -
Nein, mit 4 Aufnahmen von 4 verschiedenen Transpondern habe ich zuletzt nicht mehr getestest - anfangs schon. Ich bediene 3 verschiedene Clients gleichzeitig (die ebenfalls dann rund um die Uhr Ihr laufen) und überprüfe den 4. Tuner lokal mit vdr-sxfe. Muss dazu sagen, dass der 4. Tuner oft schon kein Bild mehr lieferte, wenn kein anderer Client verbunden war und ich nur lokal auf Tuner 4 eingestellt hatte, weshalb ich dann keine Aufnahmen mehr zum testen gemacht habe. Trotzdem werde ichs jetzt mal wieder mit den Aufnahmen überprüfen.
-
Bei mir scheint es dann wohl doch am EPG scan zu liegen. Alle 4 Tuner laufen nun schon seit mehr als 2,5 Tagen durch. Frage mich allerdings, warum dieses Problem beim regelmäßigen scannen der EPG Daten bei mir auftritt.
-
Hallo,
verwende derzeit den Kernel 3.5.0-34, hatte aber auch schon mehrere ältere mit dem gleichen Problem.
Das media Verzeichnis habe ich verschoben und dann die selbstgebauten media_build_experimental Module installiert (letzter sync vor ner Woche oder so)Werde auch mal versuchen DolbyDigital abzuschalten. Zunächst aber erst noch mal mit deaktiviertem EPG scan und angeschlossenem X10 Empfänger.
-
Der 4. Tuner lief weitere 3 Tage vollkommen problemlos. Habe dann den EPG scan gestern wieder aktiviert und nach ein paar Stunden Betrieb war das Bild wieder weg.
Als andere mögliche Fehlerquellen hatte ich zwischenzeitlich einen internen X10 Funkempfänger sowie ein Laptop Netzteil welches direkt neben dem PC liegt in Betracht gezogen. Werde also weiter testen, da es bei UFO ja auch mit EPG scan läuft.
-
Erstmal vielen Dank für den Test UFO
Dann kann es eigentlich nur an meinem System bzw. der Hardware liegen, denn normalerweise dauert es nur ein paar Stunden bis der Tuner kein Bild mehr liefert. Aktuell läuft es allerdings nach wie vor durch, wobei man die Option "EPG scan" ja dann wohl als Grund ausschließen kann. Ich habe ansonsten keinerlei Änderungen vorgenommen. Eine Sache, bei der ich mir jetzt allerdings nicht mehr 100% sicher bin: Früher hatte ich den VDR ohne device option gestartet, bei den letzten Tests hatte ich dann irgendwann mal "-D0 -D1 -D2 -D3" eingefügt. Möglicherweise war diese Änderung bevor ich den EPG scan deaktiviert habe und es seit dem durchläuft.
Ich versuche jetzt mal einen Neustart um zu sehen, obs danach weiter ohne Fehler läuft. Bisher hat der 4. Tuner noch nie so lange durchgehalten.
-
Seit ich den EPG scan deaktivert habe läuft der Tuner nun seit über 24 Stunden fehlerfrei durch. Sollte es tatsächlich daran liegen? Device bonding nutze ich aber wie gesagt gar nicht.
-
Meinst du damit dass nur ein kabel vom lnb vorhanden ist und du device bonding verwendest ?
Dann wäre eine aktuelle Vdr version 2.0.2 und ein entsprechendes setup sinnvoll ( epg scan deaktiviert weil der probleme mit dem bonding machen kann, channel update auf nur name und pid , usw )Lg,
JoeNein, ich meine den Connection Tab auf der CineS2 an den man dann eine Duoflex oder CI anschließen kann. Die neueren Karten haben scheinbar 2 solcher Anschlüsse für mehrere Erweiterungen.
Die Karte plus Duoflex hängen an einem Multischalter und jeder Tuner hat ein eigenes Kabel.Mitllerweile verwende ich übrigens VDR 2.0.2 aus dem yaVDR PPA. Werde aber mal versuchen den EPG scan zu deaktivieren. Das habe ich bisher noch nicht getestet.