34 replies to this topic

[Frenske]

Hallo Frenske,

 

es ist schon seltsam dass es bei der Testbox von littlesat, wie auch bei meiner Box nicht funktioniert aber bei deiner Box schon?

Was hast du da für eine Zauberbox/Image wo alles ohne Fehler funzt?

 

Mikel

Es kommt vor das es unterschiede gibt in Muster die uns vom Hersteller zur Verfügung gestellt sind. Ob das bei mir und / oder Littlesat‘s Muster auch so ist, das kann ich mir nur abfragen.
 

Später Heute werde ich mit Littlesat testen.

[Frenske]

Ich habe trotz die schreckliche Temperatur noch einmal mit dem neuesten Release Image getestet und auch mit dem Release. Beide funktionieren bis jetzt einwandfrei wie du sehen kannst. Das Video ist zu groß um hier hinzu zu fügen. Dies kommt später noch.

[mikel]

Hello littlesat,

 

Here is the result.

 

At first glance, the result looks like yours.

 

Gruß Mikel

 

root@h9combo:~# mkdir test
root@h9combo:~# mount /dev/block/by-name/bootoptions test
root@h9combo:~# grep '' test/STARTUP_*

 

test/STARTUP_ANDROID:bootcmd=setenv vfd_msg andr;setenv bootargs $(bootargs) $(bootargs_common); run bootcmd_android; run bootcmd_fallback
test/STARTUP_ANDROID:bootargs=androidboot.selinux=enforcing androidboot.serialno=0123456789
test/STARTUP_ANDROID_DISABLE_LINUXSE:bootcmd=setenv vfd_msg andr;setenv bootargs $(bootargs) $(bootargs_common); run bootcmd_android; run bootcmd_fallback
test/STARTUP_ANDROID_DISABLE_LINUXSE:bootargs=androidboot.selinux=disable androidboot.serialno=0123456789
test/STARTUP_LINUX_1:bootcmd=setenv bootargs $(bootargs) $(bootargs_common); mmc read 0 0x1000000 0x3BD000 0x8000; bootm 0x1000000; run bootcmd_fallback
test/STARTUP_LINUX_1:bootargs=root=/dev/mmcblk0p23 rootsubdir=linuxrootfs1 rootfstype=ext4 kernel=/dev/mmcblk0p19
test/STARTUP_LINUX_2:bootcmd=setenv bootargs $(bootargs) $(bootargs_common); mmc read 0 0x1000000 0x3C5000 0x8000; bootm 0x1000000; run bootcmd_fallback
test/STARTUP_LINUX_2:bootargs=root=/dev/mmcblk0p23 rootsubdir=linuxrootfs2 rootfstype=ext4 kernel=/dev/mmcblk0p20
test/STARTUP_LINUX_3:bootcmd=setenv bootargs $(bootargs) $(bootargs_common); mmc read 0 0x1000000 0x3CD000 0x8000; bootm 0x1000000; run bootcmd_fallback
test/STARTUP_LINUX_3:bootargs=root=/dev/mmcblk0p23 rootsubdir=linuxrootfs3 rootfstype=ext4 kernel=/dev/mmcblk0p21
test/STARTUP_LINUX_4:bootcmd=setenv bootargs $(bootargs) $(bootargs_common); mmc read 0 0x1000000 0x3D5000 0x8000; bootm 0x1000000; run bootcmd_fallback
test/STARTUP_LINUX_4:bootargs=root=/dev/mmcblk0p23 rootsubdir=linuxrootfs4 rootfstype=ext4 kernel=/dev/mmcblk0p22
test/STARTUP_RECOVERY:bootcmd=setenv bootargs $(bootargs_common); mmc read 0 0x1000000 0x1000 0x9000; bootm 0x1000000

Edited by mikel, 5 August 2020 - 13:43.

[mikel]

Werde wohl über ein USB-Flash nicht herum kommen um das PIP mit einem Pli-Image zu nutzen!

 

Mikel

[Frenske]

Hier kannst du selber schauen was Ich getestet habe.

[mikel]

Hallo Frenske,

 

da hast du dir ja richtig Arbeit gemacht, schön das es funzt, werde wohl wie oben bereits geschrieben ein neuen USB-Flash machen müssen um diese unter Pli zu nutzen oder auf eines der beiden anderen Images gehen.

 

Danke für deine Mühe.

 

Gruß Mikel

[Frenske]

Leider muss ich mich korrigieren. Nachdem ich minutenlang mit PIP rumgespielt hatte, wie man eigentlich im Realität nie macht, hab ich endlich auch das von dir erwähnte Problem erfahren. Zum Glück lief ein Enigma Log gleichzeitig mit was ich mittlerweile schon an Littlesat geschickt habe. Ob dies überhaupt von uns zu lösen ist, das ist im Moment noch unbekannt. Jedenfalls konnte ich es nach langer Zeit rekonstruieren. Sonnst kann man nichts lösen wenn man nichts objektivieren kann. Ich hoffe das unsere Entwickler etwas mit dem Logdatei ausrichten können. 
Im Moment sind mehrere von unserem Entwickler im Urlaub und / oder sehr beschäftigt wegen Corona also kann dies mehr als ein Weilchen dauern bevor dies gelöst ist. Möglicherweise erst in 8.0.

[littlesat]

First let verify the STARTUP files Frenske has.... I hope they are different... when not then I speculate on the wrong 'joker'...

 

Here it goes wrong at the first attempt... I have picons in the box that are scaled... maybe that is also a faktor... (as they are accelerated).

Edited by littlesat, 5 August 2020 - 15:11.

[Frenske]

@littlesat

Check Mattermost.

[mikel]

First of all, thank you for your effort to eliminate this error, time will come, advice.

 

Greetings Mikel

 

Danke erstmal für eure Mühe diesen Fehler zu beseitigen, kommt Zeit, kommt Rat.

[mikel]

The Picons are probably complicit in the non-functioning PIP, as littlesat already found out in the report mentioned # 28. When I uninstalled the Picons, the PIP worked better, but then crashed after a while.

Edited by mikel, 7 August 2020 - 07:27.

[littlesat]

I still think it is a driver issue. When have a pig skin with small picture of the playable Servië (I assume this should be service) in menu. Other images default skins do not have that. Here it goes wrong as soon I’m going in a menu with pic. Other image do not have pig skins by default. I suggest there it also crashed when you select a screen there with pig. I suggest we need to forward this anomaly to the manufacturer.

So pressing menu and getting a pig screen (with smaller video) triggers the issue here!

Picons are not related.

Edited by Frenske, 9 August 2020 - 10:17.

[mikel]

Hello Pli-Team,

 

is there anything new about the PIP bug topic?

 

Thanks Mikel

[mikel]

Wann wird der Fehler behoben?

Edited by mikel, 29 September 2020 - 09:05.

[Frenske]

Wann wird der Fehler behoben?

Sobald Zgemma reagiert dann wird dies möglicherweise mal behoben werden. Es ist schon vor Wochen bei denen gemeldet soweit Ich mich erinnern kann.

Leider sind es noch immer oder sogar wieder seltsame Umstände weltweid. Das könnte zu Verzögerungen leiten.