Posts by mmpp

AAC audio has to be decoded by the box and sent to the avr as multichannel PCM audio. Same with flac audio.

Sounds like a hardware fault to me. You might try to change the hdmi cable or ask someone to measure the connections of the hdmi socket and re-solder if neccessary.

- Activate SSH server on your box
- Connect using SSH client (user: root, password: libreelec)

Type the following commands:

cd .config
nano autostart.sh

This starts an editor. Insert the following text:

#!/bin/sh


echo 1 > /sys/class/amhdmitx/amhdmitx0/output_rgb

Then save and type

chmod 755 autostart.sh
reboot

Your box will restart, and from now on always use RGB output.

Sorry, I did not see that you installed to internal.

Please try this: Reboot into android, go to settings->display and change resolution to 1920x1080 and disable auto-switching of resolution.

I see the same bug, when 720p is selected in Android.

1. On embedded systems with limited ram, having a 64bit instead of a 32bit userspace usually has very limited benefits.
2. Why not? The 32bit userspace on top of a 64bit amlogic linux kernel is a new feature. Having both versions is useful for testing and debugging and offers those who do not want to switch a clean update path.
3. To my knowledge, 32bit is currently considered as the way to go forward. Check the alpha release threads for the discussion.

Use the 32-bit userspace. Your benefits include

• access to the many addons for the armhf archictecture (same as the raspberry pi), especially widevine content encryption and console emulators
• not having the hard-to-find memory leak, that would make 1G ram boxes unusable after running for a longer time on the 64-bit version
• lower memory footprint of the kodi application and binary addons overall

No, I run it with German language settings.

BT.709 is the regular colorspace. BT.2020 is the extended colorspace.

All HDR formats use BT.2020 (to my knowledge, see also Rec. 2020 - Wikipedia)

-> your working videos are most likely not HDR

Quote from w00x

The Sync function in Playback is enabled. So are the DTS Passthrough and refresh rate change.

"Sync to display" together with "passthrough" do not work well together and result in playback (jerkiness) and a/v sync issues. Please deactivate sync to display and test again.

More information on these settings can be found on the kodi forum. See for example here: "Adjust Display Refresh Rate" vs "Sync Playback to Display"

Hi,

updated and did a few tests: playing files from SMB share will consistently cut a few seconds from the beginning. Same with youtube videos or other streaming media.

From the known issues (1st message in this thread):

Quote

Suspend doesn't work most of the times. Temporary solution: use poweroff.

My wetek hub takes less than 20 seconds after a power on, so I never tried suspend. Does powering on the TX5 with the remote control work after a poweroff from libreelec?

Just to be sure, you do not use "sync to display" together with passthrough, yes?

Sorry, you are right, the hw deinterlace is automatic and cannot be controlled from the gui. I was remembering it wrongly (x64/nvidia offers it). You can still try

echo 1 > /sys/module/di/parameters/bypass_all

from the shell. See [SOLVED]Disable deinterlace - WeTek Community Forum for details.

Hi redger,

you can check the output of

cat /sys/class/amhdmitx/amhdmitx0/disp_cap

to see if your tv set has a 50Hz mode and advertises it on the hdmi connection. Then check the kodi log of a 50Hz playback to see if there is an indication of the change and also try the tv's info to see if 50Hz actually made it to the tv.

Also you can try to disable deinterlace to see if the judder is created by the hw deinterlacer. You can do it in the video options during playback.

Hi,

I have no trouble playing European DVB-S2 signals (720p50/h264, 1080i50/h264, 576i50/mpeg2, 4k/hevc10) with hardware acceleration. Both live TV and recordings work. Backend is tvheadend (cubieboard w/ armbian and tvheadend compiled from git some weeks ago). I use refresh rate switching on start/stop with a 0.1s delay.

Amlogic S905 does not offer USB3 to my knowledge...

If you do not mind the remark: "I believe" belongs to the church. If you want to argue, please give empirical results from repeatable tests.

In my case: if I use remote key "power" on the MXQ using android, the picture will go black. But the android system is still running, as I can still access servers (e.g. ssh or web servers) over the network. If I use "power" again, picture is shown again.

On the other hand, if I force the android system to properly power off (either with console command or by using programs that initiate a shutdown), the box will go into exactly the same state as a poweroff in libreelec: red light, no reaction on any events, can only be switched on by pulling and reinserting the power plug.

And finally: All works as intended with the wetek hub (both libreelec AND android), which is basically the same hardware, but has a proper bootloader by the manufacturer.