Blank screen on Raspberry Pi 4

[shankargopal]

Hi, I love the idea of Neko, thank you so much for this project! I plan to use it for running some browser-based tasks that I don't want crowding up my (relatively low powered) system.

But while I'm able to log into Neko at <LOCAL IP>:8088 (not 8080, even though it claims it's listening on 8080), I get a blank screen. This happens whether I am using the Firefox or the Chromium versions. I have used the docker-compose.yaml file from the Raspberry Pi example given on the Examples page, and only modified it by adding NEKO_NAT1TO1 and increasing shm_size. This is my docker-compose.yaml file (with Firefox):

version: "3.4"
services:
  neko:
    image: "m1k1o/neko:arm-firefox"
    restart: "unless-stopped"
    # increase on rpi's with more then 1gb ram.
    shm_size: "1024mb"
    ports:
      - "8088:8080"
      - "52000-52100:52000-52100/udp"
    # note: this is important since we need a GPU for hardware acceleration alternatively
    #       mount the devices into the docker.
    privileged: true
    environment:
      NEKO_SCREEN: '1280x720@30'
      NEKO_PASSWORD: 'neko'
      NEKO_PASSWORD_ADMIN: 'admin'
      NEKO_EPR: 52000-52100
      # note: when setting NEKO_VIDEO, then variables NEKO_MAX_FPS and NEKO_VIDEO_BITRATE
      #       are not being used, you can adjust them in this variable.
      NEKO_VIDEO: |
        ximagesrc display-name=%s use-damage=0 show-pointer=true use-damage=false
          ! video/x-raw,framerate=30/1
          ! videoconvert
          ! queue
          ! video/x-raw,framerate=30/1,format=NV12
          ! v4l2h264enc extra-controls="controls,h264_profile=1,video_bitrate=1250000;"
          ! h264parse config-interval=3
          ! video/x-h264,stream-format=byte-stream,profile=constrained-baseline
      NEKO_VIDEO_CODEC: h264
      NEKO_NAT1TO1: XXXXXX

If I connect to the container using docker exec -it neko-neko-1 bash, and then run ps aux, I get this output:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.3  16000 13300 ?        Ss   12:11   0:00 /usr/bin/python2 /usr/bin/supervisord -c /etc/neko/supervisord.conf
root         9  0.0  0.0   1472   424 ?        S    12:11   0:00 /bin/sh /usr/bin/dbus
neko        11  3.4  0.1 348324  5108 ?        Sl   12:11   0:33 /usr/bin/pulseaudio --disallow-module-loading -vvvv --disallow-exit --exit-idle-time=-1
neko        12  8.0  1.2 330444 49824 ?        Sl   12:11   1:18 /usr/lib/xorg/Xorg -config /etc/neko/xorg.conf :99.0
neko        14  7.5  6.8 903384 268076 ?       Sl   12:11   1:14 firefox-esr --no-remote -P default --display=:99.0 -setDefaultBrowser -width 1280 -height 720
message+    15  0.0  0.0   5208  2444 ?        S    12:11   0:00 /usr/bin/dbus-daemon --nofork --print-pid --config-file=/usr/share/dbus-1/system.conf
neko        16 49.7  1.0 1256144 42480 ?       Sl   12:11   8:08 /usr/bin/neko serve --static /var/www
neko        37  0.0  0.0   5196  1520 ?        S    12:11   0:00 dbus-launch --autolaunch e8a4b59ac0c40c0bd502574421e3d4ad --binary-syntax --close-stderr
neko        38  0.0  0.0   5208  1768 ?        Ss   12:11   0:00 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
neko        61  0.0  0.3  53772 12680 ?        S    12:11   0:00 /usr/bin/openbox --config-file /etc/neko/openbox.xml
neko       115  2.3  2.8 529836 112380 ?       Sl   12:11   0:22 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 215023 -parentBuildID 20210927121355 -appdir /usr/lib/firefox-esr/browser 14 true tab
neko       138  0.4  2.6 396548 103760 ?       Sl   12:11   0:04 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 2 -isForBrowser -prefsLen 45 -prefMapSize 215023 -parentBuildID 20210927121355 -appdir /usr/lib/firefox-esr/browser 14 true tab
neko       211  0.0  1.3 356580 51500 ?        Sl   12:11   0:00 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 3 -isForBrowser -prefsLen 8853 -prefMapSize 215023 -parentBuildID 20210927121355 -appdir /usr/lib/firefox-esr/browser 14 true tab
root       967  0.5  0.0   2688  2112 pts/0    Ss   12:27   0:00 bash
root       983  0.0  0.0   4280  1720 pts/0    R+   12:27   0:00 ps aux

