Verbesserung des Umschaltverhaltens

[klausb]

Ich habe mich in der letzten Zeit öfter gefragt, warum sich das Umschalten auf meiner DBox2 mit Neutrino besser anfühlt als auf meinem HTPC mit DVBViewer.

 

Wenn man genauer hinsieht, stellt man fest, dass die Umschaltzeit nicht wesentlich verschieden ist. Der Unterschied hingegegen liegt in der Entkopplung von UI/OSD zum eigentlichen Umschaltprozess unter Neutrino. D.h. während der physikalischen Umschaltung kann ich weiter zappen. Wenn ich in der Phase des Tunens mehrere Sender überspringe, werden diese ignoriert. Also keine Queue.

 

Beim DVBViewer wird dagegen das UI/OSD blockiert, während auf der Sat-Karte neu getuned wird. Ich vermute aus diesem Grund wurde die Umschaltverzögerung eingeführt, um die Zapping-phase zu ermöglichen. Wenn man dann die eingestellte Anzahl von Millisekunden nix mach, wird erst umgeschaltet. Für mein Gefühl eher ein Workaround.

 

Mein Vorschlag wäre nun, das OSD beim Tuning nicht zu blockieren, sondern den Benutzer weiter zappen zu lassen. Nachdem ein neuer Sender eingestellt wurde (tuning beendet), kann DVBV checken, ob mittlerweile weitergezappt wurde und ggf. den neuen Sender einstellen.

 

Wie ist Eure Meinung dazu?

 

Gruss,

klaus.

Edited June 13, 2006 by klausb

[pagix]

Klingt grundsätzlich gut, fragt sich nur ob sowas ohne weiteres umsetzbar ist.

[klausb]

Klingt grundsätzlich gut, fragt sich nur ob sowas ohne weiteres umsetzbar ist.

<{POST_SNAPBACK}>

 

Ich gehe bei DVBV von einer multithreaded application aus. Es ist denkbar, dass nicht alles während des Tunens möglich ist. Aber der Kanalliste entlang zu laufen sollte doch möglich sein.

 

Am besten wir bekämen Info aus erster Hand :-)

 

klaus.

[Guest Lars_MQ]

Aber der Kanalliste entlang zu laufen sollte doch möglich sein.

ist es doch auch, dafür ist Umschaltverzögerung da.

[Griga]

Der will, dass wir das Tunen in einen separaten Thread auslagern...

 

@klausb: Interessante Idee. Arbeite das mal weiter aus.

 

Also der Anwender wählt einen Sender, und der Thread startet. Während er arbeitet, wird ein weiterer Sender angewählt. Was dann? Wie stelltst du dir die Synchronisation zwischen dem UI und dem Thread genau vor?

 

Zu berücksichtigen ist dabei, dass es je nach Treiber/Schnittstelle unterschiedlich abläuft. Bei manchen kehrt der Aufruf sofort zurück, während der Treiber im Hintergrund asynchron den Sender einstellt und den Stream startet. Bei anderen kehrt der Call erst zurück, wenn der Tuner auf die Frequenz eingerastet ist, oder, falls dies nicht gelingt, nach einem Timeout von z.B. 2500 ms. Und Treiber-Threads sind durch den DVBViewer natürlich nicht kontrollierbar.

[klausb]

@klausb: Interessante Idee. Arbeite das mal weiter aus.

 

Ok, habe ich gemacht. Ohne mich in vielen Worten zu verlieren habe ich das ganze mal als Pseudo-Code formuliert.

 

Ich treffe hier ein paar Annahmen:

 

1) Eine Variable (in unteren Fall newChannel) und ein Mutex-Objekt wird in 2 Threads verwendet.

 

2) Zuweisung von Variablen ist atomar. Das macht den code einfacher, da ich hier erstmal auf komplizierte Thread-Synchronisierung verzichten kann.

 

3) Das tunen eines Senders ist "blocking". D.h. der Treiber lagert das nicht selbst wieder in einen Thread aus. Griga hat auf diese Problematik schon hingewiesen. Manchmal ist das wohl nicht so. In solchen Fällen, würde ich versuchen auf den Vollzug des Treibers zu warten und dieses Warten ggf. in die tune-Methode zu verlagern.

 

