It's not a Kodi debug log, and there is no attempt to play anything. Fix those details and use "cat /storage/.kodi/temp/kodi.log | paste" and share the URL (less effort than copy/pasting to pastebin).
Posts by chewitt
-
-
RPi4 software is not quite as mature as RPi3, but I've been using one as the family daily driver since before the public launch and I don't see any real-world issues with any media apart from HDR which plays with washed out colours due to the current lack of HDR support (but is otherwise fine).
In the absence of a debug log file which would allow us to spot the config errors and such, we have to guess. I'm guessing you've enabled 4K60 modes and set the GUI to 4K60 (or if not enabled, it's running at 4K30) and you haven't done refresh/resolution whitelisting, so 23.976 media is being forced to run at the desktop resolution (30 or 60 Hz) which requries resampling .. and RPi4 is still a low-power ARM device so that will suck and cause a nice stuttery experience.
Keep the desktop at 1080p60, set "adjust refresh" to start/stop and configure the whitelist for 1080p/4k 23.976/24/50/59.97/60 only, and don't force 4k60 in config.txt unless you actually intend to watch 4k60 media (there is none in use apart from test files).
-
There are lots of shitty Amlogic builds .. but I haven't heard of a "shitty" image before.
-
delete autostart.sh and run the commands from the SSH console
-
-
I'll re-add the GT-King device-tree to my working tree in a couple of days, then it will magically reappear in Oleg's images. I need to do more testing but the general idea is to send it upstream so it's included in Linux 5.7.
-
LE 9.2 does not exist for Amlogic devices. We got fed-up witth working in an awful vendor kernel and changed our focus to development of mainline kernel support. LE10 (Kod 19) is planned to have support for C2 again.
-
-
VFD displays are simple serial devices and you can literally do "echo 'my text' > /dev/serial-device" to write content to the display in some cases. VGA output will need an app that runs under X11 to output to a second display device, which is quite a bit more complicated.
It's not impossible, but I'm not aware of any existing tools/plugins in the LE ecosystem. Our mid-term technical direction will also see us move from X11 to GBM/V4L2 running directly on the framebuffer so even if you get something working under X11 this will have a short shelf-life in LE.
IMHO dual-display would be easiest to achieve under Windows or a desktop distribution, perhaps with a web-based touch GUI.
-
leandrotsampa It looks like you are hacking a vendor-proprietary rendering system into Kodi similar to Amcodec, iMX6, etc. which have now been exorcised from the codebase. If HiSilicon have V4L2 support, this is the technical direction to invest time into, as your current approach will not be accepted upstream.
-
cp /etc/connman/main.conf /storage/.config/connman_main.conf
^ edit to allow the list of "TetheringTechnologies" to include "ethernet,wifi" instead of just wifi.
-
That's up to the Kodi developers. K19 alpha1 release is due soon, allegedly.
-
Yes, more coffee required at that time of the morning
-
Sorry I couldn't edit the extlinux.conf as my system is on eMMC and I do not have a SD card ready, but I will try to get one
mount -o remount,rw /flash
nano /flash/extlinux/extlinux.conf <= make changes
mount -o remount,ro /flash
reboot
^ there's no need to reboot from an SD card to edit extlinux.conf
-
Kodi supports output to a single screen - period. It's possble to mirror content between two connected screens, but that's all, and getting that to work when the two displays are radically different sizes will require crippling the HDMI output to the resolution of the VGA output. Add "using an AMD GPU" into the mix and even getting dual-output might be a challenge.
That's probably not the answer you were looking for .. but that's the answer
-
Yes, the plan is to support SM1 (S905X3) devices in LE10 (K19).
-
The only way to stop that behaviour is modifying packages/mediacenter/kodi/tmpfiles.d/kodi-userdirs.conf in the build-system and then building a custom image with the modification. In our standardd image they will always be recreated on boot (by systemd not samba).
You can probably hack a delete via /storage/.config/autostart.sh but since this runs at the start of userspace boot you'll need to background the task for aa few seconds, e.g.
-
It will depend on how the touchscreen is connected to the motherboard (HDMI, USB, ???) and whether this requires drivers?