So firefox appears to be running. But I can't see it. This appears to be a bug? Or perhaps I just don't know what I'm doing? (I should also mention that I am a docker newbie).

Here's a screenshot of my screen

[mbattista]

First it listens to 8088 because in the yaml stands '- "8088:8080"' :)

Can you post the log of the neko instance? It probably has some errors in there.

[shankargopal]

log.txt

Here you are. And I think I see your point :-). I was confused because somewhere in the output it said "listening on 8080."

[shankargopal]

So, commenting out the NEKO_VIDEO line in docker-compose.yaml makes it start, and all seems to work ok.

But I presume the options in that line are to make things easier on the Pi. So without it my Pi has maxed out to the extent that it's heating dangerously and I had to shut down Neko.

I'll try fiddling with that line and reporting any results to you. I don't know what most of those options mean though so it's kind of going to be stumbling around in the dark.

[mbattista]

Commenting out the NEKO_VIDEO should lead to inefficient encoding on a rpi, since then it will not use the Hardware Acceleration.

I do not have a rpi4 right now to test against, why this fails. Can you lower the bitrate and check again? Are there incoming packages in the chrome://webrtc-internals/ tab?

[shankargopal]

I tried replacing video_bitrate=1250000 with video_bitrate=250000 and it did not make a difference - with the NEKO_VIDEO line present, I still get the blank screen.

I'm currently using the Firefox container, so no chrome://webrtc-internals. I commented out NEKO_VIDEO, restarted Neko, and accessed about:webrtc. I also tried to start "Debug Mode" and then stopped it. I got this screen:

Doesn't seem to be of much help :-(. Will try with Chromium if you think that'll help.

There is another odd behaviour, not sure if that helps to figure this out or not. I tried using WhatsApp Web in the Firefox container. It opened normally, synced, loaded my messages (all slowly, but still did it), etc. But I was unable to send messages from it - the messages just never went and my phone's WhatsApp never showed them.

[shankargopal]

Ok, I tried with the Chromium container. I'm sorry, I don't know what to do in chrome://webrtc-internals, I just get this:

[mbattista]

Sorry, I meant to open it on your Browser and not in the Container. You can do this with the Firefox Container as well.

It should show you some information about the current webrtc season. The interesting part would be the video stats.

You can also check if sudo apt-get install v4l-utils will install something in the container.

[shankargopal]

Oh thanks for the clarification. Yes, with the black screen, I get some video stats from about:webrtc in Firefox on my own system. This is what it reports:

I'm also attaching the report that Firefox generated, which seems to be in json:

newlog.txt

For that command, it says Unable to locate package v4l-utils . When I run it inside the container, that is. When I try to run it on the Pi, I get v4l-utils is already the newest version.

[mbattista]

Try running apt-get update before the apt-get install v4l-utils command. This should work.

In the logs it says, that the video is VP8 instead of h264. Do you still have the NEKO_VIDEO_CODEC: h264 in the yaml file?

[shankargopal]

Ok, the apt-get install now worked. Doesn't seem to have changed the blank screen, but I'm not sure if that's what you were expecting?

Yes the NEKO_VIDEO_CODEC: h264 line is still there. The output mentioning VP8 confused me too.

[mbattista]

Can you check, that if you run it without the NEKO_VIDEO line and you are getting a video, do you still have the VP8 in the logs?

