You can start with a Kodi debug log, but I suspect that's not going to be enlightening. If you're able to test and replicate the issue with Kodi running on a general purpose Linux OS like Ubuntu that would be helpful to eliminate LE itself from suspicion and allow you to concentrate on the add-on; which will have a support thread in the Kodi forum where the add-on authors hang out.
Posts by chewitt
-
-
-
From the device-tree name, it's probably the one I created some time ago (used uncredited, as is normal for ophub). See comments in the other thread you created.
-
MatteN is probably on the right track with his answer. Remove EDID captures and connect the RPi4 board directly to the TV until you get things working. You probably need to experiment with different TV ports and/or port settings to ensure it can accept 12-bit 4:2:2 input, which is what the RPi board uses when 10-bit YUV 4:2:0 (which it cannot output) is needed by media.
See https://wiki.libreelec.tv/configuration/4k-hdr#id-4k-60hz
Note that RPi4 (not RPi5) also requires 4K modes to be enabled in config.txt. You do not want to force the Kodi desktop to 4K60 unless you want the UI to be slow and annoying. Mode switching for playback is fine, but the UI is best in 1080p.
-
I'd guess that "no signal" refers to the HDMI input signal and when the LE device is powered on the HDMI input is being switched, but the TV fails to lock on the resolution and you see an appropriate message. Killing the antenna signal sounds really weird and I heard nothing like that before.
-
No idea what the issue is (although Synology and SMB are 100% nothing to do with it) but, a) the better place to ask the question is the Kodi forum where the developers who maintain the Music side of Kodi and the scrapers hang-out, and b) for any commercial media that you've ripped, https://picard.musicbrainz.org is the fastest route to correctly tagged media that scrapes without issue.
-
The FD628/TM1628 driver was submitted upstream and then bike-shed'ed to a standstill, so it remains un-merged and the author has no plans to resurrect the effort. I have been including patches in the Amlogic kernel that I maintain for the AMLGX image for some time. To have the driver work, the VFD layout needs to be correctly described in device-tree. I've created device-tree files for other boxes in the past, but the only one I still have in the AMLGX image is for the TX3-mini. The driver is not designed for use with openvfd or lcdproc userspace tools, although the openvfd repo is useful for figuring out the pins that need to be bit-banged to make things work. The nearest you can get with userspace configuration is issuing a sequence of fdtput commands to modify the device-tree file that boots the box (which updates will overwrite).
This kernel branch has the commits to add the driver, and a device-tree for Tanix TX9-pro with the VFD described:
Commits · chewitt/linuxLinux kernel source tree -- WARNING I REBASE MY BRANCHES! - Commits · chewitt/linuxgithub.comNote that this was 10x kernel releases ago and I've no idea now if these patches were ever proven on a real TX9-pro, or whether your TX9 (non-pro) clone will need/use the same layout; although I'd guess the spec difference is limited to RAM size and WiFi/BT module used. Typically users show-up excited that AMLGX exists and then go quiet once they realise playback is not as polished as the older vendor kernel images (not that these are perfect either) so not all device-tree files that I create get tested and sent upstream.
The device-tree compatible also needs to be in to https://github.com/LibreELEC/Libr…s/vfd-clock#L25 .. although it looks like I've done that for the tx9-pro in the past and never cleaned it up.
There are build instructions for creating your own LE images in the wiki if you're that way inclined and want to experiement. I can also pick the patches back into my LE13 test images; although I'm currently working on a kernel driver fix for a long-running bug and it might be a few days before I have that resolved and release a public image again.
-
I'd guess that if you have Kodi configured to play the next episode and media is opened from a view that lists multiple episodes .. it will do what it's been told to do.
No ideas on the stop/exit although Kodi should buffer if the connectivity is poor, so it sounds more like an issue with media itself or something server-side or how the add-on works
-
Random guess based on the PCM comment: have you put Kodi settings from Standard > Advanced or Expert to expose the audio formats to be passed-through?. If none are selected you'll still get PCM.
RPi5 2GB is more than enough for LE unless you want to run a ton of persistent add-ons and services like Docker containers.
-
Kodi has a comprehensive wiki here: https://kodi.wiki/view/Main_Page and a reasonable amount of LE specific things are covered here: https://libreelec.wiki .. there are no tutorials largely because it's an effort to write them (anyone could contribute them to the wiki but nobody does) and there are lots of use-cases (so more effort).
NB: It's generally easier to ask a specific question and then people will give you specific help and answers.
-
RomanHT You didn't understand the answer and need to read up on rsync. In short: as long as the other device has SSH enabled rsync can push/pull files to/from it without needing to mount a remote filesystem first. You can also mount and then sync between the local filesystem source and local filesystem (remote) target destination.
-
If you enable Samba sharing of removable media AND configure samba.conf .. the OS adds a share, and then you manually added the second share. Delete /storage/.config/samba.conf and reboot and it should just work.
-
If you have the original Android ROM image for the box feel free to experiment at your own risk in the knowledge that Amlogic burning tool can always recover the box to its original state. If you don't have that ROM, don't attempt anything.
-
Chrome is only available on Generic-legacy, because it needs X11 as display server.
I would assume he knows that since he tried to boot Legacy.
basubasu see if adding something like video=HDMI-A-1:1920x1080M@60 to kernel boot params in syslinux.cfg has impact. If not, add ssh to boot params so you can login over Ethernet to run "pastekodi" and share the log URL generated. The rest of the OS will be functional even if Kodi/Xorg has an issue with something.
-
-
the non-legacy generic and generic nightly install and run just fine
You have a working system then. What's the problem?
-
The "not supported in this forum install2internal script" repurposes two Android partitions for /flash and /storage. I forget exactly which ones are used but let's assume /system = /flash and /data = /storage. The goal of the script is to not mess with the Android partition scheme (some of which is intentionally hidden from Linux to stop users from bricking Android) so you are stuck with the sizes the original Android ROM for the box implemented for /system and /data (in your case, 4.5GB). It is possible to repartition the internal storage to create more space, but this is a non-trivial task using low-level tools (not normal userspace utilities) and it's not fun to resurrect devices or spoon-feed complex instructions to their pissed-off and panicing owners when things inevitably go wrong and the device is left in a "bricked" state. Hence we avoid the entire issue by not supporting install2internal. If you run from internal storage; whatever you problem is, it's not our problem.
To provide more info: The OS boots from KERNEL (the Linux kernel) and SYSTEM (userspace). On devices with more than 1GB RAM SYSTEM is expanded into RAM to create a virtual (read-only) filesystem. The /storage area has nothing to do with SYSTEM or the use of squashfs, so you cannot gain space by removing squashfs from the LE image. It is possible to create images that do not use a squashfs filesystem; but then the contents of SYSTEM have to be installed to internal storage not RAM, which will reduce the internal space available for /storage.
TL/DR: if you can't solve the issue yourself (as we don't provide guideance or support for the activity) you are stuck with 4.5GB and the best solution for everyone is that you continue to boot and use LE from the SD card.
-
Code
[TOSHIBA] path = /media/TOSHIBA available = yes writeable = yes browseable = yes public = yesSee if this ^ works. I've added available = yes as per the default shares we provide. Also note that modern versions of Windows require SMB auth to be enabled.
NB: The correct way to add the share is to rename /storage/.config/samba.conf.example to /storage/.config/samba.conf and then make changes. You need to reboot to effect the change. This is then copied to /run/samba/smb.conf during boot and used as the active Samba configuration.
