If the fonts are rendered as a "square" glyph you need to add /storage/.kodi/userdata/Fonts/Arial.ttf using an 'Arial' font that includes Asian character support.
Posts by chewitt
-
-
I think the dream setup is to use Kodi and just have DSD work. LE kernels support the higher bitrates needed (hence MPD can be a solution for some) but Kodi has no handling for media above 192k that I can see (perhaps that's where HDMI maxes out?) so the ALSA audio sink code probably needs to evolve a little. And since Kodi is ultimately a big fancy wrapper around ffmpeg some work will be needed there too - and ffmpeg being the fun place to submit patches, that might take a while. As always in the Kodi world, it requires someone with the tryptych of patience, coding skills, and the initiative to do the work.
-
The original post was approved withing a few hours of you posting. Nothing is stuck or needs approving. Just nobody cared to reply to your post. I'd guess because nobody can replicate the claimed problem. For example: I'm running LE13 nightlies on an RPi5 and the InfoWall view is available everywhere for me. Right now LE13 is still using the same Kodi Omega version as LE12 as we didn't bump up to Kodi 'P' just yet.
I would stop and rename the /storage/.kodi folder to /storage/.kodi-old and restart. If the (now empty, all new) Kodi library DB has Infowall back, something is messed up or corrupt in the kodi-old settings or DB files and you can now stop, move files, restart Kodi to move old config and bits to the 'new' Kodi folder until you find out what caused the issue.
You can also share a debug log, but I rather doubt the issue will be visible that way.
-
The content of /storage/.kodi is what you want to rsync. In reality it's the userdata folders, but you might as well sync add-ons and such too assuming it's the same hardware in both places.
-
Do you think it will be compatible with LibreELEC and Tvheadend ?
It's never guaranteed but I think it should be. Hauppauge are one of the few DVB device vendors who actively maintain their drivers in the upstream kernel and most mentions of that device I see (including on the Hauppauge website) are referencing support in old kernels (meaning support has been around for a long time).
-
It looks like two issues:
a) Some builds are taking so long they reach a timeout value and are killed.
b) Because they took so long the next build is trying to schedule itself and can't find a free worker, so fails
Some DevOps'ing needed I suspect. Not sure why things are running slow.
-
The same fix is in the same kernel used in both LE12 and LE13 nightlies. No need to use my images. NB: The 16K page fix has nothing to do with the normal run-of-the-mill stupdity with NTFS filesystems being marked dirty and failing to mount. That still requires you to go fix the drive on Windows before reconnecting to Linux.
-
/etc/fstab exists solely to stop some error messages from being shown. It's not actually used so you will never see content about drive mounts there. And I'm guessing the command sequence based on the "emmctool" script that's embedded in the Amlogic image. The general principle is that you shouldn't peform change operations on mounted partitions and filesystems and some commands result in auto-remount being triggered so you need to unmount things again before you run the next command. So unmount, grow the parition to 100%, then resize the filesystem to 100%. There's no need for crash helmets as the worst that happens is you mess up something that isn't being used and doesn't already work. You can always start over and have another go.
NB: I'm wondering if an "nvmetool" script might be useful for RPi5 boards.
-
It might need an eeprom and USB firmware update at some point, but there should be no reason why it cannot run LE12.
-
Is there anyway to edit a conf to disable the SSL requirement in the interim?
No, it needs to be compiled with the right options. The fix is in LE12/13 nightlies for a while so just update to the current one?
-
You probably found 3 add-ons, which are still using Python 2.
Probably not if the addon was working under LE11 as per post #1.
Seeing a full debug log would be useful.
-
Attention from Intel devs is never guaranteed, but if you never open it, you can guarantee it never receives attention. TL/DR; open the ticket, there is nothing to lose.
NB: Assume that Intel devs have little clue what LibreELEC is (let alone our release numbers) so focus on talking about kernel details that they do understand.
-
Thanks for confirming. I'll push some changes out.
EDIT, fix merged to master now. Separate fix will go to LE12 in a couple of days I'd guess.
-
The log doesn't show anything.
-
The normal approach is to designate one of the HTPC devices (or a NAS box) as the 'server' and use a common MariaDB instance to host the Kodi database along with the content being played. That's going to need a reasonable network though: Ethernet is always advised as the amazing WiFi speeds acheived in some test lab for marketing purposes are never the same as your home in real life.
I've also seen people use rsync to literally sync local database files and thumbs between different LE devices, but that relies upon you only ever using one device at a time and performing a sync before you switch devices; else things are quickly out of sync. The rsync binary is in the network-tools add-on IIRC.
-
What happens if you first install using the LE10 image and then manually update to LE12?
-
-
so I don't think it's a cable issue.
Well, it reads exactly like a cable issue. Also make sure you have the latest BIOS and graphics firmware that might be available. Intel have a long history of buggy firmware.
