Posts by HarryH

Hi chewitt ,

thank you for the clarifying. But currenly I'm little bit confused and get a node in my head. Do you have a perhaps a link to a sketch about the different positioning of SL/SR vs. BL/BR vs. BLOC/BROC speakers please?

I'm asking because my DENON 3808 AVR reports this setup via HDMI (EDID decode) and thinking the SONY AVR of _marklam_ behaves the same :

 Speaker Allocation Data Block:
   FL/FR - Front Left/Right
   LFE1 - Low Frequency Effects 1
   FC - Front Center
   BL/BR - Back Left/Right
   BC - Back Center
   RLC/RRC - Rear Left/Right of Center (Deprecated)

This 7.1 AVR has 6 terminals for 2x Surround A + 2x optional Surround B and additional 2x Surround Back Left/Right speakers. The Surround A terminals should be used for a 5.1 setup and the speakers placed sideways or little bit behind of the main seating.

Currently I think BL/BR is mapped to Surround A + B and RLC/RRC is virtual in 5.1 mode. Because I currently haven't a 7.1 speaker setup I can only relies on the reported input signal.

In that sketch for the 7.1 speaker setup example, it looks to me
https://www.intel.com/content/dam/support/us/en/images/mini-pcs/7.1.jpg

• that BL/BR is moved to my assumed RLC/RRC position
• and SL/SR replaces my assumed BL/BR position

During my research I found this kind of adapters too: https://www.allaboutadapters.com/au-hcp2.html I'cant see a different positioning for SL/SR vs. BL/BR

I'm wonder if AESinkALSA should doing the same with LPCM 7.1 media files?

• map media SL/SR -> HDMI BL/BR channel
• map media BL/BR -> HDMI RLC /RRC channel

Being I'm totally wrong with that idea? Or does all others 7.1 receivers advertise SL/SR via HDMI additional?

EDIT:

  HiassofT Could it be that there is already an option for that, but a condition is wrong (channel replacement looks not executed)

xbmc/xbmc/cores/AudioEngine/Sinks/AESinkALSA.cpp at 7c7f08a545d6011aa05c0ece2b960452b65e3457 · xbmc/xbmc

Kodi is an award-winning free and open source home theater/media center software and entertainment hub for digital media. With its beautiful interface and…

github.com

It looks to me that the speakers that are requested not matching the speaker setup reported by your amp. The channels SL and SR are not listed by your amplifier.

2024-04-30 11:57:42.244 T:901      info <general>:     Device 4
2024-04-30 11:57:42.244 T:901      info <general>:         m_deviceName      : hdmi:CARD=vc4hdmi,DEV=0
2024-04-30 11:57:42.244 T:901      info <general>:         m_displayName     : vc4-hdmi (vc4hdmi)
2024-04-30 11:57:42.244 T:901      info <general>:         m_displayNameExtra: SNY SONY AVAMP on HDMI
2024-04-30 11:57:42.244 T:901      info <general>:         m_deviceType      : AE_DEVTYPE_HDMI
2024-04-30 11:57:42.244 T:901      info <general>:         m_channels        : FL, FR, LFE, FC, BL, BR, BC, BLOC, BROC
2024-04-30 11:57:42.244 T:901      info <general>:         m_sampleRates     : 32000,44100,48000,88200,96000,176400,192000
2024-04-30 11:57:42.244 T:901      info <general>:         m_dataFormats     : AE_FMT_RAW,AE_FMT_S24NE3,AE_FMT_S24NE4,AE_FMT_S32NE,AE_FMT_S16NE,AE_FMT_S16LE,AE_FMT_S16BE,AE_FMT_U8,AE_FMT_RAW
2024-04-30 11:57:42.244 T:901      info <general>:         m_streamTypes     : STREAM_TYPE_AC3,STREAM_TYPE_DTSHD,STREAM_TYPE_DTSHD_MA,STREAM_TYPE_DTSHD_CORE,STREAM_TYPE_DTS_1024,STREAM_TYPE_DTS_2048,STREAM_TYPE_DTS_512,STREAM_TYPE_EAC3,STREAM_TYPE_TRUEHDz

Requested by the play process:

2024-04-30 11:58:26.562 T:902     debug <general>: CAESinkALSA::GetChannelLayout - Requested Layout: FL, FR, FC, LFE, BL, BR, SL, SR
2024-04-30 11:58:26.562 T:902     debug <general>: CAESinkALSA::GetChannelLayout - Got Layout: FL, FR, LFE, FC, BL, BR, BC, UNKNOWN1 (ALSA: FL FR LFE FC RL RR RC NA)

I have seen in the manual of the amplifier, that it supports different speaker schemes. How many and which type of speakers do you have? Maybe you should ensure to set it to 3/4.1 and try it again.

