Nightly builds (NEW)

sammutd88 · 27 July 2023 07:40

Is new 20.3 nightly on Amlogic-ne incorporating the back port for DV support?

coolyzp · 28 July 2023 17:18

Where to download amlogic-ng-dv 20.3?

vpeter · 28 July 2023 17:19

Nowhere. Release will be available with stable 20.3 release.

rasto4nik · 7 August 2023 12:59

On this build https://relkai.coreelec.org/Amlogic-ne/ce-20/CoreELEC-Amlogic-ne.aarch64-20.3-Nexus_nightly_20230807.tar on the hk1 s905x4 iptv pvr simple client switch off with no compatible. How fix this bug?

Portisch · 7 August 2023 13:56

crazyturk · 3 September 2023 23:30

Omega 20230904 nightly version Bluetooth does not work.
Device Gt King ii

ctyrka · 5 September 2023 08:14

Hello, just a tiny issue I’ve noticed since 2 or 3 weeks I am using CE on Homatics box (Dune HD). I’ve installed CE 20.2 nightly and box already updated couple times via auto update since. Despite the new build probably installed, I can still see 20.3-Nexus_Nightly_20230816 in CE addon as an OS version.
I guess it pulls the info from /etc/release:
Amlogic-ne.aarch64-20.3-Nexus_nightly_20230816

Is this a bug or my system has never been updated despite the message about new update was downloaded, asking me to reboot the box, which I did. How to find out CE version, running on the box?
Thank you.

Portisch · 5 September 2023 08:29

Last one is 20230905:
https://relkai.coreelec.org/?dir=Amlogic-ne/ce-20

You see in /storage a file like update info where the last update process was saved.
Share this file please.

ctyrka · 5 September 2023 08:34

CoreELEC:~ # pwd
/storage
CoreELEC:~ # ls -la
total 29
drwxrwxrwx   16 root     root          1024 Sep  5 09:58 .
drwxr-xr-x   13 root     root           245 Aug 16 02:25 ..
-rw-------    1 root     root          2442 Sep  4 15:41 .bash_history
drwxr-xr-x   16 root     root          1024 Aug 28 10:43 .cache
drwxr-xr-x   18 root     root          1024 Feb 16  2023 .config
drwxr-xr-x    7 root     root          1024 Feb 16  2023 .kodi
drwxr-xr-x   13 root     root          1024 Aug 26 14:05 .opt
drwx------    2 root     root          1024 Aug 28 11:40 .ssh
drwxr-xr-x    2 root     root          1024 Feb 16  2023 .update
drwxr-xr-x    2 root     root          1024 Sep  4 18:34 backup
drwx------    2 root     root         12288 Aug 16 02:26 lost+found
drwxrwxrwx    2 root     root          1024 Feb 16  2023 music
drwxrwxrwx    2 root     root          1024 Feb 16  2023 pictures
drwxr-xr-x    2 root     root          1024 Sep  5 09:58 pub
drwxrwxrwx    2 root     root          1024 Feb 16  2023 screenshots
drwxrwxrwx    2 root     root          1024 Feb 16  2023 tvshows
drwxrwxrwx    2 root     root          1024 Feb 16  2023 videos
CoreELEC:~ # ls -la .update/
total 2
drwxr-xr-x    2 root     root          1024 Feb 16  2023 .
drwxrwxrwx   16 root     root          1024 Sep  5 09:58 ..
CoreELEC:~ #

Portisch · 5 September 2023 08:53

Then something is broken for you, there should be a init-previous.log or init.log file.
Try clean fresh install.

ctyrka · 5 September 2023 11:50

is this log created also during automatic upgrade or during manual upgrades only? by “manual” I mean copying *.tar (or whatever image file) into /storage/.update and reboot as this is something I haven’t tried yet.
I only experienced 2 automatic upgrades/updates (probably to newer build rather than release) when Kodi popped up with message about newer downloaded image and asked me to reboot the box. Which I did, but I can still see 20230816 and no log in /storage.

CoreELEC:~/.update # find /storage/ -name init*.log
CoreELEC:~/.update #

edit: it’s interesting I am not the only one with this. I know about two other users running same box, same release and no nightly updates. They did only manual upgrades by copying image into the /storage/.update folder.

ctyrka · 5 September 2023 12:48

well, I just did manual update by wgetting 20.3-Nexus_nightly_20230905 into /storage/.update. Rebooted box and now I can see correct version in CE addon. Kodi also popped up with release notes and I can see init-previous.log that hasn’t been the case during “previous updates”. So I guess my box has never already updated previously.
Interesting I know about two more users experiencing very same issue on Homatics/Dune HD box with CE 20.3
I am curious if new nightly builds will install automatically from now on.

Vasco · 5 September 2023 14:23

It’s easy to test it. Just install the previous nightly and see if it install the today’s one.

ctyrka · 5 September 2023 14:27

I am happy box is working, so I guess I rather be patient and wait on 20230905 until the next nightly build. : )

crazyturk · 6 September 2023 07:12

20230905 Omega Nightly version
Alsa aml-Augesound HDMI-MULTI CH PCM
And Alsa aml-Augesound HDMI No sound in these settings.
Device Gt King ii

Portisch · 6 September 2023 09:09

Is the same problem on other platforms?

crazyturk · 6 September 2023 10:20

No problem on other platforms.
20230905 Nexus ne platform no proplem
20230905 Nexus ng platform no proplem
GT King Pro and GT King ii tested with ii

