Errors/Blank Screen - Raspberry Pi 4

@jvolker

@jvolker I tried downloading both your image itself and running the install script you created on the newest version of Buster. In both cases, when I set openframe to run on startup I'm getting a black screen with no art coming up. I'm on a Raspberry Pi 4 with 1Gb memory. I'm also getting the black screen (Issue #42 ) on SSH. When I run openframe from console I get a lot of errors when displaying art randomly. Any ideas on what could be happening? I'd be happy to do further testing on the Pi 4!

Thanks for your contribution to this project! I got pretty excited when Raspberry Pi 4 support was added - then 4k becomes possible, which is a huge step forward!

Glad you're trying the images.

Login via SSH is currently only working with autostart disabled (https://groups.google.com/forum/#!msg/openframeio/X1BapUmEchs/QPE9UUzjAgAJ). There is a fix available and merged but there not a new release yet.

I assume the black screen might be an artwork that is offline. There is no error message for this yet (#50).

What artwork are you specifically testing with? Could you please post a link and format/type of the artwork? Could you take a picture of the errors you can see?

Here's a link to some art I'm using: https://openframe.io/artwork/5d9b4beea38167076035be26

Art does display if I do not autostart, and the art above displayed fine - sometimes.

Here is the error I sometimes see when pushing a photo (it seems random if/when I get the error). This is a 4k photo that is not small, so perhaps it is due to download time?

Here is the error I am always seeing when I push a 4k MP4 video to the frame (here is a link to that actual video) :

Sorry for the mistake on SSH - I read the Github comments and didn't quite understand. I will begin reading Google Groups from now on! Glad you're thinking of moving forums to Discourse - I will join there as soon as things are approved.

@jmwohl

It seems like the image is not loading because the GPU memory is still set too small for such a big image. Increasing it to 512MB worked for me:
sudo raspi-config nonint do_memory_split 512

I checked the video(54,7MB) with debug turned on DEBUG=* openframe tried multiple times.

Once I got this:

openframe:downloader curl: (18) transfer closed with 50607703 bytes remaining to +1ms

I recommended in #50 to switch to a node downloader instead of spawning curl. Not sure if this would solve it.

Another time:
openframe:pubsub pubsub client connected +87ms and openframe:pubsub pubsub client disconnected +307ms while still downloading. I'm wondering if this triggers spawning multiple download causing an endless download mess.

The output looked something like this. It stopped the old artwork at some point, but continued downloading afterwards:

 openframe:downloader stderr: 0 52.1M    0     0   190k      0  0:04:40  0:04:40 --:--:--  323k
  openframe:downloader  +1ms
  openframe:downloader child process exited with code 0 +59ms
  openframe:frame_controller swapArt +0ms
  openframe:frame_controller endArt +0ms
 19 52.1M   19 10.3M    0     0  97449      0  0:09:21  0:01:51  0:07:30  142k +9ms
 12 52.1M   12 641 +29mstderr: 
  openframe:downloader stderr: 5k    0     0   282k      0  0:03:08  0:00:22  0:02:46  339k +1ms
  process_manager child 1957 closing code: null +23ms
  openframe:frame_controller Error: Command failed: sudo pkill -f omxplayer
  openframe:frame_controller 
  openframe:frame_controller     at ChildProcess.exithandler (child_process.js:206:12)
  openframe:frame_controller     at emitTwo (events.js:106:13)
  openframe:frame_controller     at ChildProcess.emit (events.js:191:7)
  openframe:frame_controller     at maybeClose (internal/child_process.js:877:16)
  openframe:frame_controller     at Socket.<anonymous> (internal/child_process.js:334:11)
  openframe:frame_controller     at emitOne (events.js:96:13)
  openframe:frame_controller     at Socket.emit (events.js:188:7)
  openframe:frame_controller     at Pipe._handle.close [as _onclose] (net.js:498:12) +23ms
  openframe:frame_controller startArt +1ms
 26 52.1M   26 14.0M    0     0   1 +127ms
  openframe:downloader stderr: 28k      0  0:06:54  0:01:51  0:05:03  192k +0ms
have a nice day ;)
  process_manager child 2326 closing code: 1 +404ms
 20 52.1M   20 +395msr stderr: 
  openframe:downloader stderr:  10.5M    0     0  98469      0  0:09:15  0:01:52  0:07:23  150k +1ms

I'm not sure what this is. Maybe @jmwohl could help?

It looks like 512MB did the trick on images. I wonder if we should update our docs to recommend a bigger memory split if images have problems displaying? I'd be happy to do this if needed. Also, we may want to state that larger videos may not work. Just a thought...

OK - the last remaining issue is autobooting. I am still getting a blank screen after I reboot after enabling autoboot on my Pi 4. Let me know if there is some debugging I should be digging into on my end and I'll get after it...

Thanks again for your help!

@jvolker

@jvolker it looks like the 512Mb memory trick usually works, but not always. I have my frame in slideshow mode, and it throws this error when it hits certain images:

Here is an image that tends to display an error: https://danelliottphotography.com/wp-content/uploads/2019/10/DSC01965.jpg

Is the error reproducible with this image or does it only happen sometimes?
You could try to set GPU memory to 1024. Does that help?

OK - the last remaining issue is autobooting. I am still getting a blank screen after I reboot after enabling autoboot on my Pi 4. Let me know if there is some debugging I should be digging into on my end and I'll get after it...

Does that only happen with slideshow on or generally with any sort of content? The content might be offline.

I wonder if we should update our docs to recommend a bigger memory split if images have problems displaying? I'd be happy to do this if needed.

Yes, please. Would be good to have that. Although I think it would be good to change the install script as well. Currently, it doesn't do that at all.

Also, we may want to state that larger videos may not work. Just a thought...

Yeah would be good but I would rather focus on getting it fixed, to be honest.

Sorry for the mistake on SSH - I read the Github comments and didn't quite understand.

No worries.

I will begin reading Google Groups from now on! Glad you're thinking of moving forums to Discourse - I will join there as soon as things are approved.

Thanks for being part of this project.

I have a 1Gb Pi 4, so 512 for the GPU is the furthest I can go.
It happens both with the slideshow extension and when pushing an image to the frame from the web UI. I tested it some more today, and I can get it error on more than one image. It seems to happen more frequently if I push an image quickly after another image has loaded. These images are on a server that I can get to fine other places.

I wonder if we are dealing with the GL driver? I found this looking at the error I get: https://www.raspberrypi.org/forums/viewtopic.php?t=250271

From https://www.raspberrypi.org/documentation/configuration/config-txt/memory.md

The gpu_mem_1024 command sets the GPU memory in megabytes for Raspberry Pi devices with 1024MB or more of memory. (It is ignored if memory size is smaller than 1024MB). This overrides gpu_mem. The maximum value is 944, and the default is not set.

So you should be able to go further up. Although in this document it also says it's not recommended. But I don't know it might not be the reason anyway.

It seems to happen more frequently if I push an image quickly after another image has loaded.

Would be good to check this thoroughly and if necessary work on the downloader I think. Could you please give a reproducible list of images and instructions that cause this error? That could help to find a fix. Thanks in advance.

I don't know anything about the GL drivers. But under the hood, the image extension is using https://github.com/patriciogonzalezvivo/glslViewer/ maybe there is more info about this.

Here is an image that tends to display an error: https://danelliottphotography.com/wp-content/uploads/2019/10/DSC01965.jpg

Just tested that image and it works fine on a Pi 4 with 4GB and 512MB GPU memory. I suspect it was a problem with the downloader.

@jvolker

Thanks for digging into this @jvolker I think you're onto something with the downloader. I tried the frame out at a different location that might have faster internet, and didn't see the error often. Back here, I'm seeing the error more. I do have good internet here though.

Here are images for you to look at:

Steps to reproduce:

Follow install script directions for RPi4.
Run openframe from command line (log in, but do not set to autoboot)
Optional: Install openframe-slideshow plugin
Re-run openframe from command line.
Begin pushing images (rapidly if needed) to the frame to get the error.

@vetmiker

Thanks, @vetmiker.

I've just done a pull request for a rewrite of the downloader. The debug/error output should be much clearer with that. It won't fix the issue you are describing though.

It seems the error is caused when new artwork is pushed while the frame is still downloading another one. This needs a fix.

@jvolker

@jvolker thanks for jumping on that so fast - staying in node for downloading art makes sense!

If I have some time today I'll pull down this repo with your rewrite pull request included and see if it makes a difference.

All good.

If I have some time today I'll pull down this repo with your rewrite pull request included and see if it makes a difference.

I'm almost sure it doesn't. I've tested it and checked the code. It doesn't seem there is anything to cancel a download yet.

I've made some tests with some of the above-mentioned test images on the Pi3B and couldn't open the big ones at all: OpenframeProject/Openframe-Image#6

I guess there is a general issue with large images and glslViewer which is used by the image extension of Openframe.

@vetmiker

Let's close this issue and discuss all problems separately in the respective repositories and issues.

Regarding the issue of multiple parallel downloads there is now a partial fix available in #65. I've also opened up a new issue #67 to discuss this further.

@vetmiker could you please open another issue in https://github.com/OpenframeProject/Openframe-Image describing the dumb buffer permission denied error. I've done some tests on Pi3B and didn't get this error I had general issues with large images though. So I assume this is a problem with Pi4 and the image extension only.

@vetmiker

@vetmiker I've just released a VLC extension: https://github.com/jvolker/Openframe-VLC, that in theory also supports images. I've not tested it on the Pi 4 yet, but it would be interesting to see if your images work with that extension.

Also @vetmiker can you please close this issue?

Navigation Menu

Repository navigation

Errors/Blank Screen - Raspberry Pi 4 #64

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Errors/Blank Screen - Raspberry Pi 4 #64

Description

Activity

jvolker commented on Oct 7, 2019

vetmiker commented on Oct 7, 2019

jvolker commented on Oct 7, 2019

vetmiker commented on Oct 8, 2019

vetmiker commented on Oct 8, 2019

jvolker commented on Oct 8, 2019

vetmiker commented on Oct 8, 2019

jvolker commented on Oct 8, 2019

jvolker commented on Oct 8, 2019

vetmiker commented on Oct 8, 2019

jvolker commented on Oct 9, 2019

vetmiker commented on Oct 9, 2019

jvolker commented on Oct 9, 2019

jvolker commented on Oct 12, 2019

jvolker commented on Oct 12, 2019

jvolker commented on Oct 21, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions