Posts by Psilovybin

Quote from chewitt

If the box boots to the kernel a drive in an "unclean" state will be detected and automatically fsck'd. If the drive doesn't get that far, the issue resides in upstream u-boot; which likely follows the Linux "stop in case you break something" approach rather than the vendor u-boot) "run

vendor code to fix things" approach. I'm not sure there's much to be done here, but the workaround would be to install HD vendor u-boot on the SD/eMMC and then boot LE using the "box" image instead of the "board" image. Then you have the benefits of very poorly written vendor code "fixing" your broken filesystem at the u-boot stage and it might continue booting.

I used to live in a house with frequent power cuts and no amount of software workarounds ever beat running essentials (things that you don't want to constantly fix or risk breaking) from a small UPS.

That never happened with CoreElec or LibreElec 9.0.2, just odd that LibreElec 11 builds are doing this. It's almost like write cache is open all the time and when a power cut happens, it borks something because caching was left open. LibreElec 9.0.2 build doesn't do this, only the LE 11 builds

I was also using the latest LibreElec on my C2, and the power went out. Power came back on and the C2 couldn't find my hard drive so I was able to see that the har drive wasn't working because apparently, the drive was in a caching state when the power went out, left some bits open and I had to go into Linux on my main PC and correct the drive. Everything came back up. Power went out a few days later and the same thing happened so I fixed the drive again.

Went back to CoreElec 9.2.8 (last C2 version) and the power went out again but my hard drive was fine when the power came back on.

(I live in a very rural area and when it rains, there's a good chance the power will pop off for a few minutes. It happens)

Seems LibreElec is doing something different when the hard drive is being used, I think one of the times the power went out, I wasn't watching or using the hard drive at all and still had to fix the drive. Devs may want to look into what is caching the drive on power loss and corrupting bits. I'll just have to manage with CoreElec 9.2.8 until I can get a C4 or something else.

Quote from chewitt

NB: If you flag what firmware is requiredfor the USB WiFi stick it can probably be picked into an image (for long-term support).

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/mediatek/mt7610e.bin?h=20230310

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/mediatek/mt7610u.bin?h=20230310

was the firmware I used, I don't know how popular this USB Wifi dongle is, but that's what solved my issue.

On the buffer exhaustion missive, I can also see in the logs where ffmpeg is having an issue with this.

I'm aware of the issues that's currently plaguing the ODroid C2 but i'm much appreciative of the Support LibreElec and the developers still developing for this board. I know it is a hassle which is why CoreElec just dropped it completely.

"Just spend 60-120 for a New SBC!" I don't have that luxury as i'm on a fixed income, disabled and eating comes first.

I love my Odroid C2 and I was using CE 9.2.8 up until a few days ago because I was having some glitchy errors and started noticing the logs not able to hit the update server, couldn't add any addons and essentially, the 9.2.8 CE is pretty much dead so I check LE and lo and behold, there is a Nexus version for my lovely ODroid C2. Had initial problems with my Archer T2u Wifi USB adaptor, but I was able to rectify that by wgetting the kernel drivers from the firmware on kernel.org and dropping them in /storage/.config/firmware/mediatek, rebooting and my adapter showed up finally.

All is well until I play any HEVC title.

Here is a log

I'm only posting this hoping to help with the HEVC decoding if anyone is working on it, not looking for top tier support, i'll try to work around this. I may have to reencode my stuff back to h264 if this becomes too much of a problem and thanks for listening!