[Wanninger]

@niedi_74

Meine Wetek ist eine mit original Android drauf. Da habe ich sowas noch nicht beobachten können.

Ein Bekannter hat auch eine Openelec Wetek, und der hat das von dir beschriebene Problem auch
schon ein paar mal gehabt, nachdem er openHDF oder openATV von SD gebootet hat.

Das Ganze ging bei Ihm jetzt soweit, dass er anscheinend das NAND so "verbogen" hat, dass die
Box nur in einem Bootloop hängt. Sogar ein neu Flashen klappt nicht mehr...

...strange

-Wanninger

[niedi_74]

ok, ich habe ein openelec version.  openatv und co laufen von Micro sdkarte und danach macht das openelec im NAND keine probleme.
auch das re-install vom Openelec klappt soweit.

werde bei Gelegenheit mal "WeTek's Android software to the latest OTA version first" versuchen.

evtl hilft das ja ...

gruß
karsten

[Wanninger]

...pass aber auf, die Version 1.1.7 von Wetek hatte/hat den Fehler,
dass nicht mehr von SD Karte gebootet werden konnte.
Ich bin dann auf die Version 1.1.6 zurück gegangen. Da ging's noch.
Aktueller sind meine Infos dazu aber auch nicht.

-Wanninger

[TimUx]

Hallo zusammen,
meine WETEK bootet nach wie vor nicht mit der MLD 5.1, es bleibt ein schwarzer Monitor.

Ich habe folgendes Image verwendet:

"MLD-5.1_netinstall_2016.04.24-172.12+1539_armhf-wtk"

Gruß Timo

[Wanninger]

Ist das verhalten dann so ähnlich, wie ich hier
http://www.minidvblinux.de/forum/index.php/topic,7578.msg57391.html#msg57391
beschrieben habe?

[TimUx]

Hi,
das netinstall bootet erst überhaupt nicht., von Anfang an und immer schwarzer Monitor. ;-)

Ich habe dann mal ein customized client-satip installiert.
Hier scheint es sich genau wie bei dir beschrieben zu verhalten.

Gruß Timo

[niedi_74]

...pass aber auf, die Version 1.1.7 von Wetek hatte/hat den Fehler,
dass nicht mehr von SD Karte gebootet werden konnte.
Ich bin dann auf die Version 1.1.6 zurück gegangen. Da ging's noch.
Aktueller sind meine Infos dazu aber auch nicht.

-Wanninger

heute ist noch eine Wetek angekommen,  auf der kann ich MLD booten und benutzen ( soweit es halt möglich ist) und wenn ich die Micro sd karte raus nehme funktioniert das Openelec im NAND ohne probleme.
werde Wetek mal anfragen wo bei den Boxen der unterschied ist .....

[P3f]

Hi Timo,

Entschuldige bitte die vielleicht dumme Nachfrage, aber auch nachdem ich noch einmal das bereitgestellte Image erneut runtergelassen habe, wird davon gebotet und man kommt mit dem Netzwerk drauf. Kann dann auch das Wunschimage installieren und kommt dann an die Fehler, wie hier ja schon beschrieben.

Ich hatte auch erst immer nur einen schwarzen Bildschirm bei den Images, das lag aber an mir, Wiehl ich immer das Image auf die SD-Karte kopiert (mit dd) hatte. Aber es wird halt einzig drauf kopiert, also nachdem man die SD Karte als FAT32 formatiert hat, dann einfach die Datei aus dem tgz-File entpackt drauf kopieren, und schon bootet die WeTek mit der MLD5.1

Nicht das Dir das auch passiert(e). Es ist sozusagen kein Image, welches mit dd, Applebi-Baker oder unetbootin installiert wird.

Will nur sicher gehen, das du nicht auch in die Falle gehst. Hoffe es ist ok, mit meiner Frage.

Gruß,

Pit

Hi,
das netinstall bootet erst überhaupt nicht., von Anfang an und immer schwarzer Monitor. ;-)

Ich habe dann mal ein customized client-satip installiert.
Hier scheint es sich genau wie bei dir beschrieben zu verhalten.

Gruß Timo

[TimUx]

Hi Pit,
Nein nein, ich habe schon die Files entpackt und auf die fat32 Partition kopiert.

Mit dem neusten Image vom 28.04. Bootet die wetek mittlerweile auch und kann installiert werden.

Allerdings bleibt mittlerweile der Monitor schwarz, sobald der vdr gestartet werden.

Gruß Timo

[decembersoul]

so nach einigen Fehlversuchen bin ich nun auch so weit wie TimUx.

im Logfile steht:

Code: [Select]