So und hier etwas code:

 

Eine hypothetische switchChannel-Method, die vom UI gerufen wird

switchChannel( channel ) {
   newChannel = channel;
   mutex.notify(); // wecke tuner thread auf
}

 

Hier der hypothetische Tuner thread, der das Einstellen des Senders übernimmt

...
while( true ) {
   if ( currentChannel == newChannel ) // nix geändert worden
       mutex.wait();   // forever
   // Ann diesem Punkt sind wir entweder geweckt worden, oder
   // ein neuen Kanal ist angefordert worden, währen wir beim tunen waren
   // Wie auch immer, neuen Kanal merken und einstellen
   currentChannel = newChannel;
   tuner.tune( newChannel );   // Tuner blockt. Annahme (3) s.o.
}

 

Wichtig hier ist, das jeglicher Kanalwechsel, während der Tuner beschäftigt ist nicht gepuffert wird. Sondern erst, wenn der Tuner wieder bereit ist, wird der momentan aktuelle Kanal eingestellt. Im UI/OSD dagegen laufen die Kanäle durch und die Zap-Experience wird dadurch besser.

 

gruss,

klaus.

[klausb]

@Griga,

 

ist das mit dem Pseudo-Code nicht verständlich oder warum ist gerade alles so ruhig hier?

 

Gruss,

klaus.

[Griga]

Doch, das ist verständlich. Es ist ganz interessant, solche Ideen aufzugreifen und zu durchdenken. Aber es führt in diesem Fall nicht weit.

 

Das Einstellen eines Senders durch Absenden der Parameter an den Treiber ist nur ein relativ kleiner Teil dessen, was bei einem solchen Umschaltvorgang passiert. Es ranken sich 1001 andere Vorgänge drumherum, die neu organisiert und synchronisiert werden müssten, mit vielen potentiellen Fehlermöglichkeiten. Der Aufwand für ein "gefühlt" angenehmeres Zappen wäre sehr hoch, mitsamt den ausgiebigen Tests, die auf eine solch durchgreifende Änderung folgen müssten.

 

Kurz gesagt, die Kosten/Nutzen-Rechnung geht nicht auf. Es müssten schon weitere gewichtige Gründe dazukommen, damit es sich lohnt, sowas in Angriff zu nehmen.

[Guest Lars_MQ]

Wichtig hier ist, das jeglicher Kanalwechsel, während der Tuner beschäftigt ist nicht gepuffert wird. Sondern erst, wenn der Tuner wieder bereit ist, wird der momentan aktuelle Kanal eingestellt. Im UI/OSD dagegen laufen die Kanäle durch und die Zap-Experience wird dadurch besser.

Wo ist der genaue unterschied zur Umschaltverzögerung? ausser, das man im zweifel nachher nicht mehr weiss welcher kanal sich grade getuned hat, weil man schon 3 kanäle im OSD weiter ist? Und das sich Im OSD channel getuned und channelvorschau die klinke in die hand geben würden...

 

Ich sehe dort weder eine wirkliche Verbesserung noch einen komfort gewinn, auch wenn ich zugeben muss, dass der gedanke mit dem tuning thread schon vor zwei monaten bei mir aufkam, aber nach kurzer bestandsaufnahme schnell wieder fallen gelassen wurde, da die Änderungen zu umfangreich gewesen wären und sich auch kein echter nutzen gezeigt hat.

 

Achja, ein argument aber die neutrino kann das, zieht nicht, oder verwaltet Neutrino n-Karten in gemischter empfangsart inklusive netzwerkdevices und anderem krimskrams?

[dgdg]

Wo ist der genaue unterschied zur Umschaltverzögerung? ausser, das man im zweifel nachher nicht mehr weiss welcher kanal sich grade getuned hat, weil man schon 3 kanäle im OSD weiter ist? Und das sich Im OSD channel getuned und channelvorschau die klinke in die hand geben würden...

 

