Display showing Screenly logo and console output only

Anthias
1

Hello everyone!

So I’ve been using Screenly as a display to show a building directory, names and office numbers, for some time now. We used to have Screenly running on an older Pi but recently upgraded it to a 3B+. The display is connected to the PI via HDMI and the screen is in the vertical orientation with display_hdmi_rotate=3 in the config.txt. The PI is hardwired via ethernet and doesn’t have any USB devices plugged into it. The directory web page is a PHP page being served from a RedHat Apache web server that is accessible from a normal web browser anywhere in the world. I have only this page added as a single asset inside Screenly with it set to play “Forever”.

For some reason the display now only shows the Screenly logo and a small line of the console at the bottom: https://imgur.com/n1NGyh7. Sorry about the image quality as my manager took it with a potato apparently and I’m working remotely :upside_down_face:. I tried upgrading to the Experimental version as this was happening on the normal release too but haven’t noticed a difference. I also tried simply setting Google’s homepage as an asset and it won’t load that either with the same results. Everything in the logs says that it should be displaying properly from what I can see. Hopefully someone can review the logs below and spot what is going on here.

Hardware: Raspberry Model Model 3B+ Revision: 1.3 Ram: 1 GB Sony UK
Screenly Version master@959e5d3
Pastebin of Logs: pastebin.com/ZmtfYQ4T

2

Anyone have any ideas or things that I can try? I have full SSH access to the PI remotely and Screenly is up and running just no content display as per the previous post, only the Screenly logo and a small bit of the console below it. Thanks for any help anyone can offer. Really appreciate it.

3

Thank you for your patience.

From the look of the screenshot, the player is stuck in displaying the splash screen. That leads me to believe that it’s either a corrupt SD card or broken installation. I’d replace the SD card and download the latest disk image to see if that resolves the issue.

4

@ESSIC
what does the “small line of the console at the bottom” say?
Can you try to run this command and tell me results?
systemd-analyze blame

5

@ealmonte32 Thanks so much for getting back to me on this. Yeah, I also worry it may be an SD card issue as @vpetersson stated. The line below the Screenly logo says " screenly-viewer.service". Here’s the systemd-analyze output:

7min 42.155s systemd-tmpfiles-clean.service
4min 43.655s wifi-connect.service
     16.474s NetworkManager-wait-online.service
     11.122s redis-server.service
      3.684s apt-daily-upgrade.service
      2.422s networking.service
      1.946s apt-daily.service
      1.868s plymouth-read-write.service
      1.858s dev-mmcblk0p7.device
      1.484s NetworkManager.service
      1.362s ModemManager.service
       737ms keyboard-setup.service
       626ms wpa_supplicant.service
       608ms ssh.service
       574ms nginx.service
       512ms screenly-web.service
       509ms systemd-logind.service
       432ms raspi-config.service
       422ms systemd-udev-trigger.service
       377ms rsyslog.service
       352ms systemd-fsck@dev-mmcblk0p6.service
       338ms alsa-restore.service
       334ms triggerhappy.service
       326ms avahi-daemon.service
       271ms systemd-timesyncd.service
       247ms systemd-journald.service
       234ms screenly-viewer.service
       215ms wifi-country.service
       201ms systemd-tmpfiles-setup-dev.service
       198ms systemd-fsck-root.service
       171ms polkit.service
       164ms fake-hwclock.service
       125ms plymouth-start.service
       124ms rc-local.service
       122ms user@1000.service
       119ms systemd-journal-flush.service
       118ms systemd-tmpfiles-setup.service
       111ms pppd-dns.service
       109ms plymouth-quit-wait.service
       108ms plymouth-quit.service
       104ms dev-mqueue.mount
        97ms systemd-udevd.service
        91ms console-setup.service
        90ms systemd-update-utmp.service
        89ms run-rpc_pipefs.mount
        88ms systemd-modules-load.service
        79ms systemd-user-sessions.service
        72ms nfs-config.service
        69ms systemd-random-seed.service
        68ms sys-kernel-debug.mount
        67ms kmod-static-nodes.service
        65ms systemd-remount-fs.service
        62ms systemd-sysctl.service
        43ms sys-kernel-config.mount
        36ms systemd-update-utmp-runlevel.service
        31ms boot.mount

Thanks everyone!

6

Well, seeing these two lines take multiple minutes is probably not a good sign:

7min 42.155s systemd-tmpfiles-clean.service
4min 43.655s wifi-connect.service

Hmm… it could be the SD card yes but prior to going that route, can try to manually clean the tmp and reboot:
sudo systemd-tmpfiles --remove
sudo reboot
If that doesnt help, I wonder if flashing an entire new Buster lite image on that same SD card and running the install script and going with master/dev branch again will do some miracles…

1 Like
7

@ESSIC
I just tested your URL on a freshly burned buster-lite image with screenly-OSE installed via bash script:

IMG_20201007_192932
IMG_20201007_1929324096×3072 1.93 MB