Posts by oksmb

Quote from Pelican

I'm happy with my MINI MX-G but I have to use two LE version on two SD card (one for view pictures and one for watch movies) because the S905 has not enough power to render 4k GUI.
I hoped the S912 will solve this problem but without you and your LE version the S912 is just another cheap chinese junk.

The S912 is basically a rip off in my mind. The only reason box makers are putting it in their boxes is to make a buck off people who don't read the specs. There is no real advantage over the S905X for watching videos or viewing pictures, yet it costs much more because of the increased core count and "gaming" GPU.. Bottom line is if you want a premium TV box you are better off spending your money on a well-supported S905 box like the Wetek Hub rather than a generic S912 box. The problem you are facing is more likely related to software limitation/bugs than hardware. The hardware of the S905 is capable of 4k.

Another factor is that all of this development is tied to what is going on with the Wetek boxes and the Odroid. Neither of those players are jumping at the S912 (because it is a stupid chip to put in a TV box) so there is no development happening whatsoever for that chip and I wouldn't expect any in the future. If Odroid or Wetek build anything with the S912 I will be very surprised.

IMO the S905x will replace the S905 going forward, since it costs virtually the same and has better codec support. I don't see the S912 becoming popular because it costs significantly more than the S905/S905x but doesn't add very many features for video playback. The only one really is 1080p-60Hz-H265. Which is not something many people probably care about anyway. The S912 seems like it is more targeted towards gaming than video playback so you pay extra for processing power you probably wont use unless you plan on gaming. And IIRC the S912 is a big.little CPU which means the gain over the S905/S905x isn't as great as you might expect for having twice the cores.

RAM: 1GB should be adequate, but getting 2GB is cheap insurance against memory problems these boxes are prone to.

Storage: Kinda the same story, 8GB is fine but going up to 16GB doesn't cost much and provides good future proofing.

So I'm gonna say the winning combo is S905X / 2GB / 16GB with Gb LAN and Bluetooth. And I will be looking for one with >2 USB ports.

Quote from ozarks

Having obtained an image for my TX5 pro though, it is just a single .img file that is used to flash the device, so can't quite understand how this can be extracted in such a manner that the 2 files can be taken from it.

You need to download the firmware .zip file (sometimes called the OTA update file), not the firmware .img file (sometimes called the USB burning tool image). Maybe try this link:

MEGA
[hr]

Quote from darren1963

Just as an update, I have had a mare. I have spent about 4 hours trying to load LE both via SD and also onto nand on my new Beelink Mini MXiii and it looks as though this is the second box I have bricked. It would not load at all on SD attempts despite several goes at it and then when i tried to flash the latest LE vesrion on the Nand it tells you it has been successful but then just sticks on beelink splash screen. I then tried to go back and flash version 006 and again it says it was a successful install but when the writing comes down the screen as if it is performing the boot up it stopped and crashed and said'bad errors in section 2,3,4'. Tried to reinstall the original firmware via toothpick/recovery but then it would begin the process but just stop half way through saying installation aborted.

I doubt the box is actually bricked for good. You need to burn the box back to stock Android using a USB A - USB A cable and the Amlogic Burning Tool. See this:
How to use the Amlogic USB Burning Tool - EntertainmentBox

Then try install again using the new dtb provided by kszaq.

Quote from kszaq

@all I updated device trees directory, the only additional/changed device trees are for MiniMXIII (1st rev) and "MXQ Pro 4K". They both have a corrected system partition size to hopefully prevent filesystem errors when installed to NAND.

I tested the new gxbb_p200_2G_beelink_minimxIII.dtb on my Mini MXIII that was previously getting the corrupt filesystem error on NAND install. It is working now with the new dtb. Thanks kszaq!

Only thing I notice is that I am seeing this message every few seconds in dmesg:
RTL871X: IsBtDisabled=0, IsBtControlLps=0

Not sure what it means. Bluetooth seems to be working.

Started with Beelink Mini MX III running stock android. Booted SD card okay. Tried the new install script and it completed, but I got a "corrupt filesystem" error on boot. Burned the box back to stock android using the USB burn tool. Tried the alternate toothpick method for installing to NAND. Same "corrupt filesystem" error.

I will try installing 006 and then upgrading since that seems to be working for other owners of this box.

SSH into your box, run "dmesg -c" to clear the log. Press a few buttons on the remote and then run "dmesg -c" again. What does it say?

I noticed on the 7.90 download page it says "we still have a major Amlogic kernel change and support for the WeTek Hub and other Generic S905 devices to pull in". This makes it sound like there are plans to officially support generic S905 devices in LE 8. Am I reading this right?

Quote from kszaq

This would have to be implemented in Kodi for Amlogic hardware decoder. I am not a Kodi dev, don't ask me.

You can adjust the overscan by bringing up the OSD when a video is playing. Then go to the movie reel icon, click on "Video Calibration". It will take you through a series of adjustments to match the video to your display. Hope this helps

Quote from Hans Gruber

Yeah I have the same file structure as above on my Beelink Mini MX III and I can't get it to install to NAND either. SD and USB work fine but when trying to install to NAND I just get a bootloop on the Beelink bootlogo

I also got a bootloop on the Beelink logo when trying to install to NAND on Beelink MiniMXIII using the toothpick method. Tried both with and without recovery.img and dtb.img on the card. I pulled the SD card and used the toothpick to boot into recovery, then reinserted the SD card and installed the zip from within recovery. It is working now.

As far as I can tell, these are all parameters that should control how button hold-down works. When you hold down a button on the remote, dmesg looks like:

[  235.317924@0] remote: press ircode = 0x1a,
[  235.317965@0] remote: scancode = 0x0069,maptable = 0,code:0xe51aff00
[  235.545763@0] remote: repeat ircode = 0x1a,
[  235.545787@0] remote: scancode = 0x0069, maptable = 0,code:0x00000000
[  235.653543@0] remote: repeat ircode = 0x1a,
[  235.653546@0] remote: scancode = 0x0069, maptable = 0,code:0x00000000
[  235.761321@0] remote: repeat ircode = 0x1a,
[  235.761342@0] remote: scancode = 0x0069, maptable = 0,code:0x00000000
[  235.869118@0] remote: repeat ircode = 0x1a,
[  235.869122@0] remote: scancode = 0x0069, maptable = 0,code:0x00000000
[  235.976899@0] remote: repeat ircode = 0x1a,
[  235.976911@0] remote: scancode = 0x0069, maptable = 0,code:0x00000000
[  236.105223@0] remote: release ircode = 0x1a,
[  236.105226@0] remote: scancode = 0x0069, maptable = 0,code:0x00000000

There seem to be a couple timers at work here. When the remote driver detects a button being held down, it waits 228 msec before beginning to repeat the scancode. Then it repeats the code every 108 msec. Finally when the button is released it waits for 128 msec before sending the last scancode.

After playing with the values though I am still not sure exactly how everything translates. The only one that seems to have an effect is release_delay. The time between the final repeat scancode and the release scancode is always = 100 msec + value of release_delay. It is interesting that this is the only value that seems to have an effect as some of the "stock" remote.conf files only include this value and do not include repeat_delay or repeat_peroid.

The only thing I can manage to accomplish by tweaking repeat_delay and repeat_period is to break repeat completely. When these values get too small, holding down a button does not repeat the button (same as if repeat_enable=0). So obviously these values are being read but I don't understand what the driver does with them.

A comment in the source code states that repeat_delay is "time interval from the first frame end to first repeat end". To me this sounds like it should control the 228 msec timer. But it doesn't.