Apr 30 21:44:00 (MLD-WeTek) user.warn kernel: [   72.311898@0] cec TX status: rx: 0x0; tx: 0x2
Apr 30 21:44:05 (MLD-WeTek) user.err vdr: [3812] amlhddevice: failed to write U:1280x720p-0  to /sys/class/graphics/fb1/mode (-12)
Apr 30 21:44:07 (MLD-WeTek) user.warn kernel: [   79.391953@0] cec TX status: rx: 0x0; tx: 0x2
Apr 30 21:44:15 (MLD-WeTek) user.warn kernel: [   87.572014@0] cec TX status: rx: 0x0; tx: 0x2
Apr 30 21:44:17 (MLD-WeTek) user.err vdr: [3957] amlhddevice: failed to write U:1280x720p-0  to /sys/class/graphics/fb1/mode (-12)
Apr 30 21:44:22 (MLD-WeTek) user.warn kernel: [   94.672067@0] cec TX status: rx: 0x0; tx: 0x2

und im vdr logfile

Code: [Select]

VDR exits at Sa Apr 30 21:44:06 CEST 2016
Segmentation fault

[decembersoul]

Code: [Select]

MLD> echo "U:1280x720p-0" > /sys/class/graphics/fb1/mode
sh: write error: Cannot allocate memory

Wenn ich VDR mit max loglevel starte, dann kann ich das hier noch sehen

Code: [Select]

Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13082] video directory scanner thread ended (pid=13081, tid=13082)
Apr 30 21:57:28 (MLD-WeTek) local7.info vdr: [13081] initializing plugin: amlhddevice (0.0.1): HD output device for Amlogic SoC
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13081] new device number 1
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13081] cTimeMs: using monotonic clock (resolution is 1 ns)
Apr 30 21:57:28 (MLD-WeTek) local7.err vdr: [13081] amlhddevice: failed to write U:1280x720p-0  to /sys/class/graphics/fb1/mode (-12)
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13083] video directory scanner thread started (pid=13081, tid=13083, prio=high)
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13084] epg data reader thread started (pid=13081, tid=13084, prio=high)
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13083] video directory scanner thread ended (pid=13081, tid=13083)
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13084] reading EPG data from /var/cache/vdr/epg.data
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13084] epg data reader thread ended (pid=13081, tid=13084)
Apr 30 21:57:28 (MLD-WeTek) local7.info vdr: [13081] setting primary device to 1
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13081] amlhddevice: new cOsdProvider()
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13081] assuming manual start of VDR
Apr 30 21:57:28 (MLD-WeTek) local7.info vdr: [13081] SVDRP listening on port 6419
Apr 30 21:57:28 (MLD-WeTek) local7.info vdr: [13081] setting current skin to "lcars"
Apr 30 21:57:28 (MLD-WeTek) local7.info vdr: [13081] loading /etc/vdr/themes/lcars-default.theme
Apr 30 21:57:28 (MLD-WeTek) local7.info vdr: [13081] starting plugin: amlhddevice
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13085] LIRC remote control thread started (pid=13081, tid=13085, prio=high)
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13081] remote control LIRC - keys known
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13081] remote control KBD - keys known
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13081] setting watchdog timer to 60 seconds
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13081] OSD size changed to 1280x720 @ 1,77778
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13086] KBD remote control thread started (pid=13081, tid=13086, prio=high)
Apr 30 21:57:28 (MLD-WeTek) local7.debug vdr: [13081] amlhddevice: opened OSD frame buffer 1280x720, 32bpp
Danach ist Ende.

Ich versuche mal ob ich ihn dazu bekomme mit einer Geringeren Auflösung zu starten.

[clausmuus]

Hi Pit,

ich hatte gerade vor ein paar Tagen im VDR Portal gelesen, dass die beiden Framebuffer (OSD und Video (fb0 und fb1)) vertauscht sein können. Ob das im Kernel oder im VDR Plugin angepasst werden muss, hatte ich aber nicht verstanden.

Als wir mit dem Plugin angefangen hatten, hatten wir sowas mit dem zu kleinen Grafikspeicher doch schon mal. Vielleicht ist es ja auch nur sowas. Ich weiß aber nicht mehr wie das geändert wurde.

Claus

[decembersoul]

Wie sieht es nun aus?
Ist da udev drauf das ich die devices mal vertauschen kann?
Wenn das wirklich der Fall ist, dann dürfte es ja bei keinem gehen.

[rfehr]

Hi Pit,

ich hatte gerade vor ein paar Tagen im VDR Portal gelesen, dass die beiden Framebuffer (OSD und Video (fb0 und fb1)) vertauscht sein können. Ob das im Kernel oder im VDR Plugin angepasst werden muss, hatte ich aber nicht verstanden.

Als wir mit dem Plugin angefangen hatten, hatten wir sowas mit dem zu kleinen Grafikspeicher doch schon mal. Vielleicht ist es ja auch nur sowas. Ich weiß aber nicht mehr wie das geändert wurde.

Claus

Für den Grafikspeicher haben wir einen patch drin '18_linux_wetekplay_dtd.patch.wtk'.

Gruß,
  Roland

[decembersoul]

ok, bedeutet es das es nicht das Problem sein kann?
Hat jemand das Image denn auf der Box am laufen?