quackmore

thank you I ordered a HMDI to VGA adapter that has an audio jack output too but I'll keep your suggestion as a backup solution

Thanks, I think I'm gonna use an external adapter too

the jack audio on my Orange Pi 3 LTS is very noisy... my setup description below anyone having the same issue and fixed it? or anyone that went with a USB audio adapter or a HDMI adapter? thanks for sharing ___________________ this is my setup ORANGE PI 3 LTS headless Linux 6.1.53-current-sunxi64 #1 SMP Wed Sep 13 07:43:05 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux Distributor ID: Ubuntu Description: Ubuntu 22.04.3 LTS Release: 22.04 Codename: jammy I'm using alsa and everything plays fine when using bluetooth **** List of PLAYBACK Hardware Devices **** card 0: ac200audio [ac200-audio], device 0: 508f000.i2s-ac200-dai ac200-dai-0 [508f000.i2s-ac200-dai ac200-dai-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: sun9ihdmi [sun9i-hdmi], device 0: SUN9I-HDMI PCM i2s-hifi-0 [SUN9I-HDMI PCM i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 Using alsamixer I muted all the inputs and the input boost for card 0 further details from mplayer output... mplayer -ao alsa someSong.mp3 MPlayer 1.4 (Debian), built with gcc-11 (C) 2000-2019 MPlayer Team Playing someSong.mp3. libavformat version 58.76.100 (external) Audio only file format detected. Clip info: ... ========================================================================== Opening audio decoder: [mpg123] MPEG 1.0/2.0/2.5 layers I, II, III AUDIO: 44100 Hz, 2 ch, s16le, 192.0 kbit/13.61% (ratio: 24000->176400) Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers I, II, III) ========================================================================== AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample) Video: no video Starting playback...

your logs say: Dec 07 23:16 : server_socket: bind to '[::1]:6600' failed (continuing anyway, because binding to '127.0.0.1:6600' succeeded)... it looks like binding to an IPv4 address actually works while binding to an IPv6 address fails but it's not a fatal event... I'd rather check your mpd config, and maybe open a specific thread for that if you still wanna try another way to disable IPv6, try googling "Using GRUB to disable IPv6 on Ubuntu"

Where it get that "0" then? It's network manager... Don't manually modify sysctl.conf Just follow instructions Here to change the connection for device wlan0

don't think its armbian fault, networking comes from debian (and ubuntu) there are a lot of guides on the internet suggesting you to modify sysctl.conf, but I read about problems, for instance if network manager is already managing your interfaces... you can check discrepancies using: sudo sysctl --all | grep disable_ipv6 you might find something like this ... net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.eth0.disable_ipv6 = 0 ... showing that IPv6 is not disabled on a specific interface... the following guide provides some other options and add more on the sysctl.conf one (which I wouldn't recommend anyway) https://pimylifeup.com/ubuntu-disable-ipv6/ but I'd still prefer to disable IPv6 on the single interface using network manager, as described here disabling IPv6 for a specific connection

or give nmcli a try https://www.baeldung.com/linux/network-manager or using nmtui you can check you connection and verify that the option 'ignore-auto-dns' is not checked https://linuxhint.com/network-configuration-debian/

I've installed Armbian 22.08 Jammy (CLI only) on a Orange Pi 3 LTS and it works like a charm but, apparently installing postgresql breaks logrotate.service... actually on reboot syslog shows the following: ... armbian-ramlog[2065]: /usr/lib/armbian/armbian-ramlog: line 153: /var/log/./postgresql/postgresql-14-main.log: Permission denied ... systemd[1]: logrotate.service: Control process exited, code=exited, status=1/FAILURE ... systemd[1]: logrotate.service: Failed with result 'exit-code'. ... systemd[1]: Failed to start Rotate log files. some things I found out after a shallow research: postgresql package post installation script manages the log files access permissions slightly differently from other packages, assigning ownership to root:postgres instead that root:adm. I mean this is what you get after postresql installation: ls -al /var/log ... drwxr-xr-x 2 root adm 4096 Nov 16 16:58 nginx drwxr-xr-x 2 root root 4096 Mar 22 2022 openvpn drwxrwxr-t 2 root postgres 4096 Nov 17 18:20 postgresql ... changing postgresql log files access permissions to root:amd fixes the problem and makes logrotate.service run fine after a SBC reboot the postgresql file access permissions are restored to root:postgres (weird!!! is this because it's zram?) I currently fixed the problem running a crontab script at reboot that sets the 'proper' access permissions and restart the logrotate.service, but I'm confident there must be a cleaner solution... Anyone?