Login at Kodi Home

lekand · 2016-07-29, 21:36

(2016-07-29, 20:29)Eve72 Wrote:
(2016-07-29, 17:08)lekand Wrote: Hi,

I'm sorry a few of you are having issues with the Hub. I'm pretty sure most of them will be ironed out in time. I myself had a problem with colors flipping on me, all screen becoming greenish (both under Android and the LibreELEC 7.0.2 version kindly provided by wrxtasy). I wrote to WeTek support and they have been really amazing. I asked for a replacement, because I was convinced there was a hardware issue. They asked for a video of the problem. After 24hours they get back to me, saying that they have traced down the problem as a bug when coupling the hub to some Philips TVs, and that a replacement would have the same issue. In the same message they provided a custom Hub firmware with a new option under Android to force RGB colorspace. I installed it, switched on RGB as instructed, and the problem is gone. I'm even getting a more stable Kodi 17 experience now (might be subjective, though I've not had a single crash). They tell me also that they've contacted the LibreELEC team (wrxtasy?) to include this new option there.

How's that for technical support? I, for one, have never seen anything like it. Kudos to WeTek!

I´ve also had problems colors flipping, though in my case the screen isn´t greenish but pinkish. The problem has fortunately only occured a few times. At first I assumed it was caused by bad wire connection but it turned out false. Luckily rebooting the TV gave the needed fix.

I´m very interested in the solution you @lekand received from Wetek. Should I also contact Wetek to be provided with the custom Hub firmware that you mentioned?

My Hub is connected first to my AVR and second my Philips 55PUS7600 TV.

Hi Eve72, I guess you should ask them for the link, I'm not sure I'm supposed to distribute it. Mention ticket number #13470.

The solution, I have to say, is still partial. Using the bundled HDMI cable I've still seen 3 color flips to green/pink in about 5 hours. Before the patch it was constant, every 2 minutes. Using a more expensive HDMI cable I've not had the issue at all after the patch. Good luck!

Draghmar · 2016-07-29, 22:05

(2016-07-29, 18:39)wrxtasy Wrote: The problem is not with the Hub but actually some models of older Philips and Sony TV's that have a bug in their HDMI implementation that sometimes triggers the selection of the wrong colorspace resulting in a magenta/green display.

Is there a list of models that can have this issue? I have quite old Sony TV so would be great to know that before I get my hands on Play2 Tongue

~~Ned Scott~~ · 2016-07-29, 22:59

(2016-07-29, 21:36)lekand Wrote: Hi Eve72, I guess you should ask them for the link, I'm not sure I'm supposed to distribute it. Mention ticket number #13470.

The solution, I have to say, is still partial. Using the bundled HDMI cable I've still seen 3 color flips to green/pink in about 5 hours. Before the patch it was constant, every 2 minutes. Using a more expensive HDMI cable I've not had the issue at all after the patch. Good luck!

I would guess they will include the RGB option in upcoming firmware versions. As for the HDMI cable, it's very cheap and should just be thrown away. It's not up to HDMI specs for an HDMI cable.

wrxtasy · 2016-07-30, 04:02

(2016-07-29, 22:05)Draghmar Wrote:
(2016-07-29, 18:39)wrxtasy Wrote: The problem is not with the Hub but actually some models of older Philips and Sony TV's that have a bug in their HDMI implementation that sometimes triggers the selection of the wrong colorspace resulting in a magenta/green display.
Is there a list of models that can have this issue? I have quite old Sony TV so would be great to know that before I get my hands on Play2

You will have to google this issue searching for your particular TV model yourself. In the past even Apple hardware was not immune to this problem either:
https://discussions.apple.com/thread/260...0&tstart=0

wrxtasy · (This post was last modified: 2016-07-30, 06:40 by wrxtasy.)

(2016-07-29, 20:46)lekand Wrote:
(2016-07-29, 18:39)wrxtasy Wrote: Other way around, we already had a solution from LE C2 development
There is no easy boot.ini switch for LE on the Hub yet however. Likely a custom LE release will come when i can sit down and patch.
There is a pretty healthy AML development community sharing ideas at the moment.

