Problem after power cut

[Duzeper]

I have had PictureFrame2020 running successfully and, pretty much non-stop, for nearly 2 years now (my word, doesn't time fly), but a problem has developed after a power cut.
I have rebooted the Pi and restarted PictureFrame 2020 and its start/stop timers and everything is working fine except that, at seemingly random times (I have not discerned any pattern to the occurrences) the next slide will not display - the display goes to a blank screen. Then, once again apparently randomly, slides will display normally.
This is clearly a display issue as if, using MQTT, I select 'Next Slide' or 'Previous Slide', then it will display normally. Also 'Text Refresh' will display the slide properly. In addition, text (Filename, Date etc) displays normally, and correctly, even when the slide does not. Clearly, therefore, PictureFrame2020 thinks it is displaying the slide correctly.

As I said, up until the power cut which, by the way, occurred during the night when PictureFrame2020 was not running, it was working perfectly.

Any ideas?

Martin Dashper

[paddywwoof]

Hi, it does sound odd. Powering off without a proper system shutdown is supposed to potentially cause some kind of damage in the file system (or something OS related) but I've not experienced it. Occasional blank pictures was one symptom of pictures being too large so maybe there's been a corruption of something keeping track of memory capacity???I will have a Google later but the only thing I would suggest trying is to make a new SD card with a fresh OS and copy the app and images onto that and see if the problem persists.PaddyOn 26 Nov 2022 00:52, Duzeper ***@***.***> wrote: I have had PictureFrame2020 running successfully and, pretty much non-stop, for nearly 2 years now (my word, doesn't time fly), but a problem has developed after a power cut. I have rebooted the Pi and restarted PictureFrame 2020 and its start/stop timers and everything is working fine except that, at seemingly random times (I have not discerned any pattern to the occurrences) the next slide will not display - the display goes to a blank screen. Then, once again apparently randomly, slides will display normally. This is clearly a display issue as if, using MQTT, I select 'Next Slide' or 'Previous Slide', then it will display normally. Also 'Text Refresh' will display the slide properly. In addition, text (Filename, Date etc) displays normally, and correctly, even when the slide does not. Clearly, therefore, PictureFrame2020 thinks it is displaying the slide correctly. As I said, up until the power cut which, by the way, occurred during the night when PictureFrame2020 was not running, it was working perfectly. Any ideas? Martin Dashper —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Duzeper]

Thanks Paddy. I was not sure if this thread was still being monitored.
I note that I am running Pi OS V10 (Buster) but I see that there is a V11 (Bullseye) and I wonder if I should install the latest version anyway with:

sudo apt update
sudo apt full-upgrade

Is that correct and would that throw up any other issues?

PS
I might try to install the Pi OS in a virtual machine on my Windows PC in order to try out PicFrame.

[Duzeper]

A quick update. This morning the text display is not working properly. The grey text bar appears but the date or filename shows a black bar with no text.

[paddywwoof]

On the RPi there has been a bit of a divergence with the move to bullseye and the use of the old (bcm) graphics drivers. i.e. the newer OS doesn't support them. The replacements are better in some respects but sometimes slower. If you look at the discussions here and here you will see various ideas about how to make bullseye work better. It depends very much on the power of the RPi you are using.

I would be interested to hear how you get on with pi3d in a virtual machine on windows. That's on my list of things to check now that, as I understand it, WSL has graphics capabilities.

[Duzeper]

I cannot find the original detailed instructions for installing Pi3D and PictureFrame2020. Can you remind me where to find them

Martin

[Duzeper]

A quick update. I have replaced the image files on the Pi with the originals and that, so far, seems to have fixed the issue.
Clearly, a long term test is required, but so far, so good.

I would still like to download the PictureFrame2020 instructions again but the link I have now points to PicFrame instructions.

Martin

[paddywwoof]

Martin, Yes Wolfgang migrated to picframe as we had tweaked the code so much with various enhancements!

I will set up a new SD for one of my RPis here and check what needs to be done. But essentially I think:

1. setup OS as per normal instructions on raspberrypi.com, https://pi3d.github.io/html/ and the links above for bullseye.
2. python3 -m pip install pi3d for pi3d (on WSL or linux on laptop you probably need to sudo git install mesa-utils-extra)
3. Either clone the whole github.com/pi3d/pi3d_demos repo or just right click and save the four PictureFrame2020....py files into an appropriate directory (for instance /home/pi/ if this setup is only to run the picture frame). If you don't clone the whole demo repo you will need to also save the font from pi3d_demos/fonts/NotoSans-Regular.ttf and shader from pi3d_demos/shaders/blend_new then change the relevant lines in the PictureFrame2020config.py file
4. If you're going to use geo info you need to install geopy and there might be other dependencies
5. put all your pictures into another directory (for instance /home/pi/Pictures)
6. edit /home/pi/PictureFrame2020config.py so the appropriate paths point to the right places (pictures, font, shader, missing img and geo chache txt file.
7. make sure it runs ok from the command line python3 PictureFrame2020.py and when it does set up systemd to run it as a service from scratch see https://github.com/helgeerbe/picframe/wiki/Running%20As%20Service

As I say, I haven't done this for a while so there might be errors and omissions - I will check back later!

Paddy

[rec]

Wow! Did you keep the original files? It would be fascinating to take a look at them, perhaps.

…

On Sat, Nov 26, 2022 at 5:07 PM Duzeper ***@***.***> wrote: A quick update. I have replaced the image files on the Pi with the originals and that, so far, seems to have fixed the issue. Clearly, a long term test is required, but so far, so good. I would still like to download the PictureFrame2020 instructions again but the link I have now points to PicFrame instructions. Martin — Reply to this email directly, view it on GitHub <#66 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB53MTAO5ZOP3ZGM5NHXPLWKIYVTANCNFSM6AAAAAASLWZFFE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- /t PGP Key: ***@***.*** *https://tom.ritchford.com <https://tom.ritchford.com>* *https://tom.swirly.com <https://tom.swirly.com>*

[Duzeper]

I'm afraid not. I just overwrote the files on the Pi.
I think, however, that I was a bit premature. Although it had been working properly all day yesterday since I restored the image files (after starting the frame manually), when the frame started this morning it was back to not displaying images. I have now stopped the frame and restarted it manually and it is back to working properly (so far, at least).

I am using a frameOn.service, frameOn.timer and a frameOff.service, frameOff.timer, all of which ahd been working continuously for the last 2 years. It would seem that the powercut has caused an issue with one or more of these or, I suspect more likely, the system behind these processes (forgive my clunky terminology which will confirm that I am not a Linux person, so pretty much everything I learned 2 years ago I am having to relearn)
Anyway, I will need to do some more testing by resetting the times in the timers and rerunning them to confirm this.

I believe it is possible to do an OS update in situ, but, assuming there is a 'system' problem, is there also a 'repair' option?

Martin

PS. I have successfully installed 32bit & 64bit Buster in VirtualBox on my PC, but I would like to try and get PictureFrame2020 working again before I have a go at a virtual picFrame.
By the way, I have installed Buster, as Wolfgang seems to suggest that Bulldog may not be suitable for picFrame.
Also since I am running a Pi3B+, am I right in assuming that the 32bit OS is the correct one for me?

[paddywwoof]

Martin, I have just now followed @tomasedoff instructions https://gist.github.com/thomasedoff/3973846101da1e7496524be075f1c02f pretty much exactly but instead of pip installing picframe, just installed pi3d and git cloned pi3d_demos. Transitions ran very slowly but after going into raspi-config and switching on advanced options -> glamor it seemed fine. Ctrl-C didn't stop it (I was running it with keyboard and mouse) so you need to be able to SSH in and kill the process while you test it. I will try putting the SD card into an old RPi and see what it looks like.

I'm not sure what caused your bug but it might be something corrupted on the SD card so it would make sense to try another.

[Duzeper]

Paddy
OK, I have installed a clone I made (on a different SD card), which, unfortunately was slightly earlier than when I got all the MQTT stuff working properly. I have copied over the working PictureFrame2020.py, PictureFrame2020config.py and PictureFrame2020geo.pyand it now seems to be working properly. I have, however, noticed that there is a TextBlock.py file that also needs updating,but I cannot FTP the file, I presume 'cos of a permissions issue.
Can you remind me how to install this file. I almost certain it was you who told me how in the first place.

Martin

[Duzeper]

Paddy
I have a 'useful.txt' file containing what I thought might be some (believe it or not!) useful commands, and in it is:

'sudo pip3 install pi3d --upgrade'

Is this what I am looking for to update TextBlock.py?

Since I do not know what that file does, I am not sure if is causing an issue that I haven't yet spotted. Otherwise it all now seems to be working OK

Martin

[paddywwoof]

Martin, sorry to not reply before, I'm away from home and can't check stuff so easily. The TextBlock.py file is part of the 'standard' pi3d so that would normally live in wherever pi3d is installed, inside the pi3d/util directory. So updating pi3d to the latest using pip upgrade should fix that in theory. There were some fixes 18 months ago so maybe you had a version in your PictureFrame2020.py folder to 'trick' the module loading!!

For picframe we moved from the TextBlock system using OpenGL point rendering because a) the fast text changing ability wasn't needed b) it was useful to be able to draw any character in the available font (i.e. thousands of unicode characters used in place names of the geopy system).

Keep an eye on your system and shout out if you have any other problems.

Paddy

[Duzeper]

Thanks Paddy. I just wanted to check before I update and create a new updated clone. Fortunately the previous clone was not way out of date and everything seems to be back to normal.
I would really like to try out picFrame and, if I could actually buy another RPi, I certainly would. In the meantime I'll have a go on the virtual machine, though it's never quite the same is it.

Thanks for your help.
Martin

[Duzeper]

Sorry, one more, general, question.
If I want to update my system, do I need to run both:

sudo apt update & sudo apt upgrade

In other words, does upgrade just upgrade my current OS (buster) or will it upgrade to the next version (bullseye), which I do not want to do?

Martin