Posts by frakkin64

    it's up to the devs to make the final decision

    Seems like it was already made with the comment that only 20 users seem interested in these features, so at this point it's just trying to sway positions. The way I see it, since we are swaying positions (or sharing thoughts), for a media center device there is no use case (at least for me) for disk encryption, mdraid, or lvm2. But I also just use a NAS with ZFS, and I use the built-in NFS client in Kodi to access the media and don't want to deal with trying to plug in 9 drives via a USB hub and then wonder why it's so slow moving a file. Basic works well.

    In any case, not sure I agree with the argument that it stops with raid support. But it would be interesting if features were upvoted/downvoted to see what the community interest was.

    I'm actually surprised as well that LE does not support simple raid 1 (mirror). Although I understand the "Just enough OS" approach, I think raid 1 and partition encryption sound like a basic/essential requirement. Anyway, this is my imho

    Pretty dated comment to respond to, but my question to you is where does it stop though? I don't want to use mdraid, I want zfs, or I want bcachefs, or I want <insert next great thing here>. Before you know it it's a full blown Debian install with all of the support requirements of it.

    rpi-update is unique to Raspberry Pi OS and it's compatible derivatives. The only way your going to get new "firmware" is by installing a newer LE image as they are baked into the image, or downloading and installing them manually to /flash.

    The files you are talking about are baked into the image by the bcm2835-bootloader package, see here. They are installed to /flash on upgrades by this script. I believe the tar ball (hosted on LE's site) is prepared by this script.

    The situation is by the way the same for the EEPROM firmware, so if you have a recently purchase RPi4 and installed LE 9.2.8 then yeah rpi-eeprom-update is going to only have older EEPROM firmwares available for installation, like the bootloader those are also baked into the image and are only delivered by LE image updates. You can manually download those and install them with rpi-eeprom-update command line switches, or pop in a recent RPiOS and burn in the EEPROM firmware that way. But the bootloader files are loaded from the SD card/disk by the EEPROM, they are not burned into a ROM.

    Your first log indicates a connection issue to your SQL database, which if I am reading this right is on the same machine. That would seem to suggest a problem with your network configuration (perhaps the netmask is wrong?). You might want to go into LE settings and make sure Wait for network connection is enabled, as that may be a contributor to that error.


    The 2nd one is either a DB issue or the 121 database is too old to upgrade (not sure if anyone has tested upgrades from 121 to 128, maybe it works and it's a unique to you problem). The error is with this SQL:

    2024-01-08 21:27:20.916 T:1266 error <general>: SQL: [MyVideos128] Undefined MySQL error: Code (1050)
    Query: CREATE TABLE videoversiontype (id INTEGER PRIMARY KEY auto_increment , name TEXT, owner INTEGER) CHARACTER SET utf8 COLLATE utf8_general_ci

    You can try to run that create statement in a mysql command line and see if it indicates anything more specific. Not seeing a lot of posts complaining about this, so it might be something unique to your setup, also suggest posting on Kodi forums for wider visibility. (1050 is Table already exists, btw).

    I just know I have MariaDB on a separate host (my NAS), and I have done many upgrades over the years and never really had a problem with it. Probably the biggest issue was the bump to MariaDB 10 there was a change with legacy password hashes/older client compatibility that required a setting change on the MariaDB side.

    Sometimes it's better to stick with what you have, even if it's slightly dated, but at least reliable.

    Yeah, perhaps some of the older devices will get attention now that the devices are basically end of life. But that attention would probably have to come from volunteers in the community. My understanding is the latest Amlogic vendor kernels dropped GXL support, and that will just continue and propagate to projects still using those old vendor kernels and eventually they will move on.

    It sounds like I should be deterred by the 11.0.4 release notes? =O Is there anything specific that you think might put me off?

    I would read them, if you haven't already. It is highly dependent on the media you are consuming, so it's really something you would have to answer for yourself. It's usable on GXL devices with 1080p media, but the release notes outline quite a number of things that are not working that are important to some people. I mostly use it for MPEG2-playback of 480/720/1080 progressive/interlaced content (PVR recordings), and MPEG2 HW decode is totally broken so it is all ffmpeg software decode currently, beyond that I have used it to playback Xvid and H.264 content which seems fine.

    Nothing, but a lot to loose in terms of watchability of videos because of the block of text in the top left of the screen when debuging is enabled.

    Enable it via the advancedsettings.xml, it will just turn on the debug log (no visualizations):

    Code
    <advancedsettings version="1.0">
        <!-- https://kodi.wiki/view/Log_file/Advanced -->
    
        <!--
           -1 = no logging
            0 normal logging
            1 debug logging
        -->
        <loglevel hide="true">1</loglevel>
    </advancedsettings>

    I dont have a PC monitor here to try. Just 2 tv Samsung but any of them I can watch LE

    I dont know what I can do more.

    Works fine with my Samsung TV, no tweaks necessary really (mine is 4K, so mainly just have 4kp60 enabled in config.txt).

    What model Samsung?
    Is it 4K?
    Are you plugging into the right HDMI port (one near the power input)?
    Are you using ethernet or wireless?

    This information above is for Raspberry Pi OS, really doesn't apply to LE. The easiest way to turn on SSH is just connect the RPi to a monitor that is working with it, go into the LE Settings app and turn it on. The alternative way is to add " ssh" to the end of /flash/cmdline.txt, you should be able to find instructions on the forum (no quotes, add to the end of the existing line in the file).

    So I tried one of the nightly build and it didn't change anything, in fact it might have actually made them slightly worse. The Kodi splash screen has weird colors / distortations and the wireless still doesn't work right. After one reboot I needed to unplug it and plug it back in. On reboots where it showed up it still wouldn't autoconnect.

    The splash screen is by design. So, you have to attach logs, so we can actually get a clue what the current situation is. If it is the same, then your problem still exists and if you want to use that USB wifi dongle then you will probably have to get support from the Linux kernel maintainer. If you don't want to do that, then your only option is to buy a different device to connect to your network and continue to play the wifi roulette.

    By the way, I have had good results with TP-Link T3U (aka AC1300), which uses the same driver just a different chipset (RTL8822BU). Half the battle is finding a device that actually works with Linux, then other half is wireless itself.

    rtw88 driver had a lot of issues with Linux 6.1, never used 8821cu myself but have seen similar problems with 8822bu. LE12 nightly has a lot of updates for this driver from Linux 6.6, so would suggest trying LE12 nightly and see (it's built on Kodi 21 beta 2, and has been very stable for me).

    RPi4 doesn't have a clock, so LE needs network connectivity and a working network stack to reach an NTP server to set it during the boot. If you do have an RTC, then you would likely have to enable it with an overlay, check with who sold the device. It will likely need NTP to initially set the clock.

    I don't know anything about HifiBerry, but pointing out the obvious that it also depends on your media source. If your media source is not 5.1, is poor quality, then garbage in/garbage out. I'll leave it to DAC users to comment, I just use audio over HDMI.

    So, new SD card - New LibreELEC-RPi4.arm-11.0.3.img

    but im still getting "ERROR IN MOUNT STORAGE" (image attached)

    Any ideas please? Is my Pi4 corrupted?

    It's probably the SD card, there are some SD cards that the RPi just seems to hate. I don't know if updating the EEPROM brings better compatibility, because for me the problem eventually went away.

    What brand/model of card is it? Another thing to try is pop the SD card into another computer, edit the cmdline.txt on the FAT partition and add this at the end of the line (not a new line, without quotes, make sure to add a space and then the text):

    " sdhci.debug_quirks2=4"

    This will disable UHS modes, IIRC. The card will operate slower, but perhaps more reliably. That's what used to work for me on LE10.

    LE12 nightly box image works, with the known issues in the release notes. I have run LE, CE, Armbian, and OSMC on the Vero 4K+, the former three are via SD card (nothing installed to eMMC other than OSMC).

    The only problem I have with OSMC (in terms of a media center OS) is they are a bit slow on the take up of Kodi releases. I think the other issue that is possibly looming in people's minds is now that they have their next device out how long will the 4K+ continue to be maintained.

    Right now, I am just using it to run Armbian as a serial console terminal. Personally, I am sticking with RPi4 or moving on to x86 devices.


    One other comment with the Vero 4K+ is you have to use the toothpick method to boot the SD card, and be warned if the SD card is not prepared properly then there is a bug in the bootloader that will wipe the instaboot partition and cause OSMC on the eMMC not to boot. This, in my opinion, is because they (OSMC) didn't modify the default bootloader script to remove the "wipeisb" & decided to use multiple Android partitions in an LVM group.

    The percentage of x86_64 users peaked around 30% in the early years of OpenELEC then gradually declined to a stable 10% figure in recent years.

    Just guessing, but I would suspect many x86_64 users are using Windows. HW compatibility, acceleration, DRM, etc is what I would expect to be better & more attractive on Windows since that is the main OS platform x86_64 manufacturers are targeting.