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 -a
Fix #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:
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.
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
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.
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.
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
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.
[/spoiler]