The problem is not with the Hub but actually some models of older Philips and Sony TV's that have a bug in their HDMI implementation that sometimes triggers the selection of the wrong colorspace resulting in a magenta/green display.
The MINIX U1 also has the same problem, so does the ODROID C2 with these TV's - both already had fixes.

You basically have to force an RGB colorspace output to these problem TV's with a user selectable switch.

How amazing! Ok, now the turnaround time doesn't seem so supernatural This developer environment you guys have created is what makes all the difference with these machines. Many many thanks! Any clue when the LibreELEC version with a fix will be available?

Patched the Kernel for LE on the Hub as well to force RGB colorspace output (untested ATM as my TV is fine):
Follow the link HERE

lekand · 2016-07-30, 11:42

(2016-07-30, 06:33)wrxtasy Wrote:
(2016-07-29, 20:46)lekand Wrote:
(2016-07-29, 18:39)wrxtasy Wrote: Other way around, we already had a solution from LE C2 development
There is no easy boot.ini switch for LE on the Hub yet however. Likely a custom LE release will come when i can sit down and patch.
There is a pretty healthy AML development community sharing ideas at the moment.

The problem is not with the Hub but actually some models of older Philips and Sony TV's that have a bug in their HDMI implementation that sometimes triggers the selection of the wrong colorspace resulting in a magenta/green display.
The MINIX U1 also has the same problem, so does the ODROID C2 with these TV's - both already had fixes.

You basically have to force an RGB colorspace output to these problem TV's with a user selectable switch.

How amazing! Ok, now the turnaround time doesn't seem so supernatural This developer environment you guys have created is what makes all the difference with these machines. Many many thanks! Any clue when the LibreELEC version with a fix will be available?
Patched the Kernel for LE on the Hub as well to force RGB colorspace output (untested ATM as my TV is fine):
Follow the link HERE

Mmm, it doesn't work it seems. I got 'solarized' within minutes of booting with the patch. Do I have to do anything within settings like under Android, perhaps?

wrxtasy · 2016-07-30, 12:23

No that LE .tar is hardcoded to output RGB, there are no settings to change. Same patch has been working over on LE on the ODROID C2 S905's...
If you SSH login and look at the Kernel log, you find this as a confirmation as well that RGB has been forced.

Code:
dmesg

[ 0.000000@0] Forced RGB colorspace output

I would play with the TV settings and change between Full and Limited RGB, that probably won't help much tho...
or maybe even swap HDMI cables.

lekand · 2016-07-30, 12:52

(2016-07-30, 12:23)wrxtasy Wrote: No that LE .tar is hardcoded to output RGB, there are no settings to change. Same patch has been working over on LE on the ODROID C2 S905's...
If you SSH login and look at the Kernel log, you find this as a confirmation as well that RGB has been forced.

Code:
dmesg

[ 0.000000@0] Forced RGB colorspace output

I would play with the TV settings and change between Full and Limited RGB, that probably won't help much tho...
or maybe even swap HDMI cables.

Uhm! Nope, that does not show up in my kernel log! Confused

I'll try to flash your LE version again...[/code]

lekand · 2016-07-30, 13:04

(2016-07-30, 12:52)lekand Wrote:
(2016-07-30, 12:23)wrxtasy Wrote: No that LE .tar is hardcoded to output RGB, there are no settings to change. Same patch has been working over on LE on the ODROID C2 S905's...
If you SSH login and look at the Kernel log, you find this as a confirmation as well that RGB has been forced.

Code:
dmesg

[ 0.000000@0] Forced RGB colorspace output

I would play with the TV settings and change between Full and Limited RGB, that probably won't help much tho...
or maybe even swap HDMI cables.

Uhm! Nope, that does not show up in my kernel log! I'll try to flash your LE version again...[/code]

Ok, reinstalled the patch, but no dice... I might have done something wrong... I copied the image in the Update folder, and rebooted. I got the update routine, all seemed fine. The beginning of the kernel log is:

