Ist ja schön, aber der höhere Timeout dort löst das ursächliche Problem nicht. Und das ist, dass es so oder so evtl. länger als bei lokal angebundenen Tunern dauern kann, bin ein Lock da ist und Daten kommen. Ob die Tuner an oder aus sind, ändert nichts an deren Verfügbarkeit für den vdr selbst, also kann es nur was mit dem Zustand zu tun haben,,, Aber was jetzt da so "intelligent" ist, sehe ich im Code grad nicht...
> Das glaub ich so nicht, denn via Streamdev hatte ich immer ein Bild. Ich
> weiss natürlich nicht, ob der streamdev da irgendwas in der Richtung
> macht.
Die Auswahl der Tuner macht jede Datensenke selbst, von daher kann es da schon grosse Unterschiede geben.
> Rein Hypotethisch, was passiert wenn ich ein Tunertimeout von sagen wir 2
> min habe und der VDR bleibt 10 min auf ein und denselben kanal, gibt
> das mcli-plugin an den Netceiver eine Meldung ala "hier guckt noch
> jemand"? Was ist, wenn aus irgendeinem Grund eben diese Meldung
> wegbleibt und der tuner einfach ausgeht...
Das mcli-PI hat einen Timeout von 10 SEKUNDEN (!!!) für alle PID-Receiver, die keinen ganzen Service ziehen. Der vdr (und die diversen Plugins) gibt nämlich freiwillig (d.h. ohne Tunerknappheit) keine PIDs mehr her, wenn er mal den Tuner angefasst hat. Damit würden alle Tuner bis zum Abschalten belegt werden, und das nur für SI, EPG und so Kleinkram. Das würde die ganze Ressourcenverwaltung ruinieren.
Alle PIDs, die einem Service zugeordnet sind (also "Programme" fürs Schauen, Aufnehmen und Streamen) sorgen für einen regelmässigen Refresh aller abonierten Multicastgruppen übers Netz (d.h. alle ~10s geht per MLDv2 eine Liste aller gewünschten Transponder + deren PIDs raus). Damit haben die Multicastgruppen (MCG) für einen Transponder einen Usage Count !=0 im NetCeiver, daher läuft das Streaming der PIDs weiter. Im NetCeiver werden die MCG entweder aktiv über MLDv2 gelöscht (via DelPid() zB. beim Zappen) oder die Updates werden nicht mehr empfangen (Empfänger "verendet", spontan vom Netz gefallen, ...). Ohne Update gibts einen weiteren Timeout (auch 10s), der für jedes Empfänger<->MCG-Paar den MCG-Usage Count runterzählt. Ist er 0, will gar keiner mehr diese PID von dem Transponder haben und das Streaming dafür wird eingestellt (der NetCeiver streamt ja nur selektiv PIDs). Ist der Usage-Count für den Transponder insgesamt 0, fängt der Tuner Timeout an zu zählen.
Ist alles sehr schön zu sehen: Nimm netcvlogview (die NetCeiver-Logs werden auch per Multicast gesendet) und schau, was so passiert, wenn man den ganzen vdr "im Lauf" zB. per SIGSTOP oder Debugger anhält. Das triggert mangels MLD-Update die MCG-Timeouts, der Usage Count für den/die benutzten Tuner fällt sehr schnell auf 0. Wenn dann noch der Tuner Timeout kurz ist, wird kurze Zeit später BER auf "deaddead" gesetzt. Dann erst ist der Tuner (inkl. LNB-Versorgung) aus.
> hattest du mal zeit gehabt zu schauen?
Ja, Den DVB-register-Calls vom Kernel ist wieder mal ein neuer Parameter gewachsen. Leider hat C keine Default-Werte wie C++, damit würde das gar nicht auffallen. Compilieren tuts schon wieder, aber testen muss ich es noch.