Wenn das Sender-Logo und die Kanal-Nummer immer sofort eingeblendet würden, dann wüsste man beim Zappen immer, wo man ist. Man könnte sehe schnell mal 4 oder 5 Kanäle weiterzappen ohne dass man bei jedem Kanal warten muss, bis der getuned ist.

 

Dem Komfort käme das sehr zu Gute.

 

Aber ob man das dann im Zusammenspiel mit allen Komponenten so reibungslos und flüssig hinbekommt, wie man sich das vielleicht theoretisch vorstellt - da hab ich so meine Zweifel.

 

Und dank EPG-Übericht im OSD (OSD-Gelb) kann man mit DVBViewer sowieso sehr gezielt "zappen".

 

Gruß, dgdg

Edited June 18, 2006 by dgdg

[Guest Lars_MQ]

Wenn das Sender-Logo und die Kanal-Nummer immer sofort eingeblendet würden, dann wüsste man beim Zappen immer, wo man ist. Man könnte sehe schnell mal 4 oder 5 Kanäle weiterzappen ohne dass man bei jedem Kanal warten muss, bis der getuned ist.

Genau das macht die Umschaltverzögerung. ich zappe 3 kanäle weiter, sehe dabei das miniepg des jeweiligen kanals, kann schauen was da ist und wenns mir gefällt zappe ich nicht weiter und der kanal wird getuned.

[gwr]

Also bei meiner Skystar 2.6c ist ja fast schon so wie gewünscht

Umschaltverzögerung hatte ich im GE schon lange aus und jetzt auch bei der Beta 3.4.12.1.

Ehe der Videodecoder das neue Bild aufgebaut hat kann ich meist schon weiterschalten,

so das nur das mini-EPG und die Kanalbildchen wechseln. Der Viewer und mein

Lieblings-Treiber 4.3.1 Beta halten das aus.

Anders sieht es bei meiner neuen Nova-S-Plus aus, da kann ich erst weiterzappen, wenn

das Bild da ist, müsste also die Umschaltverzögerung wieder einschalten um schnell zu

zappen.

Wenn ich beim GE "Tuningspace benutzen" ausschalte, geht es wie bei der Skystar 2.

Bei der Beta gibt es diese Option nicht mehr, oder ich hab sie noch nicht gefunden.

Benutzt die Beta immer Tuningspace bei der Nova?

 

mfG Gerd

 

Nachtrag: kleiner Fehler meinerseits die Beta schaltet auch bei der Nova sofort weiter,

nur das Mini-EPG und das Bildchen bleibt stehen, so das ich blind zappe. genauso

ist es beim Ge mit Tuningspace.

 

achso: so wie ich da vorgehe, das ist natürlich nicht gerade förderlich für die

Stabilität des Viewers, deshalb gibt es ja die Umschaltverzogerung, damit der Tuner

nicht im SekundenTakt arbeiten muß!!! nur bevor Beschwerden kommen

Edited June 18, 2006 by gwr

[Griga]

Anders sieht es bei meiner neuen Nova-S-Plus aus, da kann ich erst weiterzappen, wenn das Bild da ist,

Tip: Falls DiSEqC nicht benötigt wird, alle Sender in der Kanalliste auf DiSEqC = None setzen. Dann geht es schneller, und ist insbesondere in einer Shared LNB-Konfiguration auch sicherer - das DiSEqC-Signal der einen Karte kann u.U. der anderen Karte ein paar Diskontinuitäten verpassen.

 

Benutzt die Beta immer Tuningspace bei der Nova?

Ja, bei allen BDA-Geräten. Ohne ist direkter und schneller, funktioniert aber nicht mit allen Karten (z.B.nicht mit FireDTV, wie ich gehört habe).

[gwr]

Tip: Falls DiSEqC nicht benötigt wird, alle Sender in der Kanalliste auf DiSEqC = None setzen. Dann geht es schneller, und ist insbesondere in einer Shared LNB-Konfiguration auch sicherer - das DiSEqC-Signal der einen Karte kann u.U. der anderen Karte ein paar Diskontinuitäten verpassen.

 

Danke für den Tip, das habe ich schon gemacht. geht auch schneller.