Edit: Some minutes ago I have looked into my kodi.log. With my receiver I get also BLOC and BROC instead of SL/SR reported. I will test it tomorrow with that files if I come to the same result like you:

GitHub - sfiera/flac-test-files: FLAC test files for multi-channel sound systems

FLAC test files for multi-channel sound systems. Contribute to sfiera/flac-test-files development by creating an account on GitHub.

github.com

Can you please more specific?

- which RPi? 1, 2, 3, 4, 5 ?
- which LE version?

The best way to provide the needed details is to enable debug logging (Settings → System → Logging), reboot and paste here the link to the log only:
https://wiki.libreelec.tv/support/log-files

If you currently use LE 11.0.6 or earlier, please try a current nightly - because there was important changes regarding EDID data. EDID data is the source for the audio channel information and must be correct.

HiassofT ,

thank you for the additional explanation to make the current state more clear.

Regards,

Harry

Hi Lotte,

nice, that you found a solution.

If you currently doesn‘t have a dtoverlay=hifiberry … line in your config it seems that the overlay was instead loaded from the HAT EEPROM. Please keep in mind, that in future kernel versions it could be possible that this overlay in the HAT EEPROM will be outdated. Then you will need a matching dtoverlay line for your hifiberry.

Regards,

Harry

Because of this:
Configuring Linux 4.x or higher | HiFiBerry
HiFiBerry sound cards on the Pi5 | HiFiBerry
Changes in HiFiBerry drivers | HiFiBerry

you should ensure that this line is commented out:
dtparam=audio=on
to
dtparam=audio=off or #dtparam=audio=on

I had read that this command
force_eeprom_read=0
is deprecated, you should instead move this 2 lines to the very beginning of the config.txt

dtoverlay=
dtoverlay=hifiberry-dacplushd

The first line prevents it from loading the overlay out of the HAT EEPROM (hifiberry).

I know that some users with RPi5 and a Argon ONE case use successful the hifiberry driver set with their new BLSTR DAC modules. But the driver for dacplushd could have his own bugs.

Okay, this looks like a little bit different constellation. If i'm right, then the remote you using relies on the default remote profiles. Or do you have added an "rc_map.cfg" or "lircd.conf" file manually in the past to get it work?
You can check if one of these files exists in the "/storage/.config" folder.

Hint: Instead of a restore the complete configuration, in your case it would be enough to delete the rc_maps.cfg in /storage/.config. Just for completeness also delete the remaining "/storage/.config/rc_keymaps/argon40.toml".

In this case, I already had on my to-do list to find a working merge solution.

The Addon can't backup files, which are not exists during installation or after the settings menu was closed with OK.
Please be aware: The known switch object in the Addon settings menu isn't able to trigger directly an action! This could be create a gap in your idea and needs additional handling. For example if someone will change/add his own files, after the plugin was installed and is already running. Such edge cases must be taken into account.

I would prefer the way, to add the Argon IR remote to the existing list for coexistence, if that possible. But this depends on how the custom remotes were added.

Like I wrote before, the Addon (depending on the version) currently add only files to the ".config" directory like rc_maps.cfg and lircd.conf. This are 2 different ways to add a custom remote, but the resulting behavior is different.

Please can you provide more details, which file(s) you have restored, to make your remote control working again?

Quote from Reddirt

I had no idea the order in which devices were powered might be an issue. If I understand correctly the RPi5 system will record all necessary EDID info on it's 1st run and save in a permanent file for future boots?

No, it‘s not saved automatically. The command „getedit create“ is the manual process for that, and „getedit delete“ the counterpart.

Explanation:

Since some LE versions, its more important that:

1. the EDID informations are available
2. the EDID information must be correct

Normally the HDMI handshake should be initialized during boot of the RPi. This happens dynamically with every boot process. At this time it‘s important that the HDMI chain is working and not disturbed. Disturbing is possible with bad manufactured/not certified HDMI cables, Micro-HDMI adapter, other HDMI devices …

For example you should ensure, that you switch on the RPi as the last one if your cabling looks like this:
RPi5 -> AVR -> TV

The ideal sequential order to power-on is that:

1. TV (provides EDID data for screen size/frequencies + supported sound channels/formats)
2. AVR (passthrough and/or provides additional EDID data)
3. RPi5

If the AVR is powered-off, the RPi5 can‘t get the EDID information. Some newer AVRs are able to passthrough the EDID information if they are in standby. But there also exists TV, that only provide this information if the TV is switched on.

To get a more robust system against the different power-on scenarios, it‘s possible to grab the EDID data one-time and save it in to the file system with the „getedit create“ command. After that the kernel/KODI will use this saved information at the next boot instead of the dynamical available EDID information. But this implies, that this file must match to your current hardware constellation. On this way it also possible to fake some information, if the extracted EDID block is incomplete or something like that.
If you afterwards make some (conflicting to the EDID file) changes on your hardware/device firmware, then you must update or delete the EDID file again.

