bazzle
19 July 2023 21:03
2249
Latest nighty 20231706 ng working perfectly on 2 boxes. One is an H96x2 , 2nd is X96x3.
Is new 20.3 nightly on Amlogic-ne incorporating the back port for DV support?
Where to download amlogic-ng-dv 20.3?
vpeter
28 July 2023 17:19
2252
Nowhere. Release will be available with stable 20.3 release.
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?
Omega 20230904 nightly version Bluetooth does not work.
Device Gt King ii
ctyrka
5 September 2023 08:14
2256
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.
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
2258
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:~ #
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
2260
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
2261
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
2262
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
2263
I am happy box is working, so I guess I rather be patient and wait on 20230905 until the next nightly build. : )
1 Like
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
Is the same problem on other platforms?
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
It’s broken because of this PR:
xbmc:master
← thexai:sink-names
opened 11:34AM - 22 Aug 23 UTC
## 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.
2 Likes
joco
6 September 2023 19:14
2268
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.