mit den Diskontiniutäten ist es so, daß beim Zappen mit der SS2 die Nova Discos hat,

umgekehrt nicht. Nehmen allerdings beide auf, so das die SS2 nicht den Transponder

wechseln kann, so bekommt die Nova keine Discos.

Meine Vermutung ist, das die LNB-Spannung der SS2 etwas höher ist und beim Tunen schwankt.

 

Tschuldigung das hat jetzt mit dem Thema nix zu tun.

 

mfG Gerd

[dgdg]

Wenn das Sender-Logo und die Kanal-Nummer immer sofort eingeblendet würden, dann wüsste man beim Zappen immer, wo man ist. Man könnte sehe schnell mal 4 oder 5 Kanäle weiterzappen ohne dass man bei jedem Kanal warten muss, bis der getuned ist.

Genau das macht die Umschaltverzögerung. ich zappe 3 kanäle weiter, sehe dabei das miniepg des jeweiligen kanals, kann schauen was da ist und wenns mir gefällt zappe ich nicht weiter und der kanal wird getuned.

<{POST_SNAPBACK}>

 

Stimmt! War mir gar nicht so aufgefallen, weil ich DVBViewer ja nicht zum Zappen verwende. Ich hatte zwar die Einstellung in den Optionen schonmal gesehen, aber nicht verstanden, wozu man das braucht ;-)

 

Na dann ist doch alles bestens.

 

Gruß, dgdg

[klausb]

Achja, ein argument aber die neutrino kann das, zieht nicht, oder verwaltet Neutrino n-Karten in gemischter empfangsart inklusive netzwerkdevices und anderem krimskrams?

 

Nicht aufregen :-)

 

War nur als ein 'anderer' Sat-Receiver gedacht. Ich hab halt nur noch den. Aber wie auch immer, ein "Kunde" stellt halt solche Fragen.

 

Ich honoriere sehr wohl die Tatsache, dass DVBViewer viel KrimsKrams drumherum macht und das ganze nicht trivial ist. Andererseits bin ich von einer Trennung zwischen UI und Applikation ausgegangen. Und zwischen diese Trennlinie noch einen Thread einzubauen erschien mir machbar.

 

Ok. Soll nicht sein. Was mich stört ist lediglich das Blockieren des gesamten Systems, wenn die Umschaltverzögerung abläuft und die Karte den Sender einstellt. Es passiert mit sehr oft, dass ich beim lesen des MiniEPGs die Verzögerung 'verpasse' und dann beim Weiterzappen hängt erst mal alles. Die Verzögerung länger zu machen finde ich dagegen kontraproduktiv, wenn man einfach weiter schaltet. Genau diese Unterscheidung zw. unentschlossenem Zappen und "nächster Kanal" sollte durch diesen Vorschlag entschärft werden.

 

Jetzt habe ich aus der Diskussion das Gefühl, dass es durch ein paar Einstellungen bzw. den richtigen SkyStar Treiber kein Blockieren gibt. Ist das richtig rüber gekommen oder hab ich das falsch verstanden?

 

@gwr: Ich glaube bei Dir läuft das rund. Ist das ein anderes Verhalten der GE-Version gegenüber der Pro?

 

Gruss,

klaus.

[Guest Lars_MQ]

Skystar Umschalten ist bei Pro und GE nahezu identisch. Untersuche lieber deine Einstellungen genauer (Fastchannelswitch an / detect video und audio aus / vernünftiger video decoder...) und die aktuelle Pro 3.5 natürlich.

[klausb]

Skystar Umschalten ist bei Pro und GE nahezu identisch. Untersuche lieber deine Einstellungen genauer (Fastchannelswitch an / detect video und audio aus / vernünftiger video decoder...) und die aktuelle Pro 3.5 natürlich.

<{POST_SNAPBACK}>

 

Habs mal so eingestellt. Geht wirklich schneller. Auch das weiterzappen während des Kanalwechsels ist ok. Finde ich gut so!!

 

Das mit detect video/audio aus war mir neu. Um ehrlich zu sein, habe ich diesen Switch nie richtig verstanden. Sollte mal doku lesen ;-)

 

Gruss,

klaus.