Do you mind to explain why ? From my experience ext4 always perform better than NTFS with less CPU overhead. That changed recently ?
EXT2 will be much better as EXT4 has the added overhead of journaling. You could always disable it on EXT4 but for an external drive EXT2 will be more than ok...
The command for forceRGB isCodeecho 1 > /sys/class/amhdmitx/amhdmitx0/output_rgbYou can type it using SSH while your box is on. If the workaround works fine, you can add it to autostart.sh.
On my box with a 10 year old Sharp Aquos TV it seems to do the trick as long as I reset it back to 0, as with 1 I get no output.
To be clear, my TV will flicker randomly by a refresh rate change. Sometimes it does sometimes it doesn't. So by issuing
echo 1 > /sys/class/amhdmitx/amhdmitx0/output_rgbI lose output, so immediately I revert it by
echo 0 > /sys/class/amhdmitx/amhdmitx0/output_rgband then I get a stable screen until a later unlucky refresh rate change. Now I noticed that the flickering might come back if I switch off and on the TV. The longer it stays switched off the more likely is to flicker on the next power up. FYI this issue has cropped up sometime around the early 8.0.1 updates. It practically makes auto refresh rate switching unsuitable for these builds...
Unfortunately I couldn't flash either, tried tar and zip. Looked like it was installing and then nothing. Box now has light and no display, can't recovery using normal mx2 recovery card (created using HDD Raw) so not sure what to try next or how to fix it.
Welcome to the club. I had nemsis on so I installed the zip using the recovery button as you are supposed to do when going to different builds. Everything looked ok while flashing and on reboot, royally bricked. 
Blue light on and no output whatsoever, black screen. Recovery is also borked so I can't do any flashing that way anymore. So now way right now to at least go back to android and start over.
My box is the HD18 2.22 version of the Droid MX. I'm too busy at the moment but in a couple of weeks I will try to see if I can revive it. I think there are ways in worst case scenario to short some pins on the board to force recovery or even scrub the nand to clear any bad memory areas. There are long threads about it on freaktab if you are interested.
It's frustrating when it happens especially when you have a bad feeling about it beforehand...
These are all the partitions on my box (Beelink MiniMX III S905X):
CodeDisplay Moredev: size erasesize name inand01: 400000 80000 "bootloader" inand02: 4000000 80000 "reserved" inand03: 20000000 80000 "cache" inand04: 800000 80000 "env" inand05: 2000000 80000 "logo" inand06: 2000000 80000 "recovery" inand07: 800000 80000 "rsv" inand08: 800000 80000 "tee" inand09: 2000000 80000 "crypt" inand10: 2000000 80000 "misc" inand11: 20000000 80000 "instaboot" inand12: 2000000 80000 "boot" inand13: 40000000 80000 "system" inand14: 305400000 80000 "data""rsv", "crypt", "misc" and "instaboot" are empty. "cache" and "recovery" are only used by android. "boot", "system" and "data" are overwritten on reflash. "env" holds the bootloader variables. "bootloader" and "logo" are self-explanatory. "tee" is mostly empty except for the string lost+found, so is not the culprit. "reserved" contains a lot of ASCII strings referencing kernel terminology and some binary data, but the name suggests that this partition is not essential.
You could try using the Amlogic USB burning tool to completely reinitialize the NAND, but you would need the proper image for this. You could also ask someone with the same box (I have S905X version) to send you a dd dump of the bootloader partition, if you're feeling adventurous. The MAC address is stored as a bootenv variable, so I believe the bootloader partition does not contain unique information, but I'm not completely sure.
Thanks for the info.
Same here with my system being twice as big (80000000) and data shorter accordingly (2c5400000). I don't think the emmc data were compromised because of LE, I've only been running it through the sdcard and never installed to internal. As I can use the disp_cap hack to force the resolutions I'll be ok. Now for the jerking and flashing I'll wait a bit, as it looks software based. I'm reading other posts with people experiencing similar display issues with the last versions, so no need to inflict damage with no reason.
[hr]
I am sure that you are aware, that you should NEVER plug/unplug the HDMI cable while under power.
I know and I mostly follow the rule, but after so many times I wouldn't place my hand on the bible and say I always did... 
These temps are completely normal and should be no problem at all.
Have you tried the "toothpick method"? I don't know exactly what it does, but it should, to some extent, reinitialize the bootloader.
I know the temps look normal and in reality it should handle 20C higher. However, it's not unlikely that the temps reported can be offset by a considerable margin, so I would just take into account the deltas. And the jump in temperature seems to indicate that the box is under greater load somehow. It could be an extra cause for failure. Unlikely, but it can...
Now, prior to reflashing android using the toothpick method, I've tried by clearing the data, cache etc, from recovery, same outcome. I think the bootloader was reinitialized as well, because I needed the toothpick again to boot LE from the sdcard. As far as I'm concerned the box has a probable hardware failure on the EDID stage. What I'm not sure is if flashing with toothpick and sdcard leaves some partitions untouched, which might be corrupted and the cause of the box's behaviour. That's why I wondered if flashing using a PC is better, and can fully restore the unit.
Otherwise, I'm led to believe that I borked the HDMI port somehow by plugging and unplugging too much. On the other hand the port does not look physically abused, so it might be a case of the box being electrically damaged or something along those lines.
Just food for thought... :s
gamicoulas, I have had exactly the same problem as you crop up on one of my test boxes (a Sumvision Cyclone 4+). Suddenly, the only resolutions available are 1080p60 and 720p60, both in Libreelec and Android. Reflashing the Android firmware has made no difference, but like you, using the disp_cap hack and all works ok in Libreelec (but I'm not seeing any flickering).
Interestingly, in the output for DMESG, I see this:
Code[ 2.000691@0] hdmitx: system: [edid_rx_data] err = -6 [ 2.000718@0] hdmitx: edid: 80 errors between two reading [ 2.005444@0] hdmitx: edid: check sum invalid [ 2.009757@0] hdmitx: edid: blk0 raw data [ 2.013756@0] a0fc7e27c0ffffffd0635501c0ffffff08000010000000009088c301c0ffffff [ 2.013756@0] 00fd7e27c0ffffff58137b01c0ffffffd00fcc01c0ffffff0080bd01c0ffffff [ 2.013756@0] 0020b701c0ffffffd412cc01c0ffffff8083fa35c0ffffff2000000000000000 [ 2.013756@0] 000000000000000000c07e27c0ffffff8083fa35c0ffffff0000000000000000"check sum invalid" means the data coming in over HDMI is somehow corrupt but I have tried different cables and connect to different TVs but get the same thing. I do use this as a test box and it gets plugged in/unplugged more often than normal, but this is an odd fault if it is a physical thing, as all other aspects of the hdmi connection are fine.
I was going to put it down to a hardware problem but now that you have reported it, I'm not so sure. I have had a quick look at the uboot variables with fw_printenv and compared them to another S905 box I have, but there are a lot of them and nothing obvious jumps out. I don't want to start changing any in case I brick it. Does anyone know a way of completely resetting the variables back to factory defaults? Does flashing android firmware do that?
Mine gives zeros for edid
[ 1.739550@0] hdmitx: edid: raw data are all zeroes
[ 1.739553@0] EDID Parser:
[ 1.751161@1] secmon: probe done
[ 1.752522@0] EDID BlockCount=0
[ 1.752523@0] hdmitx: edid: HDMI: set default vic
[ 1.752525@0] hdmitx: edid: edid blk0 checksum:0 ext_flag:0
[ 1.752548@0] [RX]-receive ksv list len:1,depth:1,cas:0,dev:0
[ 1.752555@0] hdmitx: video: get current mode: 1080p60hz
[ 1.752557@0] hdmitx: update rx hdr info 0
[ 1.752575@0] hdmitx: system: [set_disp_mode_auto] ALREADY init VIC = 16I can't say what's happening for sure, but the fact that the flickering only happens on the latest versions and not on the 7.0.3 ones, can point to some software issue that's affecting our hardware more than others. Also, during my fiddling this morning I noticed that when synced at 24hz flickering does not occur. At 50 is more likely than 60, and sometimes it can go away. This happens randomly if you had a lucky switch on the refresh rate and it keeps it nicely until a later refresh change where you risk losing it again. That makes the auto adjustment setting a trigger for good or worse. Could it be that I'm using a delay for the refresh change? :s
However, for the missing refresh rates problem I'm at loss cause I've reflashed android to no avail and anyway I was under the impression that booting LE from the SD card shouldn't affect what happens with android on nand. Is there a more complete flashing procedure if we use a PC instead of the recovery hole and an sdcard?
Now I've seen other people saying about heat issues and it's true that with the latest builds my box from hardly hitting 43C has reached 49C just after playing around with the settings lately. Another point that might have stressed components to failure... 
This really sounds like a hardware defect, especially since you tried all of the above. You could try looking into u-boot variables with "fw_printenv" to see if there's something sketchy.
Also try grepping the kernel log for edid related errors.
Looks like it. Using the disp_cap hack I can make those resolutions available and everything works fine except for the flickering which is happening on the 8.0.1 releases. 
But without it the box reports that only 60hz is available even on android from nand. I've been moving that box between houses every week, so I guess all that plugging and unplugging on the HDMI port has probably caused some sort of a failure... 
Could you please post the output of these commands (use pastebin or similar):
Codecat /sys/class/amhdmitx/amhdmitx0/disp_cap cat /sys/class/amhdmitx/amhdmitx0/edid
I think kubrickdave is on something here. You have to at least try to set the Kodi UI at 24hz to see if you can sync on that refresh rate. I get the feeling that you suffer from the same thing that happened to me on my MiniMXIII (S905) a couple of days ago, where the only resolutions available are 1080p60hz and 720p60hz. It was working fine in the past but since 8.0.1e update I lost syncing at 50hz and 24hz on my tv. My display also developed a strange flickering even on the UI (Confluence). I even downgraded down to LE 7.0.3.12j and the only thing fixed was the flickering. The strange thing is that booting to Android from nand, I get the same behaviour just two resolutions at 60hz available. I haven't used android for some months now, but I remember I had more resolutions available.
Tried everything, different cables, TVs, erase data on android, still the same. So something fishy happened on my box on one of the 8.0.1 updates, might even be a hardware failure with my HDMI port that messes the EDID info. Tomorrow I will reflash android and see if anything changes.
PS: I use the disp_cap for the time being to get the missing resolutions, but ultimately would like to know what went wrong...
This is not true. All .009 and .010 device trees are the same.
Out of curiosity, looking at the lists of dtb files of these two versions, the sizes don't match! How come the device trees are the same?
I ask because I too have booting problems (stuck at Beelink logo) with the .010 version...
