It occurs to me that I am currently connected to a 1440p monitor. Could that be an issue?
That's above Full HD, so a high speed cable could already be necessary.
It occurs to me that I am currently connected to a 1440p monitor. Could that be an issue?
That's above Full HD, so a high speed cable could already be necessary.
Does Raspberry Pi OS run in 4K mode? If not, then it could be an HDMI cable issue. Make sure it's conform to HDMI 2.0 or 2.1 standard.
Dev was answering to me. No obvious reasons found in the logs. Maybe some skeletons from an older LE installation are still biting.
Please create an USB stick with latest stable LE. Then run that stick in live mode, and try Atmos again. No user add-ons or skins.
Thanks for the info. A developer will have a look at this now.
Set the amount of output channels to "2" on LE's audio settings. Other channels will be encoded into those two then.
Is there a RAM testing tool available? Maybe this should be the first thing to run.
Debug log, or you will step in the dark forever. ![]()
There are different Pine64 hardware versions. Which LE image do you use?
Use a kernel parameter. For RPi the file for kernel parameters is /flash/cmdline.txt. Editing steps on SSH session:
Append the needed resolution as kernel parameter (syntax here). All kernel parameters have to be on the same line.
Do you also have a cmdline.txt at your Pine64 file system?
Post another log with the other PSU, and at log level 1. You're still at log level 0:
2022-04-26 10:49:16.271 T:837 INFO <general>: Disabled debug logging due to GUI setting. Level 0.
I'm using a 3.1A PSU on my RPi 3B+. The benefit of a 3A+ PSU is that you can also use it for RPi 4 (with USB-C adapter). In case you're thinking about upgrading in the future, this comes in mind. Your choice.
Hmmm, I guess it has been 5 years, too long?
If the RPi is often used, then this could be too long. The under-voltage warning is in your log, so I suggest to buy a new PSU with 3A.
How old is your PSU? After some years they can lose wattage.
gekoch Thanks for checking the HDMI cable. We definitely need a debug log (see above) to track down the issue.
Thread moved to Hardware sub-forum.
So you want to use a switch button instead of a push button. In that case you can't use dtoverlay=gpio-shutdown, and you have to implement your own script to check the GPIO states. Here is a script that does the same like dtoverlay=gpio-shutdown. Start it from autostart.sh. You have to adapt it for your needs:
#!/usr/bin/python
# This script was authored by AndrewH7 and belongs to him.
# (www.instructables.com/member/AndrewH7)
# You have permission to modify and use this script only for your own personal usage.
# You do not have permission to redistribute this script as your own work.
# Use this script at your own risk.
import sys
sys.path.append('/storage/.kodi/addons/virtual.rpi-tools/lib')
import RPi.GPIO as GPIO
import os
# Replace YOUR_CHOSEN_GPIO_NUMBER_HERE with the GPIO pin number you wish to use.
# Make sure you know which rapsberry pi revision you are using first.
# The line should look something like this e.g. "gpio_number = 7".
button_gpio_number = 3
led_gpio_number = 13
# Use BCM pin numbering (i.e. the GPIO number, not pin number).
# WARNING: this will change between Pi versions.
# Check yours first and adjust accordingly.
GPIO.setmode(GPIO.BCM)
# It's very important the pin is an input to avoid short-circuits.
# The pull-up resistor means the pin is high by default.
GPIO.setup(button_gpio_number, GPIO.IN, pull_up_down = GPIO.PUD_UP)
GPIO.setup(led_gpio_number, GPIO.OUT)
# Switch LED on.
# LED will switch off automatically at shutdown by using normal GPIO state.
GPIO.output(led_gpio_number, True)
# Use falling edge detection to see if pin is pulled low to avoid repeated polling.
# Send command to system to shutdown.
try:
GPIO.wait_for_edge(button_gpio_number, GPIO.FALLING)
os.system("shutdown -h now")
except:
pass
# Revert all GPIO pins to their normal states (i.e. input = safe).
GPIO.cleanup()
Display More