LE 9.2.8 image for WP1:
Amlogic Meson6 (AML8726-MX) SoC on Linux kernel v3.10.108 (LTS):
- WeTek Play (1G/4G) a.k.a. WP1:
The device image is based on the officially supported version 9.0.2.WP1 image: Index of /WeTek_Play/
Posts by dtech
-
-
As for the bridging with another router in order to provide wired connection to it.
Does this mean connecting them via ethernet? I know how it is done.
What I suggested is an AP-bridge solution, not a client bridge, so the routers need to be connected to each other via Ethernet, not the box.
The point is that the box is connected to a separate wireless network, not to the main router's wlan.
You only need max. 1 meter of cable between the routers, so I think it will fit.
People do not want wires running around their homes.
It's easier to have the cables in the wall in advance, where you need it. But for that, I had to be put some PVC-pipes into the wall, even before painting.
-
Imagine 3 excited kids (plus their friends) running around a room and something protuding out of the tvbox. I give it 1 month before they break the adapter and the usb that is plugged in
Rather, I would be more afraid the TV will be damaged, because that is a little more expensive than a TV box or wifi adapter.
It seems a bit of an excuse...
I have a suggestion to reverse the situation: put in an older router (e.g. 802.11g) in bridge mode that communicates well with the box.
Forget the WAN side, connect the network cable to one of the ports on the LAN. Turn off the DHCP server and set up the wlan interface.
Finally, connect the box to this router via WiFi. At the moment, I can't suggest a better and simpler than this solution.
I'm sure if you have a lot of USB wifi adapters, you also have a couple of old routers.
-
Hi jim_p !
chewitt is right, the wired connection is always better.
For live streams (e.g. IPTV), even a well-functioning wireless connection can sometimes cause random delays because multiple devices are connected to it at the same time, and this sometimes puts jitter into the signal. This will make the broadcast completely unenjoyable.
(For this, it is enough to have a smartphone connected to the same wireless network at the same time as the box. Not recommended.)
What Da Flex suggested is actually a client bridge, which is an adapter between the WiFi and the wired connection.
(This can still cause jitter problems with live streams because it's really just a media converter, from wireless 802.11* to wired 802.3*.)
But for offline media (e.g. play a movie from NAS) a wireless connection may be sufficient because that can be pre-buffered.
However, the integrated Realtek wireless driver are a really old piece (just like the kernel), and I don’t have a good experience with it either.
But, if you have an USB WiFi adapter, try it with your box first. Like this...
For me, this Atheros-based adapter (TP-Link WN722N) works better than the integrated Realtek.
It’s not a piece of today either, but at least it’s stable.
Regardless, I prefer a wired connection much more than any wireless solution.
-
LibreELEC v9.2.8.1 (4K-bugfix) has been released for S8X2 devices only.
Changes:- 4k-bugfix: fix 2160p resolutions support in amlogic-3.10 kernel,
- 3rdParty images: separate Minix (datrh-based) and MXIII (Demetris-based) S8X2 builds,
- 3rdParty images: fix X8-H Plus wifi issues and add support for X8 / X8-H devices.
Thanks to oceanzhang for his help in debugging and testing.
Affected devices: OTT M8S+, X8-H Plus, MXIII, MXIII-Plus/-G, Universal n200 devices and WeTek Core.
For more information and for download links, please check the first post in this topic: #1
Important notice for WeTek Core users:If anyone has tested the image for the WeTek Core, please comment because I have not received any feedback on it so far.If I do not receive any feedback, I will discontinue the support due to lack of interest. -
I ask because I have k1 plus, I don't know what to do next. I uploaded the u-boot.bin.sd.bin file from your post to the mSD card.
I don't think this uboot image for KII Pro would work on your device because KI Plus only has 1GB of RAM.
-
3840x2160p isn't listed all the time. Connect box with my TV (samsung) , I can switch to 2160@24p.
But when connect to a monitor (lg 4k), I just got 1080@60p.
Maybe Samsung reports 4k2k24hz, but LG reports same resolution as 2160p24hz.
These two are the same, but 2160p24hz is the name in the HDMI 2.0 standard and 4k2k24hz is the name defined in HDMI 1.4.
My TV is LG and it also only sends out 2160p*, there is no 4k2k* at all. That's why it didn't appear on the list for me either.
Names defined in HDMI 1.4:
- 3840x2160 (16:9): 4k2k24hz, 4k2k25hz, 4k2k30hz;
- 4096x2160 (256:135): 4k2ksmpte.
The names of the same resolutions in HDMI 2.0:
- 3840x2160 (16:9): 2160p24hz, 2160p25hz, 2160p30hz;
- 4096x2160 (256:135): smpte24hz.
The secret is not hidden in this file (hdmi_tx_hw.c), but I am already working on it.
Detection is already working for me, but switching the resolution is not yet.
I've already done the patch for the kernel, now Kodi is coming. When I'm done, all HDMI 1.4 resolutions will work on Meson8/8m2.
At least I hope so...
-
As we all know, s812 can play no more than H265 4k@24p.
In my case, I can play H265 4k@50p, but hdmi maximum resloution is 4k@24p.
The limiting factor is mainly the HDMI 1.4. So if a higher frequency came out of it, it might not be stable.
So far, I haven’t been able to figure out how to add custom resolutions because 3840x2160p isn't listed either.
-
I'm glad the m201d image worked.
Unfortunately, many manufacturers have "lied" to the 1GB so that the Android code has also been modified to show a false value.
Just so I understand correctly, you're saying that swapping the dtb around doesn't work because the unit only checks the device tree that is baked into the kernel? If I have that right, I wish I had known that about three days ago. LOL. Oh well, live and learn.
I learned from the case, so I rewrote it in the lead post.
IMPORTANT NOTES - Please read them carefully before asking:
Unfortunately, there are plenty of clones from M8S. If the M8S+ image doesn't work on your M8S, try this one, if it's a 2G/8G model:
Index of /3rdParty/S8X2/Universal-n200-S812_2G-AP6330/
... or MXIII image, if it's a 1G/8G:
Index of /3rdParty/S8X2/MXIII-S802_1G-AP6330/
(Whether S802 or S812 SoC is included does not matter at this point.)
-
1. What program do you use to write the "img.gz" file to the SD card?
2. Have you also tried the m201d image?
Because I have read in several forums that the V3_1 board is also suspicious that it’s only equipped with 512MB of RAM.
3. Replacing the dtb with the meson8 kernel is not a solution because it can only read the dtb integrated into the kernel.
Quote from the notes section of the first post on this topic:
External DTB cannot be used with Meson8* (S802/S805/S812), because there it only takes into consideration those that are integrated into the kernel!
Try the m201d image with the toothpick method first. If that doesn't work, try getting a smaller SDHC card.
-
What does survive reboot is: during a playing video -> Setup -> Video settings -> stretch to 16:9
Then the video looks good, but gui is still on 4:3 mode (ugly stretched).
If this option is set to a value other than normal, it will also affect the calibration and will be completely bad.
So, please do not use manual aspect ratio override, because calibration alone will solve this. Calibration will set the video and GUI in sync.
For us, that’s the point now, because that’s how it can’t happen that the video is good and the GUI is bad. Either both are good or not.
Anyway, I managed to find a solution to the problem, though not the way I thought.
The disp_cap file needs to be edited. Inexplicably, the resolution is not recognized if it only includes 576cvbs:
But, if disp_cap has been edited, it will already appear:
(My display is already pre-calibrated, of course it won't look like this on your side in the first round, the edge of the image will hang over everywhere.)
If you see the resolution here, the calibration data will also be saved and will not be lost after a reboot.
Contents of the new disp_cap file:
Code: /storage/.kodi/userdata/disp_cap480cvbs 576cvbsAnd that's all.
If you have edited the file, you will need to restart the device and then you can start the calibration, which will not be lost now.
Be careful not to accidentally switch to 720x480i60hz if possible, because I don't think European CRT TV with 60Hz will be able to do anything.
-
Sorry, you are right, I really messed up the beginning of the description because it's the same as yours.
1. TV settings standard 4;3 -> the gui itself shows itself to be 4:3 which is perfecty fine, but not widescreen (black bars left / right)
2. TV set to 16:9. The gui ratio now looks bad, with everything horizontally stretched. (but no black bars)
So far, everything is the same as what you described...
Did you give up at this point? Just because the setting starts from this point.
You will then need to start a 16:9 aspect ratio TV stream and begin calibration during the video:
Setup -> Video settings -> Video calibration
The setup menu is half hidden in the lower right corner (gear icon).
The only problem is that the 576cvbs mode is not recognized by Kodi properly and thus does not save the calibration into guisettings.xml.
So after a reboot, the calibration will be lost for now. But I’m already on it to fix this bug.
A temporary solution is to manually add calibration data:
Code: guisettings.xml
Display More... <resolution> <description>720x576 @ 50.00i - Full Screen</description> <subtitles>519</subtitles> <pixelratio>1.442886</pixelratio> <overscan> <left>30</left> <top>21</top> <right>688</right> <bottom>555</bottom> </overscan> </resolution> ... -
Do you have any idea what could be the problem?
-
Did you stretch it from 4:3 to 16:9 with the video calibration? It shows an adjustment of 1,4.
Without video cal, did you not have 4:3?
Fixing 4:3 to 16:9 with video calibration,isn't that "wrong way" to do that?
Okay, I'm trying to say in order...
The "disp_cap" contains 576cvbs only!
- TV settings standard (4:3) -> The GUI shows itself to be 16:9, which looks like what has been compressed horizontally.
- TV set to 16:9, the GUI ratio now looks good, only the edges hanging over in all directions (overscan).
- I started a TV show that now under 16:9 looked like it was compressed vertically.
- I started the video calibration from the PVR menu and adjusted the corners, which eliminated the wrong overscan.
I also set the right aspect ratio for the correct display, the rectangle actually became square.
I don't know if this is a good solution, but it would be right for me.
Gui settings aspect ratio still mangled at wrong res.
After the last step of the calibration (pixel ratio adjustment), the GUI will also be displayed in the right aspect ratio:
The content cannot be displayed because it is no longer available. How can I put in a custom resolution in Libreelec?
The problem is not the custom resolution, but the fact is that there are no signal via composite output if the resolution set other than 480* or 576*. At least that is what I have experienced.
-
Well, I tried CVBS and I have nothing wrong with it, I just went through the calibration operation.
Video calibration -> It will fix overscan and pixel aspect ratio:
Video settings -> I didn't have to change anything:
TV aspect ratio (Standard -> 16:9):
-
Has bumerc sent you a firmware link yet?
-
Stupid question, but I have to ask:
After you have connected the device to USB and it is detected by the Buring Tool, do you then plug in the 12V power jack to the device or not?
Because if you don't, that will be the problem. Maybe your DIY USB cable does not provide enough power to the device for the flash operation.
However, if you plug in the jack and the error still persists, the quality of the contacts will cause this problem and a new USB A-A cable will be needed.
-
Okay, now I see that this bootloader isn't good, because it's made for a 2x1GB memory layout version and your version is 1x2GB.
Only LPDDR and its clock are correct, but the allocation is not.
Which firmware was last tried?
Is this status based on what I sent earlier (#2), or did it happen after the image sent by bumerc?