Quote from ApexDE

Yes, that was my first test: Fan always on. And it didn't work so i thought the addon in general doesn't work.

I wished, that such issues are reported here, and not silently switched back to an old version. Like the issue above, sometimes I detect that randomly only. And so long I believing all things are fine.

Quote

Can you built in a switch for the Argon remote and the others so it doesn't break the other remotes when installing the plugin without the lock file? I believe one should actively choose to use the Argon remote instead of the formerly used one. You could backupcopy the previously used remote files also?

It's not so easy like it sounds. In my opinion the best way would be, if a dialog were opened during the installation process if a existing configuration has been detected. But it seems that it's currently not supported by KODI for Addons, or I doesn't know the way for.

Because I wanted to force the migration to the modern way with ir-keytables, it was needed to delete the old lircd.conf, which was provided by the version < 0.0.10. Default this file doesn't exist in LE.
I don't have a statistic, which way (lircd vs. keymaps) the most users using with their own remote control configuration, and therefore I'm been unsure which files I should check to make this process bullet proof.

As a simple solution I thought about in the past, to add a switch to create/delete the lock file from menu. But this will not prevent, that your configuration will be overwritten during the first installation of the Addon. To prevent this, I must set the remote control file copy process default to off. It needs a restart of KODI to reload the remote config, as far as I know. But there are also users with the origin Argon IR remote, they need the configuration file from the Addon and may expect that the remote work out of the box, after the Addon is installed successful.

That's the conflict I'm in.

Quote from ApexDE

Why isn't the plugin in the LibreElec repository?

I doesn't have a automatic build process ready and I honestly currently don't know what's all required to make it part of a LE repo.
May be I must extent my test scenarios first, to prevent that I publish a buggy version.

For example, this week I stumbled over the regression, that in version 0.0.13 I introduced throwing of a exception with setting "Fan always on" is enabled. If this setting is set to enabled, the fan isn't running. I thought I have tested, but it seems I didn't.
Version 0.0.12a shouldn't affected by this. And as temporary workaround with version 0.0.13, you can lower the threshold to get the fan running all the time.

Such things shouldn't happend with a Addon in a official repo...

Hi ApexDE ,

like mentioned at multiple places like the change message for 0.0.10 and "Breaking change" in the middle of the post #25 .
You can prevent the Addon from overwriting your remote control settings, if you drop a empty file with the name "argon40_rc.lock" in the ".config" folder.

touch /storage/.config/argon40_rc.lock

There is a undervoltage message remaining in your logical-ape.log:

Quote

Code

Feb 16 23:40:57.414554 LibreELEC kernel: hwmon hwmon0: Undervoltage detected

Which kind of power supply do you use? Do you have a model or part number?

https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#power-supply-warnings
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#power-supply

Hi Ajay,

Maybe you just overlooked it. If you are not familiar with technical abbreviation like PSU, please ask.
Da Flex already provided the solution. If you ignore that, you shouldn’t expect additional support.

Quote

Thanks for the log. Replace your PSU

Your Pi doesn‘t get enough energy. The power supply that you currently use seems undersized or defective. That will also trigger other unexpected issues, and could be the reason for the WiFi issues too. So the only solution is to replace the power supply first.

Thank you for that useful information.

I have added the version comments to better show, if something has been changed.

It’s not impossible, but I currently doesn‘t know about changes in the images, which are related to these scripts.
If it‘s working now, I‘m happy and will not touch the scripts. Perhaps only to add some version comments and replacing the deprecated usleep command, no functional change.

For documentation purposes, please can you provide the following informations?

• config.txt
  cat /flash/config.txt
• kernel log
  dmesg | grep -i uart
• ls -la /dev/ttyAMA*
• pinctrl -p get
• Do you know which version of the RemotePi do you have? I read about, that the pcb has a current limiter to prevent damages at RPi pcb. But this can also restrict the current to much for your RPi5 and you are get in trouble, because not enough power.

Do we talk about the same thing? I meant, that I have updated the scripts inside of the 2 codeblocks in Post #17

Quote

I don’t know if it’s due to the board but when I connect the power to the board the pi5 shutdown just after start

Do you have this strange behavior only since you tried the pinctrl version? Have you updated to the current version?

The GPIO15 seems to me to be the more important signal for shutting down. It may be triggered the MCU on the RemotePi pcb before the irwitch.sh script was started. These 2 pins (GPIO14/15) are part of UART0. Depending on your bootloader/EEPROM settings and config.txt, conflicts can occur. But this conflict should also exist if you have not installed the script. Can you check without the scripts, if the shutdown also is initiated automatically?

This information would be important for me to know.