streamdev: could not tune to channel

Ich habe einen VDR mit 2 x DVB-S2 device, 1 x DVB-T device und streamdev-client. Auf dem Server mit streamdev-server ist nur ein DVB-T device.

Mein Log (Client) ist voll von:

Nov 10 20:17:45 flmedia vdr: [2792] ERROR: Streamdev: Couldn't tune 192.168.3.3:2004 to channel DMAX
Nov 10 20:17:45 flmedia vdr: [2792] retrying
Nov 10 20:17:45 flmedia vdr: [2792] ERROR: Streamdev: Couldn't tune 192.168.3.3:2004 to channel DMAX
Nov 10 20:17:45 flmedia vdr: [2792] retrying
Nov 10 20:17:45 flmedia vdr: [2792] ERROR: Streamdev: Couldn't tune 192.168.3.3:2004 to channel DMAX

Im Schnitt mindestens 5x pro Minute.
Dabei mache ich absolut gar nichts, was ein Streaming auslösen könnte: ich schaue (oder nehme auf) ausschliesslich lokale Kanäle (nur manchmal bei Engpässen eben Streaming). Trotzdem tauchen in diesen Log-Zeilen alle möglichen Kanäle auf, DVB-S und DVB-T (wobei mangels Kanalnummer nicht eindeutig zu sagen, alle DVB-T gibts ja auch in DVB-S), free und verschlüsselt (sind halt in der channels.conf, kann aber nix damit anfangen), empfangbar oder defakto nicht (again: sind halt in der channels.conf..).

Warum versucht er diese Kanäle zu streamen??

Einziger Grund der mir einfällt wäre EPG - aber ich habe EPG sync im streamdev-client deaktiviert.

Ausserdem kämpfe ich schon seit langem mit gelegentlichen Hängern, der VDR reagiert dann oft ewig nicht auf die FB (kann auch mal >1min sein, während im Hintergrund aber das Prg oder auch die Aufnahme weiterläuft).
Kann dieses Phänomen was damit zu tun haben?

Wer weiss, was die folgende Log-Ausgabe des VDR bedeutet:

Nov 13 00:24:55 flmedia vdr: [7257] max. latency time 31 seconds

Da steht oft auch nur 1 oder 2s. Googlet man die Meldung, sind nur sehr selten Werte >5s zu sehen. 31s sind wohl doch recht lange - aber was genau dauert da 31s?

Gruss
hivdr

Zitat

Originally posted by schmirl
EPG-Scan?

Ja, aber warum wird da überhaupt streamdev verwendet?? Wie gesagt, EPG-sync abgeschaltet. Und der normale VDR EPG-Scan versucht es über streamdev? Warum? Es handelt sich überwiegend um DVB-S-Kanäle, dafür hat er zwei lokale devices, auf dem Server nur 20 DVB-T-Kanäle. Er scheint es stur bei allen (manchmal) zu probieren.

Kann man das nicht verhindern, dass der EPG-Scan auf Streaming zugreift?

Merkt sich streamdev-client nicht die auf dem Server verfügbaren Kanäle, so dass es bei allen anderen gar nicht erst jedesmal den tuning-Versuch an den Server weiterleiten muss?

Zitat

Ist im Log irgendetwas mit SVDRP zu sehen? Bekommt der Client z.B. externe EPG-Daten eingespielt?

Log muss ich am Abend/WoE prüfen, melde mich. Aber ich wüsste nichts von externen EPG-Daten, ich verwende nur die mitgesendeten, habe alle Plugins selbst installiert, müsste es also wissen. Einziges fragliches Plugin wäre epgsearch, und das habe ich schon probiert: weglassen von epgsearch ändert nichts an der Situation.

Danke für die latency-Erklärung. Was läuft denn in so einer VDR-"Runde" alles ab, was wären verdächtige Aktionen für solch hohen Zeitbedarf?

Zitat

