Ich habe gerade mal was probiert, nämlich das amlSetInt("/sys/class/video/blackout_policy", 1); von Playmode 0 in Playmode 1 verschoben:
VideoDisplayWakeup();
amlSetInt("/sys/class/video/blackout_policy", 1);
Play();Ich habe den Eindruck, dass das Umschalten dadurch etwas fixer geht. Vielleicht ist aber auch eine Placebowirkung.
aber es werden dann ja bei jeder Ausführung von Clear unnötigerweise 3 Befehle ausgeführt, obwohl nur einer notwendig wäre. Das Abfragen des default-Wertes sollte m.E. nur 1x beim Öffnen des Plugins erfolgen und dann dieser Wert zurückgeschrieben werden beim Beenden.
naja, den Wert 1 brauchen wir ja, wenn wir bei PlayMode 0 (im wesentlichen also beim Umschalten) ein schwarzes Bild haben wollen. Wenn immer der letzte gesetzte Wert aktiv bleibt, würde nach dem ersten Spulen oder Springen ja der Wert 0 (letzten Frame einfrieren) auch beim Umschalten kommen, wenn da vorher nicht explizit wieder 1 gesetzt würde. Umgekehrt hättest Du nach dem ersten Umschalten beim nächsten Springen ein Schwarzbild, wenn dort über den Aufruf Clear->amlReset nicht vorher 0 gesetzt würde.
Welcher Wert dann beim Beenden des Plugins aktiv bleibt, könnte davon abhängen, ob zuletzt ein Clear oder ein Playmode 0 kam.
Wenn das für kodi überhaupt wichtig ist, müsste man den default Wert daher beim Beenden des Plugins setzen.
Aber Du hast recht, an der Umschaltgeschwindigkeit wird das nichts ändern. Ich bin dennoch der Meinung, dass man auf jedes nicht notwendige Kommando an den Treiber verzichten sollte - und sei es auch nur, weil der Kernel mit seinen vielen Decoderinfos so gesprächig ist.
Das Beenden eines Streams setzt immer erstmal einen Playmode 0 voraus, und dann kommt das Schwarzbild -das ist somit korrekt. Das Öffnen eines neuen Streams erfolgt über Playmode 1, und da hat diese Änderung keinen Einfluss.
Was Radioprogramme angeht: Nach meinen Tests bestand auch vorher schon das Problem, dass dort das Schwarzbild nicht greift - wahrscheinlich weil der Dekoder keine Videodaten kriegt. Insofern sollte diese Änderung da nichts verändert haben!
Dass bisher bereits ein Schwarzbild beim Umschalten kam dürfte daran liegen, dass die blackout_policy standardmäßig bereits 1 ist. Und Du setzt sie in amlReset ja jedesmal darauf zurück, wenn Du über Clear die 0 setzt.
Die jetzt erfolgte Änderung (bei Playmode 0 die blackout_policy 1 setzen) macht insoweit eigentlich nur Sinn, wenn Du gleichzeitig auch in amlReset generell 0 setzt (1 Befehl statt 3). Ansonsten bewirkt dieser neue commit im Ergebnis gar nichts, außer dass bei Playmode 0 jetzt ein Wert gesetzt wird, der zu diesem Zeitpunkt sowieso schon aktiv ist.
Ich habe hier einen X96 Max+ mit einer USB DVB-C Karte und da schaltet er in unter einer Sekunde um.
Verrätst Du mir bitte nochmal, was für ein USB device Du da hast? Hast Du es unter CoreElec mit ubuntu-chroot laufen? Verwendest Du die "latest" DVB-Treiber oder die crazycat-Treiber?
Es läuft under chroot mit den latest Dvb Treibern. Das Teil heisst CT2-4400v2 und ist von Technotrent.
Kannst Du die Technotrend-Box mal auf dem Odroid testen, wie dort die Umschaltzeit im Vergleich ist? Sie sollte dort sogar mit dem 4.9-Kernel von Hardkernel laufen, falls Du dort keinen CE-Kernel laufen hast.
Kannst Du die Technotrend-Box mal auf dem Odroid testen, wie dort die Umschaltzeit im Vergleich ist? Sie sollte dort sogar mit dem 4.9-Kernel von Hardkernel laufen, falls Du dort keinen CE-Kernel laufen hast.
Ja das kann ich tun. Komme aber erst am Montag dazu.
Na ja, zwischen unter einer Sekunde, wie Du zunächst zur X96 schriebst, und bis zu zwei Sekunden auf dem N2 ist schon ein deutlicher Unterschied. Schon eine halbe Sekunde Unterschied nimmt man wahr.
Welche CE Version hast Du auf der X96 laufen? Und welche Treiber? Für meine WinTv dual HD brauche ich die „latest DVB“. Mit dem für TBS optimierten Paket von crazycat läuft die Hauppauge nicht. Und andere DVB-Treiber von crazycat habe ich nicht im repository gefunden. Oder gibt es eines, das man manuell einbinden kann?
In einem anderen Thread hattest Du ja ein Abschalten der debugging Meldungen angeregt. Das wäre auch mein Tip - und am besten sollte man auch die ganzen debug- Meldungen von Amlogic im Kernel abstellen bzw. rauspatchen. Das könnte Einfluss auf die Umschaltdauer haben.
Ich glaube ich kauf mir mal so eine X96Max+. Die günstigere Tanix TX3 scheint es ja nicht mit Gigabit-LAN zu geben.
ist der Durchsatz denn wenigstens noch signifikant höher als 100 Mbit/s? Sonst kann man in der Tat auch gleich die Tanix TX3 kaufen. (In der Hoffnung, dass da dann auch nicht nur ein Bruchteil der 100 MBit/s erzielt werden)
Das ist ja auch nicht so der Hit. Dann kann ich auch eine Tanix nehmen. Braucht man 4 GB RAM? Hast Du CE auf der eMMC oder auf einer SD-Karte laufen? Meinst Du das macht von der Geschwindigkeit her einen großen Unterschied?
Eine Tanix TX3 2/16 oder 2/32GB kriegt man ja auch gebraucht schon sehr günstig.
Es ist eine 4GB Version, aber da noch ca. 3 GB frei sind wenn der VDR läuft denke ich das eine 2GB Version wohl auch läuft.
Ich habe immer alles auf einer SD Karte und nutze die interne eMMC gar nicht. Ich nutze zwar eine 32GB SD Karte, aber eine 8GB würde es wohl auch tun.
nur bekommt man die gar nicht mehr 
Also mit SD Karte ist die größe der eMMC egal.
Ich habe auf der X96 noch das kleine Display mit der Uhrzeit aktiv, das ist ganz nett.
Ein Display mit Uhrzeit hat die Tanix TX3 ja auch - und es wird von CE anscheinend auch unterstützt.
Bei mir gibt es bezüglich der Umschaltzeit übrigens keinen erkennbaren Unterschied, ob ich nun CE mit Ubuntu-chroot (von der eMMC) oder direkt Ubuntu (von SD-Karte) verwende.
Hat der Zabrimus CE-Kernel irgendwelche Vorteile gegenüber dem normalen CE-Kernel?
Don’t have an account yet? Register yourself now and be a part of our community!