Portisch · 6 September 2023 12:44

It’s broken because of this PR:

github.com/xbmc/xbmc

[ActiveAESink] Improves sinks enumeration names and fallback logic when exact sink name not exists

xbmc:master ← thexai:sink-names

opened 11:34AM - 22 Aug 23 UTC

thexai

+261 -56

## Description - Improves `CAESinkFactory::ParseDevice` returning values in a s…truct instead parameters by reference. Also avoids use same "device" parameter as input/output which is confusing and requires make a copy to avoids get overwrited in some places. - Appends sink friendly name to sink string when is different from sink name. e.g: Before `WASAPI:{B12C1A75-F8A8-4071-8CFB-A285C619CCB8}` After `WASAPI:{B12C1A75-F8A8-4071-8CFB-A285C619CCB8}:HDMI - DENON-AVR (NVIDIA High Definition Audio)` - When open sink by name (GUID in Windows) and exact match not found, fallback using friendly name. - Saved settings are not modified unless user opens audio settings. - When user opens audio settings current device name is "upgraded" and saved in settings, adding friendly name if available. - Even if current device GUID not exist in system anymore, current setting is not lost because fallback to a device with same friendly name and saved as current "new" device. - Fixes https://github.com/xbmc/xbmc/issues/21852 ## Motivation and context On Windows sink names are GUIDs and these may change sporadically with Windows Updates or audio drivers updates. When this happens, current logic is fallback to first audio device in list and this breaks passthrough probably because changes from `WASAPI:x` to `DIRECTSOUND:y` For some users this is just a Kodi bug "Kodi changes sporadically to DIRECTSOUND and breaks passthrough". See https://github.com/xbmc/xbmc/issues/21852 and https://github.com/xbmc/xbmc/issues/22021 Or in forum: https://forum.kodi.tv/showthread.php?tid=373640 or https://forum.kodi.tv/showthread.php?tid=372205 This PR appends friendly device name to setting and, in this way, if GUID changes, same device can be still referenced by friendly name e.g.: Device saved in settings is: `WASAPI:{B12C1A75-F8A8-4071-8CFB-A285C619CCB8}:HDMI - DENON-AVR (NVIDIA High Definition Audio)` But current system device is: `WASAPI:{555C1A75-F8A8-4071-8CFB-A285C619CCB8}:HDMI - DENON-AVR (NVIDIA High Definition Audio)` Kodi can continue operate in this way and saved setting is not altered but a WARNING log message warns of this situation. When the user realizes (if it happens) he can fix it in settings and if not, nothing happens... the next time the user enters in settings it will fix itself for the simple fact that the current setting has changed and the settings are saved when changes. Since the current setting can only be one of the list and in the list there are only the devices that currently exist in the system. After this, "new" saved setting is: `WASAPI:{555C1A75-F8A8-4071-8CFB-A285C619CCB8}:HDMI - DENON-AVR (NVIDIA High Definition Audio)` And the warning message in the logs disappears. All this is designed for backward compatibility, that is, it is not mandatory that the settings have the friendly name. And it is also not expected that the audio device will change by the fact of starting to use Kodi with these changes nor is it expected any significant change in the operation except the improvement when the same exact device does not exist. Even in the case that the setting does not (yet) have the friendly name there are some improvements in the logic: it will always be preferred to change to a device of the same driver first e.g. from `WASAPI:x` to `WASAPI:default` instead of switching to the first random device (DIRECTSOUND). Please review commits separately as has useful descriptions. ## How has this been tested? Runtime tested Windows x64 also in Shield (to look for side effects) ## What is the effect on users? Avoids in some systems sporadically audio device settings are lost because Windows Updates or audio drivers updates. In general it improves (much) the fallback logic when the current audio device is not available. ## Screenshots (if appropriate): ## Types of change - [X] **Bug fix** (non-breaking change which fixes an issue) - [ ] **Clean up** (non-breaking change which removes non-working, unmaintained functionality) - [X] **Improvement** (non-breaking change which improves existing functionality) - [ ] **New feature** (non-breaking change which adds functionality) - [ ] **Breaking change** (fix or feature that will cause existing functionality to change) - [ ] **Cosmetic change** (non-breaking change that doesn't touch code) - [ ] **Student submission** (PR was done for educational purposes and will be treated as such) - [ ] **None of the above** (please explain below) ## Checklist: - [X] My code follows the **[Code Guidelines](https://github.com/xbmc/xbmc/blob/master/docs/CODE_GUIDELINES.md)** of this project - [ ] My change requires a change to the documentation, either Doxygen or wiki - [ ] I have updated the documentation accordingly - [X] I have read the **[Contributing](https://github.com/xbmc/xbmc/blob/master/docs/CONTRIBUTING.md)** document - [ ] I have added tests to cover my change - [ ] All new and existing tests passed

I just reverted it until it’s fixed again.

joco · 6 September 2023 19:14

thanks for the revert.
this problem also breaks the Audio Passthrough feature. All supported modes of my Onkyo amplifier are gone, only Dolby Digital (AC3) is left, but it doesn’t work.

crazyturk · 6 September 2023 23:55

Thanks, now 20230907 Ne Omega Nightly version with alsa aml-augesound HDMI-MULTI CH PCM and Alsa AML-AUGESOUND HDMI HDMI Audio Passthrough Working