[shankargopal]

Yes, it's still VP8. This is what I see at about:webrtc:

I also checked inside the running container, the environment variable NEKO_VIDEO_CODEC is correctly set to h264. But the output is still in VP8.

Also, just for reference, with this same container (with NEKO_VIDEO commented out), I tried entering the container, installing v4l-utils as you said, and restarting the container. Video codec is still shown as VP8.

[mbattista]

OK, I think I am just blind. In the attached log it says, that it uses neko 2.4, the NEKO_VIDEO_CODEC got introduced later.

Try NEKO_H264: True instead. This should switch to H264 and should work with the NEKO_VIDEO pipeline.

[shankargopal]

:-) no problem. But I tried both those changes, and am unable to connect. I get a "connection timed out" message on my end, and in the output on the Pi, a line appears like this:

3:45PM ERR message handler has failed error="signal/answer failed: unable to start track, codec is not supported by remote" module=websocket

Is it that my browser doesn't support h264?

However, when I test my browser here, I get this response:

YES H.264 is supported!

So don't know what is going on :-)

[mbattista]

The fix for Firefox got merged later, so yes, for neko 2.4 H264 has no Firefox support. See https://github.com/m1k1o/neko/pull/109

If you want the current version of neko you could build it for yourself on the rpi.

1. clone the repo on the rpi
2. go into the .docker folder
3. rename the .env.default file to .env
4. ./build arm-base
5. ./build arm-firefox

After this, this should start your local build container and perhaps will have different errors. :)

[shankargopal]

Ok, I will try to do that. In the meantime I can confirm that with a Chromium client, I get a working system, things seem significantly faster, and my Pi is running warm but is no longer trying to burn the house down.

So I think we can close this bug now? Maybe, when you have time, it might be worth editing the text at the Examples page to use NEKO_H264 instead of the current text?

I may not get to the rebuild effort for a while as I've found another way to get what I needed just now (not as nice, but it works). But if / when I do will tell you how it goes.

Thank you so much for going back and forth with me on this so much, and for this wonderful project!

[mbattista]

The better solution would be, to rebuild the ARM images with the current version. I do not know, why those are out of date.

I thought since https://github.com/m1k1o/neko/pull/302 the pipeline build the ARM Images as well, but I never checked the dockerhub. It seems that on dockerhub the newest ARM image is from two years ago.

[mbattista]

And yes, the performance is not the best, but it works. You can try different bitrate as well as different resolutions to see what is working for your pi4.

And from my understanding, the rpi will deal with his heat and decrease his performance if it is critical. And one more hint: Check the firmware of your pi for better heat management https://www.hackster.io/news/newly-released-raspberry-pi-4-usb-3-0-firmware-drops-power-draw-heat-output-on-all-models-6ab398270685

[m1k1o]

@mbattista thank you for troubleshooting, @shankargopal sorry for the confusion, NEKO_H264 is deprecated and NEKO_VIDEO_CODEC should be used instead. However, m1k1o/neko:arm-chromium is not updated automatically, the latest version is only pushed to ghcr (see docs).

The example clearly uses outdated image and it should be updated in examples and users should be warned about this. Thanks for bringing this up.

P.S: we could as well push the arm images to dockerhub, should not be a big change to CI.

[shankargopal]

And yes, the performance is not the best, but it works. You can try different bitrate as well as different resolutions to see what is working for your pi4.

And from my understanding, the rpi will deal with his heat and decrease his performance if it is critical. And one more hint: Check the firmware of your pi for better heat management https://www.hackster.io/news/newly-released-raspberry-pi-4-usb-3-0-firmware-drops-power-draw-heat-output-on-all-models-6ab398270685

I meant that my other solution is not as nice as Neko, but it works :-). When I get the chance will try the new images for Neko. And yes will checkout the firmware advice. Thank you!

@m1k1o thank you for all the work!

Thank you both again. I'm closing this bug now as it seems like the issue is sorted?