Posts by chewitt

Feb 16 18:11:01 LibreELEC kernel: meson-vrtc c81000a8.rtc: registered as rtc1
Oct 25 09:21:39 LibreELEC kernel: rtc-hym8563 0-0051: registered as rtc0
Oct 25 09:21:39 LibreELEC kernel: rtc-hym8563 0-0051: setting system clock to 2023-10-25T09:21:39 UTC (1698225699)

^ the RTC chip seems to be doing its thing. Initial kernel time is taken from the glibc release date which is in the past but normally within six months-ish as LE uses a recent-ish release. The RTC chip is probed and then updates time, and then NTP (connman) is correcting time based on latest internet polled time:

Oct 25 09:21:48 LibreELEC connmand[891]: ntp: adjust (jump): +2.225134 sec
Oct 25 09:21:51 LibreELEC systemd[1]: Finished wait-time-sync.service.
Oct 25 09:21:51 LibreELEC systemd[1]: Reached target time-sync.target.

then a minute later crond shows this:

Oct 25 09:22:40 LibreELEC crond[489]: time disparity of 360911 minutes detected

^ I was thinking this is the RTC corrected jump between Feb 16 and Oct 25, but Google says that's 251 days and 360911 minutes is 240 days, so that doesn't line up correctly.

Oct 25 09:22:28 LibreELEC systemd[1]: sshd.service was skipped because no trigger condition checks were met.

^ this is also odd. The trigger conditions are either "sshd" in kernel command line (from boot params in uEnv.ini or extlinux.conf) or the file /storage/.cache/services/sshd.conf existing and that should be created on first boot.

If you do "touch /storage/.cache/services/sshd.conf && systemctl restart sshd" does the daemon start?

Can you also run "blkid | paste" and share the URL or output?

Also for kicks, please use https://chewitt.libreelec.tv/testing/LibreE…80.0-box.img.gz to boot in case some random bug has been fixed since the last LE11 release. This is an LE12 nightly from my own branch.

Quote from rmappleby

In short, is there a compelling reason to go with RPi5 rather than RPi4?

Speed and CPU grunt. Menus and screens are noticeably 'faster' and the extra CPU grunt broadens the selection of media that the board can CPU decode with ease. The 4GB RAM size isn't really required for LE but the 2GB variant isn't being produced yet. If you're on a tight budget an RPi4 will check all the immediate boxes and be a nince update on RPi3. If there's a little more room in the slush fund I'd still go RPi5 tho.

Enable debug logging, clean boot, demo the problem with local medai, then "cat /storage/.kodi/temp/kodi.log | paste" and share the URL.

If the main variable is LE u-boot vs. Tow-Boot and LE works, it implies the issue is something being done differently in Tow-Boot. In that case the "why doesn't it work" question really needs to be put to the Tow-Boot maintainers, not LE maintainers. As a general rule Linux should be configuring the hardware when it takes over from the boot environment, but in some cases you do find an underlying dependency on things like clocks where the bootloader is setting something and Linux is not (thus blindly inheriting whatever the bootloader did). LE is currently using u-boot 2022.10 with a few minor u-boot patches, but nothing that stands out as significant to me. In short..

Please test a current LE12 nightly .. let's see if newer kernel/drivers have fixed anything since LE11?

HarryH in addition to testing it would be easier to review changes if you push code to a GitHub repo. Feel free to reach out if you need any help with that process.

One of my guesses was right then! .. but nice work on fixing it

After you disable the service, mask it, e.g. "systemctl disable lircd.service && systemctl mask lircd.service"

I'm not sure how time could impact on Kodi starting or SSH login which is what your comments hint at. Not least because this is a box with an RTC chip so while time might not always/initially be accurate (ahead according to the boot log; the last line shows time being corrected) it shouldn't ever be so far off it causes problems, and a single working boot (Linux or Android should keep time current.

Can you run "journalctl | paste" and share the URL; this will mostly show the same log out but with timestamps.

I understand people still want to use WP2 boxes due to the DVB cards, but IMHO most users would be better off using them as a pure head-end (server) device and an RPi4 or RPi5 board as the client device as the software support is sooo much better.

The one other thing you can try is adding "textmode" to boot params. This boots the box to a text console (not Kodi) allowing you to poke around in the OS to look for problems using a USB keyboard. If the issue is still related to Kodi specifically it's not going to be seen (as Kodi isn't started) but... you might spot something.

Otherwise I've no idea what the issue could be. I've installed AMLGX images on a couple of things using the same batch of files in my testing share earlier today and they all run without any major issues.

To see more, we really need to see the systemd journal log and/or kodi.log to see what's causing the issue.

Package description fix PR https://github.com/LibreELEC/LibreELEC.tv/pull/8243

Both "dvbscan" and "w_scan" are included with the "DVB Tools" add-on in the LE repo. The description for the add-on only mentions w_scan but looking at the package sources we bundle everything in the dvb-apps package so the description needs fixing/updating:

LibreELEC.tv/packages/addons/tools/dvb-tools/package.mk at master · LibreELEC/LibreELEC.tv

Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.

github.com

For the record, here's the same logs from my WP2 box (connected to a Marantz AVR > LG-B7V TV) which has no problem with EDID data, and thus we have confidence it's not a general software problem (there's also a moderate number of active WP2 installs).

dmesg: http://ix.io/4JK0

modetest: http://ix.io/4JJZ

IMHO if users want a NAS they're better off aiming for a lower-spec Synology box like DS223J which is purpose-built and easy to expand in the future to include a second drive for data redundancy. The cost difference vs. an RPi4 + PSU + Case really isn't so big and it'll be easier to use and maintain than a homebrew RPi device, and there's no rats-nest of cables and PSU's to deal with. If you do want to go down the RPi route look at OpenMediaVault or similar (NAS distro) unless you plan to use the other RPi for playback too.

Quote from konrul

But as you might know already, RPi4 does not support h264 very well.

I'll call phooey on that statement ^ .. RPi4 has no issues with any of the H264 media I've tested with.

What application or service provides the IPTV server?

Plug something else into the same HDMI socket on the TV (PC or other HTPC or .. something). Any issue? If no issue, perhaps the HDMI socket on the WP2 is damaged. These are old boxes now (8-years) and faults like dry solder joints start to show up among users.

Otherwise ..

The modetest output shows no EDID data. Either the TV doesn't advertise any, or there's a fault with the cable, or the box has a problem so it's not recieved. HDMI 1.4 cables will (or should) still pass EDID info.