EPG-Scan: VDR sucht sich zu jedem Transponder das erste freie Device, das diesen Transponder empfangen kann und gerade nichts zu tun hat

Aha! Das "erste freie device" ist dann wohl gerne mal das streamdev. Finde ich generell nicht so sinnvoll.

Das hatten wir ja neulich schon mal in einem anderen Thread: er nimmt auch für Aufnahmen gern das streaming device, aber das konnte ich dann über Prio-Einstellungen wegbekommen.
Aber für den EPG-Scan, wo es mir noch viel unsinniger erscheint, ist das wohl nicht so einfach möglich.

Zitat

Wenn Du experimentieren willst: Ändere doch mal in der streamdev Datei client/device.c den Rückgabewert der Funktion cStreamdevDevice:: ProvidesTransponder von true auf false. Wenn ich im Code nichts übersehen habe, sollte streamdev damit zukünftig weder beim EPG-Scan noch bei Timer-Aufnahmen berücksichtigt werden (wohl aber bei Sofort-Aufnahmen).

OK, ich ziehe es in Betracht. Wobei ich natürlich normalerweise die Aufnahme-Möglichkeit über Streaming nicht grundsätzlich unmöglich machen würde, aber im Moment brauchts das nicht wirklich, da ich meine DVB-S-Leitungen wieder habe.

Zur Auflistung der VDR-Runden-Aktivitäten: interessant!
Jetzt bräuchte man nur noch einen debug-level, mit dem man ableiten kann, bei welchem dieser einzelnen Dinge die Zeit liegen bleibt..

Der Patch von device.c hat geholfen: keine Tune-Versuche mehr im Log.

Ob das irgendwas bei den Hängern bringt (ich glaubs auch nicht), muss ich erst etwas länger beobachten.

SVDRP taucht immer nach dem Start und dann im Abstand von einer Stunde je 2x hintereinander auf, connect from 127.0.0.2. Ich könnte mir vorstellen dass das der vdradmin ist.

Die latency-Ausgabe steht i.a. immer nach dem Start im Log, zweimal, zuerst mit einem Wert wie 1s, dann mit zB 25s, und das auch etwa passend zB 25s später als das erste mal.

Das seltsame bei den Hängern ist ja auch, dass das Bild derweilen normal weiterläuft. Klar, xine als Frontend ist unabhängig, aber vdr muss ja auch Bilddaten an den Socket unter /tmp liefern, das tut es offensichtlich.

Na sowas, erwischt! Also zumindest eine Sache. Der VDRadmin treibt die Last auf 100% hoch, gern auch mal >30s lang. Es steht sogar im Wiki, aber wer liest das schon von vorne bis hinten:

Zitat

CPU-Last: Während VDR-Admin die Daten via Svdrp lädt, steigt die CPU-Last auf bis zu 99%, VDR ist während dieser Phase nicht mehr bedienbar.

Na toll. Das finde ich ja wenig akzeptabel. Hätte ich keinen Dual-Core- sondern einen Single-Core-Atom, wäre da also jedesmal auch noch das Bild stehengeblieben? Ausserdem muss das wohl in einem anderen Thread laufen, während SVRDP-Behandlung und zB Fernbedienung wohl in einem (dieser "Haupt-Runde") laufen?

Nuja, Hauptsache entdeckt, VDRadmin deaktiviert, benutze ihn eh nicht wirklich.

Zitat

Ob Du Single- oder Dual-Core hast, spielt dabei keine Rolle. Die Aufteilung des Prozessors unter allen Prozessen und Threads erledigt das Betriebssystem.

Schon klar, aber mit nur einem Kern und dieser Vollast durch vdradmin hätte ja xine maximal (je nach Prio) noch 50% der Rechenleistung, und mindestens bei HDTV könnte das mit Atom wohl schon zum Stottern führen (OK, macht zu grossen Teilen der ION, also vdpau) - "stehengeblieben" war jetzt etwas drastisch formuliert..