Code:
[    0.000000@0] Linux version 3.14.29 (wrxtasy@OE-Build-Box) (gcc version 5.3.0 (GCC) ) #1 SMP Sat Jul 30 16:05:31 AWST 2016

[    0.000000@0] CPU: AArch64 Processor [410fd034] revision 4

[    0.000000@0] bootconsole [earlycon0] enabled

[    0.000000@0] secmon: share mem setup

[    0.000000@0] Reserved memory: initialized node linux,secmon, compatible id aml_secmon_memory

[    0.000000@0] __reserved_mem_alloc_size: linux,meson-fb

[    0.000000@0] fb: Reserved memory: created fb at 0x000000003bb80000, size 68 MiB

[    0.000000@0] Reserved memory: initialized node linux,meson-fb, compatible id amlogic, fb-memory

[    0.000000@0] __reserved_mem_alloc_size: linux,di

[    0.000000@0] DI reserved memory: created CMA memory pool at 0x0000000039d80000, size 30 MiB

[    0.000000@0] Reserved memory: initialized node linux,di, compatible id amlogic, di-mem

[    0.000000@0] __reserved_mem_alloc_size: linux,ion-dev

[    0.000000@0] ppmgr share mem setup

[    0.000000@0] linux,ion-dev add multi user:ffffffc001a6b900

[    0.000000@0] Reserved memory: initialized node linux,ion-dev, compatible id amlogic, idev-mem

[    0.000000@0] __reserved_mem_alloc_size: linux,codec_mm_cma

[    0.000000@0] Reserved memory: created CMA memory pool at 0x0000000027c00000, size 188 MiB

[    0.000000@0] Reserved memory: initialized node linux,codec_mm_cma, compatible id shared-dma-pool

[    0.000000@0] __reserved_mem_alloc_size: linux,picdec

[    0.000000@0] Reserved memory: created CMA memory pool at 0x0000000034c00000, size 48 MiB

[    0.000000@0] Reserved memory: initialized node linux,picdec, compatible id shared-dma-pool

[    0.000000@0] __reserved_mem_alloc_size: linux,codec_mm_reserved

[    0.000000@0] codec_mm:vdec: reserved mem setup

[    0.000000@0] Reserved memory: initialized node linux,codec_mm_reserved, compatible id amlogic, codec-mm-reserved

[    0.000000@0] cma: Reserved 8 MiB at 34400000

[    0.000000@0] On node 0 totalpages: 231552

[    0.000000@0]   Normal zone: 4228 pages used for memmap

[    0.000000@0]   Normal zone: 0 pages reserved

[    0.000000@0]   Normal zone: 231552 pages, LIFO batch:31

[    0.000000@0] psci: probing function IDs from device-tree

[    0.000000@0] PERCPU: Embedded 11 pages/cpu @ffffffc037d2f000 s13952 r8192 d22912 u45056

[    0.000000@0] pcpu-alloc: s13952 r8192 d22912 u45056 alloc=11*4096

[    0.000000@0] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 

[    0.000000@0] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 227324

[    0.000000@0] Kernel command line: rootfstype=ramfs init=/init console=ttyS0,115200 no_console_suspend earlyprintk=aml-uart,0xc81004c0 ramoops.mem_address=0x20000000 ramoops.mem_size=0x100000 ramoops.record_size=0x8000 ramoops.console_size=0x4000 androidboot.selinux=permissive logo=osd1,loaded,0x3f800000,1080p50hz hdmimode=1080p50hz cvbsmode=576cvbs hdmitx= hdmitx_force_rgb=true androidboot.firstboot=0 androidboot.serialno=A01B01C0000550 mac=E8:18:63:50:D1:90 androidboot.mac=E8:18:63:50:D1:90 boot=/dev/mmcblk0p1 disk=/dev/mmcblk0p2 BOOT_IMAGE=kernel.img console=tty0 consoleblank=0 scaling_governor=hotplug scaling_min_freq=96000 scaling_max_freq=2016000 systemd.show_status=auto 

[    0.000000@0] logo: osd1

