Very strange! I have no idea what could be causing this. 
Maybe something has changed in the upgrade. Was it working before the upgrade?
I noticed this at the end of July after an update, I don’t remember it happening before.
I wanted to check it by reinstalling Volumio in version 3.703, but during system installation the update to 3.742 is forced during the first steps of the initial configuration.
I don’t currently have an older version of Volumio running.
If you use the previous version of the MPD-OLED plugin, it works without any problems.
Can you try one of the previous versions of the mpd_oled plugin?
The only thing changed was some ALSA configuration changes as suggested by @balbuze I don’t know why this would cause issues 24bit playback 
It seems canva works only with 16b datas.
Try this:
modify /data/plugins/system_hardware/mpd_oled/asound/volumioalsa.postalsa.5.conf
and replace the content by (copy paste)
pcm.volumioalsa {
type plug
slave.pcm {
type multi
slaves {
a { channels 2 pcm "postalsa" }
b { channels 2 pcm "mpdoledfifoi" }
}
bindings {
0 { slave a channel 0 }
1 { slave a channel 1 }
2 { slave b channel 0 }
3 { slave b channel 1 }
}
}
ttable [
[ 1 0 1 0 ] # left -> a.left, b.left
[ 0 1 0 1 ] # right -> a.right, b.right
]
}
pcm.mpdoledfifoi { #convert in 16b)
type plug
slave {
format "S16_LE"
rate 44100
channels 2
pcm "mpdoledfifo"
}
}
pcm.mpdoledfifo {
type volumiofifo
fifo "/tmp/mpdoledfifo"
}
disable enable the plugin.
let me know 
Edit : works with softvol! (not sure…)
2 Likes
I installedand and tried version 1.1.2 again,
and it works fine here.
if you want to test this
modify /data/plugins/system_hardware/mpd_oled/asound/volumioalsa.postalsa.5.conf with
pcm.volumioalsa {
type plug
slave.pcm {
type multi
slaves {
a { channels 2 pcm "postalsa" }
b { channels 2 pcm "mpdoledfifo" }
}
bindings {
0 { slave a channel 0 }
1 { slave a channel 1 }
2 { slave b channel 0 }
3 { slave b channel 1 }
}
}
ttable [
[ 1 0 1 0 ] # left -> a.left, b.left
[ 0 1 0 1 ] # right -> a.right, b.right
]
}
pcm.mpdoledfifo {
type volumiofifo
fifo "/tmp/mpdoledfifo"
format_3 "S16_LE"
}
Hello!
After updating the mpd-oled plugin to version 1.1.3, I also had the strange display of the spectrogram bars for audio data in 24 bit and 96 kHz described by “rak39”.
My Ian Canada streamer based on a Raspberry Pi 4 is equipped with a MonitorPi Pro (integrated control center and signal analyzer). It has a built-in signal analyzer (hardware, not Raspberry software) and recognizes the digital audio format and the I2S/DSD signal status in real time and shows the real music information on its OLED display. In the photos it is the display on the right with the rotary control.
Next to it I have installed a 1.3 inch SPI OLED display with the MPD OLED plugin. In the photos it is the display on the left with the blue housing.
I have now tested the 2 solutions suggested by “balbuze” for plugin version 1.1.3 and a downgrade to plugin version 1.1.2.
1. Initial situation with plugin version 1.1.3
The displays of MonitorPi Pro and SPI-OLED see photo. The streamer/DAC is still a test setup, the front panel and rear panel are still missing. Technically everything is fully functional though.
The display of the bars of the spectrogram is strange as described by “rak39”. There are no significant swings in the bass and mids, only something is happening in the treble. In general the bars hardly move.
MonitorPi Pro shows a correct audio output in 24 bits in the 32-bit container in 96 kHz and a clock rate of around 1000 (bottom left in the display). The bit rate shown in the SPI display is typical for an audio file in 24 bits and 96 kHz. The audio output is unchanged in high-res format.
2. Plugin version 1.1.3 with solution 1 from “balbuze” (post 906)
Everything works perfectly. Many thanks to “balbuze”! 
Picture 2 see following post.
The bars of the spectrogram are displayed correctly even for audio files in 24 bit and 96 kHz and move as usual.
MonitorPi Pro shows a correct audio output in 24 bit in the 32-bit container in 96 kHz and a clock rate of 925 (bottom left in the display). The bit rate shown in the SPI display (3111) is typical for an audio file in 24 bit and 96 kHz. Excellent, the audio output is unchanged in high-res format. That’s how it should be.
3. Plugin version 1.1.3 with solution 2 from “balbuze” (post 908)
Picture 3 see following post.
The bars of the spectrogram are also displayed correctly for audio files in 24 bit and 96 kHz and move as usual.
The SPI display shows a bit rate of 2815, which is typical for an audio file with 24 bit and 96 kHz. MonitorPi Pro also shows a sampling frequency of 96 kHz, but a bit rate of only 16 bits. The clock frequency of 641 kHz (bottom left in the MonitorPi display) is significantly lower than with a bit rate of 24 bits (in the 32 bit container). Unfortunately, the audio output is downsampled from 24 bits to 16 bits.
4. Downgrade to plugin version 1.1.2
Picture 4 see following post.
The bars of the spectrogram are displayed correctly. The SPI display shows a bit rate of 3022, which is typical for a 24-bit, 96 kHz audio file. MonitorPi Pro shows a sampling frequency of 96 kHz, but a bit rate of only 16 bits. The clock frequency of 683 kHz (bottom left in the MonitorPi display) is significantly lower than with a 24-bit bit rate (in the 32-bit container). Unfortunately, the audio output is downsampled from 24 bits to 16 bits.
I wrote this text in German and automatically translated it into English using Google. I hope that you can still understand my tests and their results.
hello!
Thanks for a such detailed tests!
Very interesting!
So sol 2 works for you, fine.
Problem, it doesn’t work in some case with software volume and or FusionDsp.
I have to rework…
home made DAC?
Hi guys, Ok I have the same issue on my WEB Radio streamer with the Display and the strange bar graphs in spectrum analyzer. Will wait until Balbuze is ready with coding. If You need support in testing please let me know
Mpdoled works great, but… If I stop playing for about 1 hour - the bars stop responding. I have to disable and enable the plugin again.
Hi there!
I recently had to reinstall my setup and reinstalled the non-plugin version of MPD OLED (because of alsa issue) with a new 2.42 display from DIYMORE.
Everything works fine from the start but after playing a couple of tracks the following happens:
The image seems to shift upwards a couple of lines and what’s cut off appears at the bottom again. It stays like this for a couple of tracks (bars, clocks etc. still moving correctly) and then it happens again and moves even further up:
I could verify this with two different 2.42 OLEDs, the newone from DIYMORE and the previous one from AZDelivery. Both are connected via I2C with a voltage converter to 3.3V and reset pin connected. Config is following:
sudo mpd_oled_service_edit -o 3 -a 3c -r 4 -b 13 -g 1 -f 25
Setup:
Raspberry Pi 3B
Allo Piano 2.1
Volumio 3.785
Does anyone know this issue and how to fix it?
Thanks for any help!
Kevin
Hi Kevin
There were very rare reports of this issue from the beginning, and I was finally able to include a fix for it in 2021. This was confirmed as working, and I haven’t seen any further reports until yours!
This is the issue thread
Display flicker and frame size issue · Issue #3 · antiprism/mpd_oled · GitHub
The vertical offset should be reset every time the screen is updated, but the command appears to be having no effect on your displays, because they are remaining offset.
What instructions did you follow to install mpd_oled? Specifically, which copy of mpd_oled did you install?
Adrian.
Hi Adrian,
Thanks for looking at this!
I used the following instructions from the GitHub page for the binary package for Volumio 3:
wget -N http://pitastic.com/mpd_oled/packages/mpd_oled_volumio_install_latest.sh
sudo bash mpd_oled_volumio_install_latest.sh
sudo mpd_oled_volumio_mpd_conf_install
Did I accidentally pull an older version with this?
Thanks!
Hi Kevin
You have installed the latest version of mpd_oled, so it is a current issue.
I have reviewed my fix against the SSD1309 datasheet, and I am unsure whether the command I used sets the vertical offset to line zero, or whether it adds zero lines to the current offset, meaning that it might do nothing (although it appeared to fix the issue)!
I stopped developing mpd_oled a while ago and am only doing minimal easy maintenance now, so I am unlikely to provide a new fix for this.
I recommend trying some of things I mentioned in the issue thread I linked to. Try reducing the frame rate, the baud rate, maybe replace the data wires, you could also try not using the reset wire.
Adrian.
Hi Adrian,
Thanks for those hints! I tried those, could not achieve any improvement though. Even with low fps and baud rate it might even happen just during the first track. Same without reset pin. Data wires are good after measuring those.
Thanks though!
Kevin
Hi Kevin
Thanks for the feedback. It is a shame that nothing helped. I’ll research the situation a bit more in case this is something I could fix in code.
Adrian.
1 Like