Diskussion erbeten: Änderung cDevice::Receiving

In 1.7.25 gab es ja allerlei Änderungen unter der Überschrift "Revised priority handling to allow receivers with a priority that is lower than that of live viewing".
Sinn und Zweck war nach meiner Erinnerung u.a., ein Problem im Zusammenspiel mit osdteletext zu lösen, dass z.B. Udo Richter für FF-Karten untersucht hatte.

So wie es jetzt (getestet mit 2.1.2) ist, gibt es nun jedoch ein Problem bei Systemen ohne FF-Karte und im Zusammenspiel mit devices wie iptv oder pvrinput. Folgendes Szenario:
-osdteletext-Plugin läuft
-LiveView von einem iptv- oder pvrinput-Kanal, der Teletextdaten liefert
-Abspielen einer Aufzeichnung und danach Beenden der Wiedergabe mit Rückkehr zum letzten Kanal
Ergebnis: der zuletzt gesehene Kanal bleibt schwarz und stumm

Ich habe zahlreiche Debug-Meldungen im Code verstreut und das näher analysiert.
Die Funktion MaySwitchTransponder() liefert als return-Wert 0, weil Receiving() true zurückliefert. Dies führt dazu, dass GetDevice, SwitchChannel und SetChannel nie aufgerufen werden. Somit erfolgt auch nie die Information des osdteletext-Plugins mittels MsgChannelSwitch, dass es seinen receiver detachen soll.

Bei DVB-Kanälen tritt dieses Problem deshalb nicht auf, weil in GetDeviceForTransponder zuvor bereits die Bedingung ' if (d->IsTunedToTransponder(Channel))' zutrifft. Nun ist die Funktion IsTunedToTransponder m.E. aber DVB-spezifisch. Deshalb gibt es sie bei pvrinput und iptv nicht (weil es dort auch keine Transponder gibt).

Ich konnte das Problem dadurch lösen, dass ich in Receiving() solche Receiver, die wie osdteletext eine Priorität kleiner als Null haben, wieder unberücksichtigt lasse (ähnlich wie in 1.7.24):

bool cDevice::Receiving(bool Dummy) const
{
   cMutexLock MutexLock(&mutexReceiver);
   for (int i = 0; i < MAXRECEIVERS; i++) {
       //if (receiver[i])
       if (receiver[i] && receiver[i]->priority >= 0) // cReceiver with priority < 0 doesn't count
          return true;
       }
   return false;
}

Damit ist dann auch wieder das gewährleistet, was in PLUGINS.html im Abschnitt zu Receivers steht:

Zitat

The above example sets up a receiver that wants to receive data from only one PID (for example the Teletext PID). In order to not interfere with other recording operations, it sets its priority to -1 (any negative value will allow a cReceiver to be detached from its cDevice at any time in favor of a timer recording or live viewing).

Ich habe die vorgeschlagene Änderung bereits Klaus vorgestellt. Er hat damit grundsätzlich kein Problem und würde sie auch in der nächsten Version sowie auch im nächsten 2.0.x Maintenance-Release übernehmen. Er bittet jedoch darum, dass ich das hier vorhe rmal zur Diskussion stelle. Was ich hiermit tue

Wäre schön, wenn das möglichst viele Leute auch im Hinblick auf unerwünschte Nebenwirkungen testen würden.

ich denke dann eher an ein bool IsTunedToChannel, dass dann analog zu IsTunedToTransponder für jedes device verpflichtend wäre.
Jedes Device verwendet Kanäle, mit welchen Parametern auch immer. Das device muss dann prüfen und zurückmelden, ob es bereits exakt den angeforderten Kanal empfängt.
Es geht an dieser Stelle nicht darum festzustellen, ob das device einen Kanal zusätzlich empfangen kann. Wir wollen ja gerade nicht auf eine positive Rückmeldung von MaySwitchTransponder angewiesen sein, sondern schon vorher in GetDeviceForTransponder das device als return zurückgeben.

Wir müssen uns nur darüber im klaren sein, dass das ein API break ist und alles devices angepasst werden müssen. Es stelt sich die Frage, ob das für vdr 2.0.x in Frage kommt. Einen Fix des Problems in der aktuellen stable-Version halte ich jedoch für notwendig.

Ich halte die Änderung in Receiving() für die einfachere Variante, zumal es die Rücknahme einer früheren Änderung und nichts grundsätzliches neues wäre.

Zitat von mini73

Ich denke, ich verstehe die Funktionen richtig, werde sie heute Abend, spätestens Mittwoch in pvrinput einbauen.

Lars.

wenn Du testest, berücksichtige bitte, dass das beschriebene Problem im Zuammenhang mit osdteletext nur dann auftritt, wenn Teletext im pvrinput-Plugin gefixt ist. Der VBIMode darf seit einiger Zeit nicht mehr auf dem mpeg-device gesetzt werden - das ioctl muss nun auf das vbi device angewandt werden. Ich habe einen quick-and-dirty fix für die PVR350 zuhause, und die richtige Implementierung (Ermittlung des passenden vbi-devices analog radio device) habe ich auf meiner To-Do-Liste

als Threadstarter ist es dann wohl an mir zu verkünden, dass das Problem gelöst ist und eine Änderung in Receiving() nicht notwendig ist. Sowohl iptv (2.0.1) als auch pvrinput (akt. git) haben inzwischen die Funktion IsTunedToTransponder() implementiert und liefern true zurück, wenn die ChannelID zwischen angefordertem und aktuellem Kanal übereinstimmt. Damit ist das hier beschriebene Problem zumindest für diese beiden input-Plugins gelöst. Mir fällt ansonsten nur noch streamdev-client ein. Dort ist die Funktion bereits drin, jedoch wird dort nicht die ChannelID verglichen, sondern nur der Transponder:

#if APIVERSNUM >= 10722
bool cStreamdevDevice::IsTunedToTransponder(const cChannel *Channel) const
#else
bool cStreamdevDevice::IsTunedToTransponder(const cChannel *Channel)
#endif
{
	return m_ClientSocket->DataSocket(siLive) != NULL &&
			m_Channel != NULL &&
			Channel->Transponder() == m_Channel->Transponder();
}

Nach der Kanalsyntax von pvrinput oder iptv-Kanal können verschiedene Kanäle durchaus die gleiche Frequenz haben. Ob es deshalb im Zusammenspiel zwischen pvrinput/iptv-Kanälen und streamdev zu Problemen kommen kann, überblicke ich nicht richtig. Ich halte es aber für wahrscheinlich und meine, es wäre besser, wenn streamdev hier auch die eindeutige ChannelID prüfen würde. Was meinst Du, Lars?