[    0.000000@0] logo: loaded

[    0.000000@0] logo: 0x3f800000

[    0.000000@0] logo: 1080p50hz

[    0.000000@0] logo: get hdmimode: 1080p50hz

[    0.000000@0] logo: get cvbsmode: 576cvbs

[    0.000000@0] PID hash table entries: 4096 (order: 3, 32768 bytes)

[    0.000000@0] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)

[    0.000000@0] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)

[    0.000000@0] Memory: 507088K/926208K available (6802K kernel code, 514K rwdata, 2348K rodata, 557K init, 2479K bss, 419120K reserved)

[    0.000000@0] Virtual kernel memory layout:

[    0.000000@0]     vmalloc : 0xffffff8000000000 - 0xffffff8040000000   (  1024 MB)

[    0.000000@0]     vmemmap : 0xffffff8040010000 - 0xffffff80410dbc00   (    16 MB)

[    0.000000@0]     modules : 0xffffffbffc000000 - 0xffffffc000000000   (    64 MB)

[    0.000000@0]     memory  : 0xffffffc000000000 - 0xffffffc03bb80000   (   955 MB)

[    0.000000@0]       .init : 0xffffffc001971000 - 0xffffffc0019fc680   (   558 kB)

[    0.000000@0]       .text : 0xffffffc001080000 - 0xffffffc001970ac4   (  9155 kB)

[    0.000000@0]       .data : 0xffffffc0019fd000 - 0xffffffc001a7d840   (   515 kB)

[    0.000000@0] SLUB: HWalign=64, Order=0-1, MinObjects=0, CPUs=4, Nodes=1

[    0.000000@0] Hierarchical RCU implementation.

[    0.000000@0]     RCU debugfs-based tracing is enabled.

[    0.000000@0]     CONFIG_RCU_FANOUT set to non-default value of 32

[    0.000000@0] NR_IRQS:64 nr_irqs:64 0

[    0.000006@0] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483648000ns

[    0.007515@0] mclk->mux_reg =ffffff8000004990,mclk->reg =ffffff8000008994

wrxtasy · (This post was last modified: 2016-07-30, 13:38 by wrxtasy.)

I'm not sure what is going on with your setup...
This is the .tar file that needs to be downloaded and put in the Update folder. Do not use any .img file at all.

LibreELEC-WeTek_Hub.aarch64-7.0.2.Force.RGB.tar

Code:
dmesg | paste

This is my Kernel Log:
http://sprunge.us/AWDM

That shows Forced RGB is clearly working.

lekand · (This post was last modified: 2016-07-30, 15:05 by lekand.)

(2016-07-30, 13:37)wrxtasy Wrote: I'm not sure what is going on with your setup...
This is the .tar file that needs to be downloaded and put in the Update folder. Do not use any .img file at all.

LibreELEC-WeTek_Hub.aarch64-7.0.2.Force.RGB.tar

Code:
dmesg | paste

This is my Kernel Log:
http://sprunge.us/AWDM

That shows Forced RGB is clearly working.

Hey wrxtasy, thanks for the feedback, yes, that's the link I used. Your log is _almost_ identical to mine, but not quite. This is what I get: http://sprunge.us/iEgU

The difference seems to be the "kernel command line":

Mine:

Code:
[    0.000000@0] Kernel command line: rootfstype=ramfs init=/init console=ttyS0,115200 no_console_suspend earlyprintk=aml-uart,0xc81004c0 ramoops.mem_address=0x20000000 ramoops.mem_size=0x100000 ramoops.record_size=0x8000 ramoops.console_size=0x4000 androidboot.selinux=permissive logo=osd1,loaded,0x3f800000,1080p50hz hdmimode=1080p50hz cvbsmode=576cvbs hdmitx= hdmitx_force_rgb=true androidboot.firstboot=0 androidboot.serialno=A01B01C0000550 mac=E8:18:63:50:D1:90 androidboot.mac=E8:18:63:50:D1:90 boot=/dev/mmcblk0p1 disk=/dev/mmcblk0p2 BOOT_IMAGE=kernel.img console=tty0 consoleblank=0 scaling_governor=hotplug scaling_min_freq=96000 scaling_max_freq=2016000 systemd.show_status=auto

