Wake on LAN isn't supported on Allwinner boxes, right?
As far as I'm aware, it's not. You can ask smaeul what would be needed to implement it in Crust.
Wake on LAN isn't supported on Allwinner boxes, right?
As far as I'm aware, it's not. You can ask smaeul what would be needed to implement it in Crust.
Still trying to figure out my low library scan issue and saw this is being posted to dmesg every few seconds
There are few ways you can check what is going on. With top try to determine which process takes most CPU time. I guess Kodi, but you never know. Next, you can check perf top, which will tell you which functions currently take most CPU time. This should give good pointer where to look next.
dw_hdmi_cec_hardirq: stat=11 LOW_DRIVE
Is this relevant?
I don't think this should cause any issue. Actually, I'm thinking of removing that message or even whole patch, which introduced it. But yes, it's not ideal to have it. Are you testing this with monitor or TV? If on TV, toggle CEC state in TV settings (on <-> off). Note that TV manufacturers usually use different name for CEC, like simplink, viera link, etc.
Side note: only 4K (4000x2250) movie was to slow. Music was correct but video was slow, hanging and jumping. For me that is no issue, as I don't have a 4K TV anyway.
Ordinary 8-bit 4k should work, but the issue is in buffer/memory management (not enough CMA memory), so it falls back to SW decoding (press "o" during playback and check info). I'm working on IOMMU support, which would solve this issue completely, but it seems IOMMU driver doesn't always work correctly. This will take some time to solve.
offbeat everlanes I just found the issue and potential solution. It seems that width and height need to be multiple of 32 when converting from original NV12 tiled format to standard NV12. Please test following update: http://jernej.libreelec.tv/test/vp9/ If it works, I'll PR fix/workaround.
At least simple OpenGLES things like kmscube seem to render and output at 144FPS just fine, so it's only video plane output that has some glitch.
Correct. I believe the issue is timing - HW scaler for video plane is a bit sensitive when registers are updated and I'm pretty sure we don't write them at optimal moment.
Jernej, I have just tried that but it says it was unable to run one, or two media files and I can find info in log files.
This is not debug log. Not a single line which would say "DEBUG".
It's entirely possible that 144 Hz output needs some things to be done in more precise ways. Sorry, I don't see this being addressed anytime soon.
So its DRM driver, guess it can be reported to mesa bugtracker?
No, display driver (sun4i-drm) has nothing to do with GPU. I'm actually main maintainer for DE3 variant (used by H6). Wait, are you testing this on LE?
Yes, prime decoder=ON + prime render=EGL helps, video is OK.
ok, so issue is either with rendering code in Kodi or with DRM driver. Either way, I can't do anything more without having 144 Hz monitor.
Here is a different issue I mentioned in previous comment, broken hardware decoding outputing to 144Hz, video is plain h264.
That might be DRM rendering issue. Can you try with switching DRMPRIME rendering from "direct to plane" to EGL? If that doesn't help, I don't know... I would need such monitor to test directly.
AV1 software decoding get H6 to its knees, all 4 cores loaded pretty much to 100%.
You expect too much from A53 cores. H6 predates AV1, so no HW decoding support.
This VP9 clip fails to decode correctly
Thanks, I'll look into it. It looks like some size or stride is set incorrectly.
although you need to run under Wayland which doesn't support fun stuff like "adjust-refresh" by design so it's not quite the solution nVidia users need (better than "no support" though)..
I don't think wayland is a requirement for nvdec vaapi wrapper. However, I don't know if Kodi starts in GBM mode with new nvidia drivers.
offbeat In short, I don't think there will ever be one single go-to video decoding API under Linux, mostly becasue supported HW is very diverse. However, I believe it will boil down to few different apis.
MX10 Pro (H6)
not supported, so your issues are not surprising. Note: wifi & bluetooth are often not supported even on officially supported boards due to team policy on out-of-tree drivers.
If there is any way to do that, please explain how and I would try! Never new I am able to open m3u8 channels playlist directly in Kodi without using IPTV addons...
Last time I tried (about year or a bit more ago), it was simple. Search for m3u8 file in video section and open it just like any other video.
Again to note, this box doesn't seem to have any default working IR config (even my MCE RC6 remote doesn't work with it OotB), it'll reboot/restart fine, but doesn't shutdown or start (from IR or WeChip G20 RF dongle), no WiFi either but I understand this.
Of course, you're using image tailored to Tanix TX6, which comes with different remote. You have to build your own image tailored for T95 Mini. Check last 3 commits here how to do that: https://github.com/jernejsk/LibreELEC.tv/commits/tx6-mini Those commits were made for similar test - if different IR settings for otherwise box with similar configuration would work.
Can you try with this image? http://jernej.libreelec.tv/test/tx6-mini/ It's very similar to TX6, it just has different remote key codes programmed in.
I'm a bit rusty regarding inputstream addons, but at least in the past, it was possible to disable those... You can try removing all addons and open your playlist directly in Kodi. Obviously, it will have less functionality but also less possibilities to go wrong.
Wait, this is crashlog, not debug log. It crashes inside inputstream.ffmpegdirect. First, try watching video without this plugin.
Why not share it publicly? More people can see it, more chances to spot anything out of the ordinary.