Hi tekno - taken a look, and have backported the PR.
Testing looks good and raised the following PR - https://github.com/LibreELEC/LibreELEC.tv/pull/6678
Will be available soon.
Hi tekno - taken a look, and have backported the PR.
Testing looks good and raised the following PR - https://github.com/LibreELEC/LibreELEC.tv/pull/6678
Will be available soon.
Hi tekno - the following PR will need to be backported. https://github.com/LibreELEC/LibreELEC.tv/pull/6406 I’ll be raking a look.
Display MoreHi!
Just noticed that the timezone database is out of date. The background: our city's leaders have the habit to change the timezone offset and/or the DST literally twice a year, I mean it. Don't ask me why. So, ooops, they did it again and the time displayed is wrong. Pain again
Of course it's possible to choose the suitable timezone instead of my own but it's not very sportsmanlike
I tried to create the latest TZ DB (2022a) and symlink to it
# /storage/.config/system.d/tz-data-latest.service
Code Display More[Unit] Description=Setup Timezone data (latest) DefaultDependencies=no After=tz-data.service [Service] Type=oneshot Environment=TIMEZONE=UTC EnvironmentFile=-/storage/.cache/timezone ExecStart=/bin/ln -sf /storage/.kodi/zoneinfo/${TIMEZONE} /var/run/localtime RemainAfterExit=yes StartLimitInterval=0 [Install] WantedBy=sysinit.target
I suspected it won't work and yeap it didn't work, at least in this form. The symlink is right but the time displayed is wrong
Is there a way to force the system to use the local zoneinfo installation instead of /usr/share/zoneinfo?
As fyi (I know not 9.x) - the nightly 10 and 11 image do have the current tz (and wireless db) packages. https://github.com/LibreELEC/Libr…ges/sysutils/tz
Yes samba 4.16.2 is in the latest nightly. “List of shares” is still an issue. \\server\share working well.
Hi Frank PausE
For samba connectivity browse isn’t working but direct access to your share name should work. (Replace kodi with your LibreELEC name)
\\kodi\updates
Biosy.Baris - you will want to edit the linux.arm.conf file:
and change the commented line CONFIG_SND_SOC_TLV320AIC3X_I2C to CONFIG_SND_SOC_TLV320AIC3X_I2C=m
you can check this in the right module by doing a diff between the .config in http://build.yyy/build/linux-yyy/ and the file below.
$ git grep TLV320
…
projects/RPi/devices/RPi/linux/linux.arm.conf:CONFIG_SND_SOC_TLV320AIC32X4=m
projects/RPi/devices/RPi/linux/linux.arm.conf:CONFIG_SND_SOC_TLV320AIC32X4_I2C=m
projects/RPi/devices/RPi/linux/linux.arm.conf:# CONFIG_SND_SOC_TLV320AIC32X4_SPI is not set
projects/RPi/devices/RPi/linux/linux.arm.conf:# CONFIG_SND_SOC_TLV320AIC3X_I2C is not set
projects/RPi/devices/RPi/linux/linux.arm.conf:# CONFIG_SND_SOC_TLV320AIC3X_SPI is not set
projects/RPi/devices/RPi/linux/linux.arm.conf:# CONFIG_SND_SOC_TLV320ADCX140 is not set
jim_p - yes. If you check the commit log for libreelec-10.0 versus 10.0.2 you will see it is very minimal changes. This is our stable release. The add ons are updated (to both the stable and nightly channels.) you will see the few kernel updates and some other minors. Basically you will be 10.0.2 (with an updated kernel and some fixes). When 10.0.3 comes out which will have the update Kodi patch release - it will be a matter of updating to that. The ability to update back an forward within 10.0.x works fine.
LE11 nightlies are different. There have been some big changes that are harder (more complicated) to go back and forward. But are doable.
Hi FergFerg this link should help you add the firmware - https://wiki.libreelec.tv/how-to/add-firmware
Could it be that the Samba server isn't working in this build?
Use \\server\share - works.
Known error with browse on \\server
1/ no. The githash is a hash. It matches the hash from https://github.com/LibreELEC/LibreELEC.tv/commits/master . The “GitHub Actions” (gha) scheduled builds - grab the latest hash and build that nightly / or manually if initiated manually. The gha has the capability of building a hash, which may not be the latest hash - which is used for release builds, it could in theory be used for nightly to build a previous hash image …
Do you know when these will be updated online? 10.80.6 is still May 6. I wanted to get netcore 6.0.5 so that arm will work on this test build. 6.0.6 is out now too. I can do it manually but I'd rather do it using the package you created for NextPVR
Martin
They are there now.
Display MoreAre there any known issues with SAMBA or SSH?
The device shows as enabled for both services, but I can't ssh or access the samba shares.
I can ping the device, and I can play media off my media server. However I can't access my media player.
Logs:
Nothing seems to stand out in the log to me, but that doesn't mean a whole lot given my ignorance.
Samba works. Just not browse. Put the full share name in \\myserver\myshare
Sorry for complaining about the 0 byte files. I totally missed if's -s parameter when reading the script. I read the new version quickly and I sshed to the rpi to test it. And it somehow fails, probably because of something on
All good. Was annoying me too. There will probably be a number of updates and refinements to the actions code as it is new.
So, I guess I will wait till after the weekend. Thank you for your help.
Once https://github.com/LibreELEC/actions/actions/runs/2477868749 completes. The image should be available at https://test.libreelec.tv/11.0/
Sure, I am willing to try any suggestions. I also searched for a way to make it somehow return the board type, i.e. rpi2 in my case, but sadly I found none. The file /etc/issue seems to be the only one containing it in text.
---edit
I did not notice the quoted text (rough day today, sorry). So, if the script does check for 0 byte files, please ignore my last suggestion.
The 0 byte thing is now cleaned up. (But only after a workflow is completed. https://github.com/LibreELEC/acti…uite_focus=true
The pr that fixed this is: https://github.com/LibreELEC/actions/pull/3
You can see the cause of the issue in the build-image logs.
We are working to have a larger server for the .img.gz files. But until then - max 2 copies of each img.gz file and the cleanup is done after the workflow (not the job) completes.
Do you mean trouble accessing the shares on the Pi from a computer, or accessing SMB shares on a computer from the Pi.
I can ssh into the Pi from the PC, so I know there is no fundamental network problem. If I need to I can probably reboot the PC with Ubuntu and copy the update across from there.
\\server\updates will work (and similar). It is the “browse” share list that is not working.