Posts by frakkin64

    I wondered what is the case and i ran into the 2.4 GHz bug

    The bug was fixed 3 years ago, LE10 already has the later firmware. As for 5GHz, it already will pick it automatically, not sure what the criteria is but it may be signal strength. In my case, it works fine out of the box:

    # iw wlan0 info |grep channel

    channel 149 (5745 MHz), width: 80 MHz, center1: 5775 MHz

    It's possible your problem is buffer cache related, but I guess if this solved it then great. 5GHz will be a bit less congested, but I doubt it will solve any bandwidth problems on the Pi4 if that is the cause of your original problem.

    I'm worried that a backup made while SQL databases are being written will contain corrupted database files, and possibly other problems related to files being backed up while in an inconsistent state.

    SQL databases especially, depending on the configuration there can be data loss as it is not unusual to hold changes into a buffer cache and write them to disk later. Typically I do a backup with mysqldump (as a hot backup) and as chewitt mentioned the changes to the Kodi db are pretty low volume. Since my backups are daily there could be up to 24h of data loss, but really the only loss for me is watch counts as the data comes from NFO files on the sources.

    I would investigate each applications backup options, and follow their guidance. This may mean you need to write a cron script and use "docker exec" to run the backup command in the running container. You will need to adjust your docker configuration to probably include some volume for storing backups.

    I'm in the Miami Florida USA area and one of the local 1080i TV stations somehow put in the European frame rate of 25 fps in their metadata instead of the ATSC standard 29.97 fps.

    I can receive most of the major stations from Miami, haven't noticed a problem and they all seem to be reporting 29.97 for 1080i stations (WPBT, WFOR, WTVJ, WPLG, WLRN, WAMI). I know there are a few LP stations that I can't receive, and those are always a bit questionable. :)

    In terms of settings, found these work best:

    They may be talking about 4K/HDR, but a lot of it is relevant for a 1080 FHD television as well.

    hmmm, my mistake probably, I have to admit I didn't try, but I do remember I read it under somewhere at the end of some Release-notification. Probably it's my mistake, and I misunderstood the information about the new amlogic-ng builds...

    Thanks for correcting my statement, I'll give it a try.

    Yeah, CE works fine on gxl. I was running CE on my gxl (Vero 4K+/S905D 2GBe) device via SD card. Early on in the the 19 cycle they were missing some reserved memory and some of the gxl devices wouldn't start Kodi, but that was fixed about 8 or 9 months ago.

    I am just using OSMC on that device (which is what it comes with, since it's an OSMC branded device), and testing LE via SD card. But something is hosed up with YouTube on LE 20, and haven't had time to dig into it, which 80% of what I watch is YouTube on that device. :)

    What I'm exposing are torrents. I am fully aware that there multiple ways to mask your IP, but at least for the best of my abilities / tools available, I would block those users to get torrent pieces from me.

    You don't really mention the torrent client, but many of them support block lists for this sort of purpose. For example, Deluge, which I would highly recommend:

    Plugins/Blocklist – Deluge

    It's up to you get a list of IPs. Perhaps there is an ipfilter.dat already out there, who knows. I tend to not really use torrents.

    I suspect the problem is probably more on the end of creating the coredump. What I would try is (and don't know if this would work):

    rm -fr /storage/.cache/cores

    ln -s /dev/null /storage/.cache/cores

    If you want to influence the path variable, you can probably do that with /storage/.config/kodi.conf environment file and see if it has any effect. You just create that file, reboot, and before systemd runs the script it will load in that environment file.

    It seems I better look into the Amlogic chipsets since this device will be only a media center and video decoding is its main function.

    You should plan on buying an SBC and not an Android TV box, and you should definitely research which SBC you buy and how well they are supported. I have heard complaints that some SBCs are all great until it breaks (the warranty/support is sometimes non-existant, they likely suspect it is a user fault, and it probably is most of the time). Since most Amlogic devices with working video decoding are running a 4.9 kernel or older you should expect problems with device compatibility. So really make sure what you buy is 99% self contained (on-board the SBC), and any devices you intend to plug in are fully supported by the OS your planning on running. Good luck.

    Rockchip might me something worth looking at, not super familiar with those boards, but I believe a lot of it is mainline supported. Just know my experience with Amlogic is not great, RPi is great for me.

    Screenshot might help and LE version your running, but my guess here is you might have an incompatibility between the EEPROM & bootloader? You could try using Raspbian to install the latest EEPROM, and try the SD again.

    IMO 8GB is way excessive for a media center, 2GB is plenty and 4GB is generous.

    There are some rev 1.6 boards that I have heard may require bootloader updates. So you might need to try to update to LE 10.0.2, if your still on LE 9.2.x and earlier then the recommend path is a fresh install.

    At this point buy what you can find & want to spend money on, as long as it's 2GB or more and fits your intended usage. :) I can confirm 2GB is totally fine if your interests are basic media center usage, yet to find any add-on that doesn't work, but it depends on your workload. Some people like to use the RPi for everything under the sun plus a media center, but I just use it for the media center and have PVRs and storage on AMD-based servers.

    By the way, the basic media center usage with a 512MB video buffer cache doesn't use more than ~750MB of RAM in total, I also don't run Samba or Cron services as I don't need it. YMMV.

    As long as you backup the eMMC using "dd" first it shouldn't be too hard to restore it again if things go wrong. GXL devices boot the same from eMMC and SD card so once you've erased eMMC it's simple to test u-boot(s) from SD and when you've proven it works, you can write the boot stuff to eMMC. In the event you do screw up and need to erase eMMC the worst-case scenario is shorting pins on the eMMC chip to stop it being checked during boot, and then the SOC finds u-boot on SD or USB again.

    Ah yes, I recall reading that Amlogic will fallback to booting from an SD card when the eMMC wiped. And I do have dd copies of the eMMC already, just recently had a problem where the instaboot partition was wiped and OSMC uses that partition as a part of the VG for the root disk. I am guessing there is some "Android" specific scenario that causes this, this is the 2nd time I have ran into.

    I guess I'll need 2 SD cards, one with the original Amlogic U-Boot and some sort of basic Linux OS to run DD on (sounds like LE will do), and another one with the testing U-Boot.

    IIRC there are some capabilities that OSMC runs from the secure world (BL32) to prevent them being copied (Dolby Vision?) so any mainline u-boot will lose those (not that upstream supports DV anyway). I can ask Sam for the boot FIPs (minus the BL32 bits I'd expect) and then it's a straightforward process to create a complete image.

    For now I used gxlimg to pull those pieces out, and they should be usable directly in aml_encrypt_gxl I would think (at least it doesn't complain). Probably the next step is to give this a shot from an SD card.

    Any thoughts on how to approach mainline U-Boot? I did test the libretech-s905-pc config (which is a close match) with mainline U-Boot via chainloading:

    fatload mmc 0 1000000 u-boot.bin

    go 1000000

    Console went from the SDIO debug board (using a Adafruit SD card breakout board with a 4.7k pull-down resistor between D3 & ground, then with my USB UART its RX is on D3 and its TX is on D2) to the TV, but U-Boot does appear to work and a bit more functional than the Amlogic U-Boot in the sense that tftp is working. It did seem to recognize the eMMC, but assuming there are some tweaks to get it to use the UART. I also assume that mainline U-Boot knows nothing about the Android MPT partition table (much like mainline Linux is oblivious to it), so eventually a format of the eMMC would be in order.

    Main goal was to verify I could chainload, to verify the status of U-Boot. Does anyone else do it this way, or do you just go for broke and write U-Boot to the eMMC? :)

    The contents of the /flash partition does not change when toggling the setting. This message tells me that it actually happens when performing the reboot. But the subsequent reboot does not manage to actually perform the update.

    The LE app only touches a file /storage/.rpi_flash_firmware with the contents of the switches selected, at reboot when this file exists LE starts a target for flashing firmware. However this only installs from the critical channel, so that's going to be the January 25th EEPROM you see with "rpi-eeprom-update". It sounds like that part is all working correctly, but perhaps the command run during the target has an issue, do you have a screen grab?

    Maybe you can run this via ssh and see if there is any error? It will just stage the eeprom updates (same as rpi-eeprom-update -a):

    USE_FLASHROM=0 /usr/bin/.rpi-eeprom-update.real -A bootloader -A vl805

    You should see the same output as rpi-eeprom-update -a, and if you can check for the existence of the flag file /storage/.rpi_flash_firmware after toggling in the LE app the contents should have one or both of these set to yes:



    Yes, that is what i meant with "switching on the update setting". Than at boot it does show some firmware messages, but nothing gets applied.

    If you log in via ssh, what does "rpi-eeprom-update" show? I never use the settings app, but I just updated via ssh using the stable channel and that method works fine.

    What the script does is stages a recovery.bin in /flash, and 2 files pieeprom.upd and pieeprom.sig, the rest is handled by the Raspberry Pi hardware itself. The bootloader will look for recovery.bin, which I think is the flashing program and that looks for the signature file & update file to flash.

    So perhaps, toggle the update, login via ssh, and check the /flash folder to see if these three files exist. If they do, and after rebooting it doesn't work, then maybe this issue may help with that as it sounds like maybe boot order plays a role or having USB drive & SD card may be an issue?

    rpi-eeprom-update don't flash · Issue #220 · raspberrypi/rpi-eeprom
    Hello, I was unable to flash the eprom again, the rpi-eeprom-update says that flash it ok, but then after a reboot all remains the same. This is RPI 4 b model…

    Did you install the firmware? It's not automatic. You have to open the LE Settings app, go to firmware, and at the bottom there is 2 toggles to install the firmware on next reboot.

    I usually just jump into ssh and run "rpi-eeprom-update -a" and reboot. LE is tracking the "critical" channel, not "stable" or "beta".

    Depends on whether you have "Adjust display refresh rate" enabled or not.

    GUI resolution should stay at 1920x1080, and adjust display refresh rate should be enabled. The guide above has recommended settings, which includes whitelisting resolutions & refresh rates to get the best experience. If you change the GUI, unless you have an x86-based device, you will probably run into stuttering during playback of non 4k content.