This looks not right to me, you should add this line:
BOOT_ORDER=0xf14
QuoteTry USB first, followed by SD then repeat
To edit the EEPROM/bootloader config:
rpi-eeprom-config -e
This looks not right to me, you should add this line:
BOOT_ORDER=0xf14
QuoteTry USB first, followed by SD then repeat
To edit the EEPROM/bootloader config:
rpi-eeprom-config -e
Sorry no idea, how do I check?
vcgencmd bootloader_config reads out the EEPROM. The line should looking like BOOT_ORDER=0xf14 or something like that and defines the devices that will be checked for a valid boot partition - beginning from the right !
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
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?
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)
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:
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
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?
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:
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:
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.
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.
QuoteCan 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.
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
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.
QuoteThanks 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?