ElwoodSC If I understand correctly, clock difference is the same as the amount of time spent in suspend state? If that's true, then RTC is accidentally stopped when transitioning to suspend state.
Note that Tanix TX6 doesn't have dedicated RTC oscillator on board. It uses internal RC oscillator, which has terrible precision. Drift can be 0.5 second or more per minute.
Wait on network is used only at boot if I'm not mistaken. It's meant to wait on network to become available, so all addons, which depend on network availability, can work. If anything, you can try with longer delay, I wouldn't disable it in your case, since you're using PVR backends and SMB.
Anyway, please try test image anyway. If nothing else, it should lower power consumption, since it disables Ethernet PHY in suspend.
As heitbaum said, H616 is work in progress. In fact, out of tree patches exist for almost everything, except audio, which is main showstopper.
ElwoodSC I prepared better test update, just follow links in previous post to test it.
Am I the only one having network problem with my Tanix H6 when returning from standby?
I never observed any issue with ethernet after resume, but I'm not sure if I ever tested network access after being in suspend that long.
Anyway, I added some code which completely turns off Ethernet PHY at suspend and completely re-init it at resume. Please test this update:
source: GitHub - jernejsk/LibreELEC.tv at ac200-suspend
EDIT: scratch that, I found some issues...
BTW, which wifi chip is on your board? There are many variants of this board and 3 different wifi chips are known. I'm working on mainline driver support for all 3, so I would like to find people with all variants for testing.
Allwinner H6 has crazy stuttering in default.
I can't really agree with that. There might be stuttering with *some* videos, but not all. At least if they are HW decoded. Tweaking GPU settings sound like your video is SW decoded. Can you tell more about videos you watch? Like which codec, framerate, etc. Enabling debug log, watching some video and then posting log here (preferably via pastebin or similar service) will clear some questions I have.
32-bit AW SoCs should be good: LibreELEC.tv/linux.arm.conf at master · LibreELEC/LibreELEC.tv · GitHub
64-bit AW SoCs miss one option: LibreELEC.tv/linux.aarch64.conf at master · LibreELEC/LibreELEC.tv · GitHub
Which board do you have?
Is there a chance for official NanoPi K1 Plus support?
Only boards which are or will be officially supported by Linux kernel can be supported. Somebody must submit DT upstream and once it's confirmed, we can talk again.
Note: We don't accept additional out-of-tree wifi drivers anymore. It's also stated in first post of this topic. In short, unless someone manages to include rtl8189ES driver in Linux, it won't be supported.
Or has handling of interlaced content been somewhat abandoned with the new framework (I hope not - it's still used for a large chunk of ATSC and DVB TV, plus DVD and Blu-ray)
No, Allwinner and Rockchip implements it. Main requirement is v4l2 deinterlacing driver. LE uses out-of-tree ffmpeg v4l2 deinterlace filter implementation, written mostly by me. Kodi then uses standard ffmpeg infrastructure - first it decodes frame in DRMPRIME format and if content needs deinterlacing, it pushes frame through deinterlace filter. If not, it's displayed directly. It's still considered tech demo, since there are known corner cases, which don't work (mostly frame dropping).
None. H313 and H616 (basically same thing) are not supported (yet).
Note, we don't add new wifi drivers if they are not in kernel. So while you can make your own image with added driver, driver itself won't be accepted in official LE.
I guess driver for wifi+bt module is this one: GitHub - paolosabatino/ssv6x5x: ssv6x5x driver adapted to for rockchip rk322x Since no mainline driver -> no support in LE.
I don't know about keymap from the top of my head, but you can surely find some guide on net.
What kind of Wifi+BT chip does it have? Can you check chip markings or alternatively provide dmesg output from Android?
Regarding IR - I find it hard to believe that IR wouldn't work. Most probably it just uses remote with different keymap. You can run ir-keytable -t -p NEC,RC6 and press few keys on your remote. If key presses are decoded, you just need to change keymap.
I updated updates to 10 beta4 and added A64. No testing was performed but it should work as well as previous updates.
There is no beta 3 with passthrough support. Either you used beta 3 and somehow enabled passthrough, which is not supported or you used passtrough test image (beta 2).
Build server is temperamental at times, so just check again after a few days.
Oh seems with the last patches (maybe Rockchip: linux: add patch to fix RGB to YUV422 conversion in dw-hdmi · LibreELEC/LibreELEC.tv@8cce2e2 · GitHub) fixes the black screen on some emulators (especially Stella2014).
That patch is specific to RK, so it must be something else.
Why is it beta? Nightly builds for H3 seems VERY stable. I have Pi0, Pi3 and i can compare.
Because status is determined for all platforms together. Believe me, there are bugs even on H3, just not screaming ones.
I have the same issue with a Samsung TV, but this only started somewhere between version 8 & 9 of Kodi. There has also been a major libcec update in that timeframe. Some bisecting to find the cause might be possible. Do you have any idea what would be the most probably cause for the regression, Kodi or libcec (or something else)?
There is no LE8 for Allwinner, at least not from official git tree. Depends on which SoC you're talking. If it is A64 then regression most probably comes after switching to HW CEC driver. I don't have a clue for others.
