This helps like a lot, I will try to reproduce on my 3B+ instead of the 3B I use normally. That Pi is a bit different from the previous ones, so the difference might be in the Pi3B+… Will check, but it’ll take some time to investigate, don’t expect a fix this week 
(I won’t be home a lot)
Hi,
I’ve got some results with clean Volumio 2.657.
Installation consists of pydPiper plugin, ir controller plugin, gpio buttons plugin, backup& restore plugin and autostart plugin. All of them are working right after installation. I have not mount music on NAS. So all tests was done with the webradio.
After reboot I see pydPiper starting before the music begins and all is fine. Then webradio starts with music. LCD shows info about it during some seconds, and then begins to show blinking garbage. I did ‘docker ps’ and saw two containers. One running from the start and the second making garbage on display, because of two copies of pydpiper are fighting for one display.
I can stop them by ‘docker stop name’ and start again pydPiper (only one). After this it is working till next reboot.
I’ve tried to set pydPiper plugin to off in webUI. Then all is fine: plugin starts before music (why? it was set to off?) and correctly run whithout garbage on screen. ‘docker ps’ shows one running conteiner.
Good morning,
Last night I did a quick test, I still need to test on the 3B+, so that might still be problematic… but I installed everything on the Pi2B and only one docker container was up, even after rebooting. This is good, so we might have some problems for Pi3B+ models, which have slightly different hardware. As previously, I can’t make any promises in terms of time, I won’t be in a position to test till Sunday late in the afternoon; and even then I’m lacking time 
But I’m sure it’s something stupidly simple and has to do with previously being unable to test against a 3B+
Thank you,
your plugins are realy great.
I’ve stopped strugling with pydPiper plugin. It was not becouse of two simultanious copies but because it surely hanging my system right after music starts. I didn’t know what to do with it.
Instead of pydPiper I installed your hd44780 plugin with some corrections in mpdlcd.conf and display-fields.py files. It’s working not so nice as pydPiper do. But it never tried to hang the whole system.
Thank you, I’l be glad to know if you have new results with Pi3B+.
Thanks mate! 
I ran some tests this weekend, it took some time to find the culprit, but I think I found it. For some reason, the plugin was started by the system itself (autostart) AND Volumio (plugin), but this didn’t result in a restart of the already running instance and instead fired up a second one. Not sure how this problem surfaced without any notable changes.
Luckily the fix was pretty easy and I fixed something else as well.
Fix #1:
The system would only exit a container upon reboot/service restart, this resulted in many exited containers over time (I had like 50-ish). The fix was to update the unit file and add the
--rm
parameter.
You can cleanup your system by calling:
sudo docker system prune -aFix #2:
As said, the system would start one instance and Volumio the second. I updated the install script to disable the service, effectively disabling auto-start and symlink the new unit file (as per usual).
This doesn’t fix your installations of course, so I prepped some statements to fix your current installation:
sudo /etc/init.d/docker restart
systemctl disable pydpiper.service
sudo wget -O /home/volumio/pydPiper/pydPiper.py https://raw.githubusercontent.com/Saiyato/volumio-pydpiper-plugin/master/templates/pydPiper.py
wget -O /data/plugins/accessory/pydpiper/index.js https://raw.githubusercontent.com/Saiyato/volumio-pydpiper-plugin/master/index.js
wget -O /data/plugins/accessory/pydpiper/unit/pydpiper.service https://raw.githubusercontent.com/Saiyato/volumio-pydpiper-plugin/master/unit/pydpiper.service
sudo ln -fs /data/plugins/accessory/pydpiper/unit/pydpiper.service /etc/systemd/system/pydpiper.service
systemctl daemon-reload
systemctl restart volumio
Then, if you want, you can cleanup the obsolete containers with:
sudo docker system prune -aIf someone can test as well, I will create a PR for the patches
Hi, Saiyato
Very many thanks to you for your time and your thoughts to solve my problem. I wil try this fixes on weekend. Surely they will help.
Thank you and good luck
Hi, Saiyato
I tried and it works. All is right, only one instance of pydPiper is running.
Thank you, your code is usefull.
Now I face the next problem. All is fine when working with small database. And when I have big database installed Volumio with pydPiper crashes during reboot. In this case “small” is about 300 artists, 2500 songs and “big” is more than 13000 artists and 190000 songs.
Only pydPiper lead Volumio to crash down, cause it run with any other set of plugins. Of course HD44780-plugin is running.
Do not know what is the next step to manage pydPiper.
Thank you, and many thanks if you have any new ideas.
Hi,
I don’t think my database is that big, I should check, but iirc I’m at around 22k songs. My guess is that Volumio (or NodeJS) needs resources to boot up and pydPiper is quite cpu hungry (python will be very high when requesting “top”).
I can’t really influence that behaviour, so my best guess would be to delay the plugin, not sure if the systems allows for delayed startup of plugins. I could simply add a delay to the unit file, but this would also apply if you restart the service; then again… how often do you need to restart the service and will it be really disruptive?
Can you benchmark how long it takes to boot up with your 190k songs as opposed to 2500 songs? I can benchmark my boot time and maybe extrapolate the multiplier. All without plugins enabled of course
Of course, I prefer not to restart it at all. But sometimes it happens and if it was with pydPiper - then I need to rise Volumio from backup. It is not so nice if I have to wait long time to scan NAS.
Now it’s running with hd44780 plugin. More then a week, I think.
Thank you, I will try again for further experience.
P.S. It takes about 14 minutes to boot. Sometimes - between 12 and 16. Everybody want to know, why so long and what is the need of checking the whole base.
That’s quite the boot time! I was expecting more like 5-6 minutes, anyways, I will see if I can allot some time to implement a start delay and test it. Testing will take time I’m afraid
Thank you, it would be great. I saw the peace of code that lights LED when Volumio is ready. I think it will be usefull to start pydPiper instead of LED. Here it is turn-led-when-volumio-ready-t5746.html
Thank you again
Hello Saiyato
I have been using your pydpiper plugin for a while now with a 20x4 lcd screen and most of the time it works fine but lately it would only show the time but incorrectly and not updating it, set on say 4.15 eg. I have uninstalled it and reinstalled but it only shows version 1.4.3 of the software now instead of a later version, number unknown.
Whenever I try to ‘save’ any of the settings there is a Red Error box that states that restarting pydpiper failed.
I followed your Fix 2 and prune -a.
After the reinstall the lcd is blank totally now no time nothing, any suggestions?
Is there an updated version of the software and easy instructions on how to install on RPi 3b+
I have 2 volumio setups on identical boards but the other is version 1.3.5 and works fine.
I have just noticed that in your templates folder there is nothing for pages_lcd_20x4.py only 16x2.
Update, I have got the whole thing working again, I changed the page file setting to pydPiper.py to see if the screen was still working and it did with a scrambled scene, then changed it back to the 20x4.py and the time came up but it only changes every 5 minutes from the time of starting [is that normal] and then the music information was fine too. So for now it is working, thanks if that helps.
Hi,
What interface are you using for the 20x4, is that I2C? It’s true that I didn’t make a template for the 20x4; just the 16x2.
I have an 20x4 screen lying around, but never used it, it’s I2C though.
Please let me know.
Cheers
Yes it is I2c. 20x4
When it works it is great it just doesnt do it as consistently as it probably could, I live with it and go yay when it works and look away when it doesnt , not a big issue. Is the clock only moving in 5 minute blocks a thing that is easier, that is annoying when you actually want the time to be accurate. Is it code that needs to be modified?
thanks for the great effort to get hings to this stage
Please help configuring the 1602A monitor. I have tried many times but failed. Hope you help.
Thank you very much.
It always displays like this
The address of LCD cannot be found
Mrhung751
hi it isnt always the most obvious.
in the first photo you show that you have i2c ‘enabled’ in my setup i have that ‘off’ and the display works. try it you may be pleasently surprised.
It doesnt make sense i know but if you have parallel enabled it disables i2c which is what you are using. have a look at your pages file. mine is pages_lcd_20x4.py as yours is a 16x2 it would probably be the default pages_lcd_16x2.py. And i havent used the GPIO plugin and havent had to allocate a pin number like you have.
good luck and let me know if this helps or not, i have had some questions on here for months without a response, I know it isnt guaranteed just disheartening.
Hi there,
As Rosco says, you have an I2C type of display
Let us know if that works for you
Cheers