ErinBong

Hey! i had similar issues with the ES8388 analog and HDMI output path alignment on my OPi5 Plus under recent edge/mainline kernels. Sometimes the card states look fine in ALSA/pavucontrol but the streams just don't bridge to the hardware mapping properly, or the default audio levels are hitting gain issues. To test if it’s just a software-side compression or file amplification issue before diving too deep into modifying the device tree (.dts), try running a quick format check with a known sample using explicit routing- aplay -D plughw:1,0 your_audio.wav If your test files are inherently too quiet or failing to hit the threshold cleanly, you can boost them up beforehand via tools like MP3Louder just to make sure you aren't fighting low baseline source levels on top of the kernel driver bugs. If it completely stays dead silent even with clean, forced audio files, then it's definitely the device tree overlay parameters (simple-audio-card) not toggling correctly on your specific build version. Which image build date and kernel version are you currently on?

I'd start by checking whether the issue showed up right after an apt upgrade or after updating OMV itself. I've had cases where reinstalling the OMV packages and checking the service logs made it much easier to pinpoint what actually broke. Posting the output of the relevant logs would also help others narrow it down instead of guessing.

If you're just looking for a simple backup solution, I've had good results with creating a full image of the SD card/eMMC before making major changes. It's easy to restore if something goes wrong. For regular backups, syncing just your important configs and data is usually a lot faster than backing up the entire system every time.

I'd also check that the RDP service is actually running and listening on the expected port. If SSH still works, you can verify the service status and firewall rules from there. That usually helps narrow down whether it's an RDP configuration issue or a network problem.

One thing that helped me in a similar situation was checking that the running kernel version matched the headers exactly with uname -r. A mismatch there can be really confusing. If you've recently upgraded the kernel, a reboot before installing the headers is worth trying too.

I usually make a quick backup before running bigger updates, especially on systems that are already working well. It also helps to reboot after the update and check armbianmonitor -u if anything seems off afterward. That can provide useful information if you need to troubleshoot.

If Windows can see the share but has trouble connecting, it's also worth checking the SMB version being used on both sides. I've run into cases where enabling the correct SMB protocol or recreating the saved Windows credentials fixed the issue right away.