Slideshow aborts

[mnew]

Hello, happy new year.

My apologies if this is not the right place for questions and discussion. I'm experiencing a consistent problem where PicFrame runs and shows "some" images, sometime two, sometimes 10, and then it quits. Connecting via SSH I see a message "xinit: connection to X server lost". Most times the SSH session remains intact, but sometimes the connection is lost, and sometimes the samba connection is lost as well and not recoverable until a hard reboot of the rbpi

I'm using a raspberry pi 4B 1Gb, using the most recent instructions on thedigitalpictureframe. I'm driving a dell 24" 4k monitor via HDMI. Most of the images are cropped to 3840x2160, but even those that are 3840x2160 seem to display ok sometimes.

I've tried the different log modes to see if I can find any clues why X server quits but haven't found a mode that reports the image being processed, or other errors that might cause X server to abort. PicFrame configured with INFO seems to show the most information. Are there other ways to test what is causing X server to shutdown?

A second symptom (or separate issue?) is that most times I get one or more of the following messages "WARNING:image_cache.ImageCache:Image '/home/pi/Pictures/<image_name>.jpg' does not exists or is inaccessible" at some point after starting PicFrame. In this case the image(s) exist and are rendered sometimes. I haven't been able to figure out a rhyme or reason for this.

When it works, my family is very excited about the slideshow, and i'm pretty motivated to figure out how to get this working. Any pointers appreciated, keeping in mind that I'm not very experienced with linux.

Thank you!
Mark

[sapnho]

From my experience, somewhat inexplicable errors with the Raspberry Pi often have two reasons: Power supply and SD card. I have spent hours trying to fix a problem that was solved simply by replacing the power supply or using a fresh SD card.

[mnew]

I've now tried a two a power supplies and a few new, fast SD cards without success. The most recent power supply is a new CanaKit 5.1v 3.5a power supply. While the new cards are nice to work with, the stability issue persists.

[helgeerbe]

Hi, actual it's hard to tell what the root cause of you problems is. But I agree with @sapnho.

Picframe is caching the image list. When it is time to show the image it is going to read the image from the sd card. If the image is not accessible for any reason (e. g. image was deleted manually) you will get the warning.

If I understand it correctly. The image wehre you get the warning from is later on accessible?! That looks like a classic low power situation. What kind of power supply do you have? If I remember right you need at least a current of 3A.

[mnew]

Thank you both for the suggestions. I appreciate the help.

@sapnho, I was using an older Class10 32g San Disk Ultra. I picked-up some new 64gb U3 class cards yesterday. Booting and writing to the cards seems much faster but I still encounter the same core issue, PicFrame stops running after one or more images.

@helgeerbe, Yes, the image I get a warning on is later readable. I test this by essentially forcing the display each of each image. I did this by turning shuffle to False, stopping the PicFrame, removing the displayed images from the /Pictures directory, leaving skipped images, then restarting PicFrame.

I'm currently using a lightly used Official Raspberry Pi ps. 5v 3a. Following your suggestion, I have tried what I think is a quality ps that is also rated to 5v 3a. Using this second power supply has not improved the stability either.

Some other findings..
Currently, almost without fail, the first image is displayed without issue, but at the end of its time the screen fades to black and the second image is shown, only a black screen, usually with the name displayed a few seconds as expected.
When connected to a 1080 monitor, PicFrame seems to run without issue.

Is my Rspi 4B 1gb underpowered for 4k images? I've been checking the temp using
/usr/bin/vcgencmd measure_temp
and the highest value I've seen so far is 48C which seems in the normal expected range. I've attached a screenshot of my terminal after running the "top" command. It too looks normal to my novice eye.

Perhaps my Rspi is flawed in some way? If I could buy a new one at a reasonable price I would, but it looks like I'll have to wait for the supply to reestablished.

I'll continue to look for another quality power supply to try. I don't think a different or faster micro SD card would make a difference, but if you think that path has further merit, I'm certainly game. In the mean time, I modified the picframe.service, enabling Restart=always so it keeps restarting PicFrame until the computer stops responding (no SAMBA presence, no response via ssh) all together.

i'm open to other ideas or further suggestions.

Thank you and kind regards.

[paddywwoof]

Sometimes odd behaviour has been seen with memory issues. Could you check the image sizes, maybe make a batch of smaller and larger images to see if there's a difference? The OpenGL code is all a bit unsafe! That's probably par for the course with low level C.

Presume the GPU portion of memory is set up OK.

[mnew]

Thank you for the suggestion. By different sizes, to you mean different pixel dimensions or other parameters that impact size such as jpg quality? The GPU memory is currently at 512mb. On Jan 11, 2023, at 1:24 PM, paddywwoof ***@***.***> wrote: Sometimes odd behaviour has been seen with memory issues. Could you check the image sizes, maybe make a batch of smaller and larger images to see if there's a difference? The OpenGL code is all a bit unsafe! That's probably par for the course with low level C. Presume the GPU portion of memory is set up OK. — Reply to this email directly, view it on GitHub <#306 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADHIXOSIAMJ2PPEX7UXDS3WR4QHJANCNFSM6AAAAAATUZSGOA>. You are receiving this because you authored the thread.

[paddywwoof]

Essentially pixel dimensions, so total GPU array size. It cropped a while ago and I think there are now checks to make sure that the Python Image Library resizes anything too large, but you never know! 512MB should be safe.

[paddywwoof]

When there was an intermittent problem before it was hard to spot but I think it was down to the fact that there are two images loaded to give a fade effect. So the problem only happened when certain combinations coincided that used up more space than usual.

It would be annoying to have to resize images down when the display has all those pixels.

[mnew]

Resizing images to 1920x1080 seems to be stable so far. It is a loss of potential wow factor but it's nice to have it up and running without constantly fiddling.
Is this is indeed the stability I've been looking for, does this point to a limitation of the raspberrypi 4b 1G?

[mnew]

After trying new SD card, new power supplies, and changing resolution, it seems that resolution is the best way to keep PicFrame running and, I think, X server from crashing. Exporting at "HD" aka 1280x720, PicFrame runs for 30 minutes to an hour. Initially I thought this is the limit from my 4B 1Gb raspberry pi, but this resolution rate is so low, processing power shouldn't be an issue. Earlier versions of the raspberry pi (3B for instance) are reported to work, so I assume the 4B should as well. I'm at a loss for what to try next but happy to try anything if there are suggestions. It's pretty underwhelming in the current form. Otherwise I'll wait until 4B 4GB pi's start stocking shelves again and have a another go at it then..