CoreELEC 22.0-Piers_rc1 Discussion

I updated my device to HK1 RBOX X50 S905X5M. It’s a world of difference compared to the S905X4. The problems I was having are gone. Nevertheless, I hope I can still use my X96 in the future.

I wish the development team lots of patience and perseverance. Knowing the LibreELEC developers (Milhouse), I’m sure you’ll be successful. I’m keeping my fingers crossed for you.

Thank you for your efforts!

I have this exact box. When I try to install from microSD card, it brings me to the Android recovery. Installing and booting from USB works fine.

When I boot from USB, pop in the microSD card, it recognizes the microSD as storage.

Were you able to get it boot from microSD? I have a generic 64GB microSD and debating buying a more reputable one to test.

@technoob9

Hi, buy a UHS-I class microSD card.

I’ve never used a card with a capacity larger than 16GB. The reason is simple: backups are faster than with a larger microSD card.

Everything else runs from a NAS server or SSD, or via a USB flash drive.

Flash the firmware to the microSD card (using Win32DiskImager or BalenaEtcher). The latter is easier for beginners.

  1. Unplug the power cable.

  2. Insert the microSD card.

  3. Insert a toothpick into the audio input and press until it clicks, then hold it down (It’s best to break off the tip of the toothpick; that way you can easily hit the microswitch in the audio jack.).

  4. Plug in the power cable. The device will blink a few times. Remove the toothpick.

HK1 should now boot from the microSD card. I haven’t had any problems with it.

It’s a bit of an odd piece of advice (I’m NOT saying it won’t work!), considering that the creators of CoreELEC explicitly recommend Rufus - and it’s open-source, too.

Yeah thanks. I will try buying similar microSD.

100% agree. Been using Rufus for years. So much easier for noobs that the others.

“Many roads lead to Rome”. I personally have been using Win32DISKImager for years. I’ve never experienced any surprises with it. Of course, I also know Rufus, which I mainly use for Windows images. :wink:

With RC1 (and even the more recent nightlies) i’m experiencing high audio bitrate stutters and dropouts (ex: TrueHD 5.1 96khz with bitrates above 8200kb/s on john mayers what the light is concert bluray [chapter 20, 1:34:00 thru 1:36:30). I’m running coreELEC Piers 22 on the amazon FireCube 3rd gen. Its present on rc1, and the 10/10 nightly as well as the 10/19 nighlty (and a few others in between i’ve been trying out). I’m also using PM4K addon to stream from my plex server.

I initially had this audio dropout issue on my nvidia shield pro 2019 which drove me to want to use coreELEC(along with the dolby vision FEL of course). I see in the last 2 weeks the nightlies have lots of comments and changes regarding HDMI and timing so I think this is under active investigation and work, but if you need any example clips or additional info please let me know and i’ll help however I can (not a developer, but tinkerer/tester). I was able to get this working on shield by using kodi + PM4K and the IEC hdmi packer, but it seems the coreELEC ALSA hdmi packer still has this high audio bitrate bug. I’ve read elsewhere the movie “Free guy” has extremely high bitrate audio that can cause the dropout/stuttering bug too.

in CE21 have access to sd-card with Linux Mint or Windows

in CE22 i have only access to the “COREELEC” Partition but not to the other Partition “STORAGE”

In the Filemanager from Kodi, i have access to both partitions. But not if i use the SD-Card in a PC with Windows or Linux.

any Idea why?

My device is a TX5 S905Y5, Android 14, and CoreELEC 22 RC1 runs perfectly on an SD card, but it cannot be installed to eMMC. I tried following the methods from other projects and manually modified the eMMC partitions, copying the corresponding files over, but it still could not boot CoreELEC from eMMC. The damaged Android could not boot, and I think a factory reset was performed again. When booting CoreELEC from the SD card again, it would reboot infinitely. Reflashing the manufacturer’s Android image did not help either. Later, I tested by booting into text mode, and as soon as audio was played, the box would reboot. I want to know whether the Android system in eMMC affects CoreELEC on the SD card.

Can you provide a short video sample that reproduces the stutter.

Here’s a 2min clip. For me it doesn’t always stutter at the exact same point, but I usually get 4 or 5 stutters at least in this passage. Let me know if you’re able to reproduce the issue on your side. Looks like in tonight’s nightly theres a bunch of stuff changing that might impact this again, so eager to test again after the update :slight_smile: Sample

storage.to/t9rMw2Fb6

I played the sample through 2x without and audio drops or stutters. Put the clip on a USB drive, play it from there, maybe it’s a network issue. Ethernet or WiFi? How are network speeds? CE is booting from USB or eMMC?

Try increasing Chunk size to 1MB, Read Factor to adaptive (or 50x), Memory Size to 64-128MB.
Settings > Services > Caching

Definitely not a network issue, i’m on gigabit ethernet hardwired. Plex (official app) on shield has the skipping issue too (known issue on shield android 9/11 for this hdmi wrapper issue) But Kodi + PM4K on shield can do the 96khz bitstreamed high bitrate truehd 5.1 audio properly because kodi uses its own IEC HDMI wrapper instead of the android one.

Can I ask which device you’re using for coreELEC, which build you’re on (rc1 i’m assuming?) and what kind of audio receiver you have? Were you able to confirm on the receiver you were getting bit-streamed TruHD 5.1 with 96khz and that the coreelec device wasn’t doing decoding or transcoding (in case your receiver didn’t support truhd 96khz bit streaming) and that you have passthrough turned on in the audio section of settings of course.

My setup is an Onkyo TX-RZ830 receiver. CoreELEC 22 nightly 10/19. HDMI passthru with TrueHD 5.1 96khz showing up on the onkyo info. (If I force coreelec to do the decoding and push PCM 5.1 to the receiver instead there’s no issue, but essentially that means coreelec box is decoding and its not sending the audio via bitstream over HDMI to let the receiver do the decoding).

I only checked that the received signal was TrueHD (yes from the latest nightly). These are my audio settings. When TrueHD capable receiver + passthrough are enabled there’s no device decoding.

There’s more to network streaming than whether gbit ethernet is present. Play the clip locally from the eMMC or USB stick. Try those caching settings. If the stuttering is present when playing the video from eMMC/USB then enable Kodi debugging and grab the logs.

because STORAGE is a linux EXT filesystem that windows doesn’t support
complain to microsoft.com

In Linux, you should definitely see both partitions.

You might need to mount the partitions in the file explorer (Nemo) in Linux first, although Linux Mint usually mounts them automatically.

In Windows, you can definitely see the “flash” partition.

I once experienced a situation where the “flash” partition had lost its assigned drive letter.

How to change drive letter.

samba.conf (4.0 KB)
Try this in configfiles folder.

mounted in Linux Mint is only the Coreelec Partition. The Storage Partition will not mount

in CE 21 mount both, only CE 22 not

maybe a to old Linux? I use Linux Mint 13

Thanks for your time in helping look at this and the suggestions. From a networking perspective I send very high bitrate MKVs like Lord of the Rings FEL over the network without issue (>120Mb/s encoded bit rate on those discs) but still it was a good idea to try local playback instead of network/plex to help isolate. Unfortunately even locally (sent the John Mayer test clip mkv over winscp to the /videos dir) I still am getting the same skipping. I updated to the latest nightly to see if last nights changes helped at all but same problem. Then I tried the recommend cache settings and no go there either. Before I did the cache changes I did enable the log. I’ve got CE running on eMMC btw, I think I forgot to mention that last time.

Logs:paste.coreelec.org/2/GYse