Yours:

Code:
[    0.000000@0] Kernel command line: rootfstype=ramfs init=/init console=ttyS0,115200 no_console_suspend earlyprintk=aml-uart,0xc81004c0 ramoops.mem_address=0x20000000 ramoops.mem_size=0x100000 ramoops.record_size=0x8000 ramoops.console_size=0x4000 androidboot.selinux=permissive logo=osd1,loaded,0x3f800000,1080p60hz hdmimode=1080p60hz cvbsmode=576cvbs hdmitx=cec0x2f androidboot.firstboot=1 androidboot.serialno=A01B01C0005093 mac=E8:18:63:50:BB:A1 androidboot.mac=E8:18:63:50:BB:A1 boot=/dev/mmcblk0p1 disk=/dev/mmcblk0p2 BOOT_IMAGE=kernel.img console=tty0 consoleblank=0 scaling_governor=hotplug scaling_min_freq=96000 scaling_max_freq=2016000 systemd.show_status=auto

Funny thing is that I have a launch parameter hdmitx= hdmitx_force_rgb=true that you don't have, but you do get forced RGB.

ChristianTroy · 2016-07-30, 20:03

hdmitx_force_rgb=true

comes from android (I guess you flashed the testing zip)

Code:
__setup("hdmitx=", hdmitx_boot_para_setup);

+static int __init hdmitx_force_rgb_setup(char *str)

+{

+       if (!strcmp(str, "true")) {

+               hdmitx_output_rgb();

+        hdmi_print(IMP, "Forced RGB colorspace output\n");

+    }

+       return 1;

+}

+

+__setup("hdmitx_force_rgb=", hdmitx_force_rgb_setup);

+

#ifdef CONFIG_AM_TV_OUTPUT2

MODULE_PARM_DESC(force_vout_index, "\n force_vout_index\n");

Newbie_from_NJ · (This post was last modified: 2016-07-30, 20:13 by Newbie_from_NJ.)

Quick question guys, any of you having issues streaming links using real-debrid service on the Hub? Movie does not play for me. However If I chose the same movie on my Chromebox, it plays fine. WTH?

Edit: currently experiencing this symptom in LibreELEC.

Sent from my SM-N920P

lekand · (This post was last modified: 2016-07-30, 22:08 by lekand.)

(2016-07-30, 20:03)ChristianTroy Wrote: hdmitx_force_rgb=true

comes from android (I guess you flashed the testing zip)

Code:
__setup("hdmitx=", hdmitx_boot_para_setup); +static int __init hdmitx_force_rgb_setup(char *str) +{ + if (!strcmp(str, "true")) { + hdmitx_output_rgb(); + hdmi_print(IMP, "Forced RGB colorspace output\n"); + } + return 1; +} + +__setup("hdmitx_force_rgb=", hdmitx_force_rgb_setup); + #ifdef CONFIG_AM_TV_OUTPUT2 MODULE_PARM_DESC(force_vout_index, "\n force_vout_index\n");

Mmm, not sure what you mean here. I just updated the LibreELEC version from wrxtasy by copying his RGB patch onto the Update folder... My hub has also the custom Android patch provided by WeTek, do you think that might be interfering somehow? Any advice on how to fix the LE kernel launch command?

ChristianTroy · 2016-07-31, 07:29

I mean the different cmdline, that hdmitx_force_fgb will be present starting with the next OTA (or by flashing the zip you received from the customer care)
Basically hdmitx_force_rgb defaults to false, when set to true it calls that hdmitx_output_rgb() function that in other part of the hdmi kernel driver ignores the color space request by the TV and forces RGB444.
I did not use 1:1 the odroid patch because in this way I find easier to alter the property (just setting it false or true depending on the value you select in android settings), and also would look better if you did not configure cec (that defaults to be empty and the cmdline would look "hdmitx=," as default or when no rgb force is in action and I did not like it cosmetically lol)