Unable to get video or images out of the box #10
Comments
|
Investigating.. |
|
Likely an issue with pulse audio. The video module unfortunately requires a working audio driver (out of our control for now). It looks like pulseaudio might not always properly initialize itself, resulting in the termination of the video bridge. I will submit some improvements and some guidance when these types of errors arise. |
The video bridge requires a working pulse audio driver. We now start pulse audio with a configuration that opens up all access, and add additional early checks to validate pulse audio configuration. Updates the documentation with more information how to diagnose WebRTC failures. This fixes google#10. Includes fixes for missing adb and python 2 compatibility issues. This fixes google#9.
The video bridge requires a working pulse audio driver. We now start pulse audio with a configuration that opens up all access, and add additional early checks to validate pulse audio configuration. Updates the documentation with more information how to diagnose WebRTC failures. This fixes google#10. Includes fixes for missing adb and python 2 compatibility issues. This fixes google#9.
The video bridge requires a working pulse audio driver. We now start pulse audio with a configuration that opens up all access, and add additional early checks to validate pulse audio configuration. Updates the documentation with more information how to diagnose WebRTC failures. This fixes google#10. Includes fixes for missing adb and python 2 compatibility issues. This fixes google#9.
|
Unfortunately still facing the same issue or similar issue using the latest canary and your update; Output of From the log, it seems like screenshots are working, but in the browser, no image shows up. After removing |
|
Interesting; let's also try with modifying the Dockerfile to launch |
|
tail: cannot open '/tmp/android-unknown/goldfish_rtc_0' for reading: No such file or directory this could also be related In the web interface itself, can you also try using the PNG fallback? |
|
The reason youre seeing the error without -no-window is that Qt UI gets loaded, which in turn requires a bunch of dependencies not specified in the dockerfile. |
|
Yeah, I figured that was the issue without -no-window, just wanted to check that Regarding using PNG fallback, the logs look identical to just using PNG: Something weird I noticed; on fresh startup of the containers, if I have the web view open already, I will get the PNG of the android boot screen, but no further images afterwards. Running with |
The reason you are seeing this is because the log file will be created when the video bridge actually starts, we initially are waiting for the file to be created (hence the --retry flag). Later on we should see this on the log:
@li-richard did you re-run the emu-docker script to create a new emulator container? With the new changes I expect to see something along the following on the logs: The WebRTC module will not work if you see this line: It is normal for Pixels to be null before the emulator has completed booting. See following log snippet:
Pixels will become available later in the boot sequence. Usually by the time logcat becomes active, pixels are available. I've filled two emulator bugs to track improvements we can make: @li-richard could you please try re-running with the latest changes? i.e.
|
|
Ran the commands you specified @pokowaka with the latest changes. Continuing to see the screenshot of the android boot screen flash once or twice, then no further images follow. From what you said about pixels becoming available later in the boot sequence, it seems like the root cause of not being able to get images might be due to the emulator crashing on startup? Here's the output of Even after logcat becomes active, I'm still getting |
|
logs.txt |
|
I noticed: On the logs. This means pulse audio is not properly initialized. The video bridge cannot launch. We are also running into some serious kernel issues (this should not be happening): I do see on the logs that screenshots fail to produce results: Could you perhaps share the CPU/OS and docker version you using?
Are you running in a nested virtualization environment? That way I might be able to reproduce it locally to get a better understanding of what is going on. |
|
Not running in a nested virtual environment. Other information: |
|
It looks like you are using redhat, which version are you using? |
|
|
Thank you for your patience! I've managed to partially reproduce what happens. It looks like it is possible that the container with the emulator is not launched from a clean slate. This can happen when the emulator crashes (possible due to the kernel issues you are seeing). This can cause multiple issues:
I'm investigating what we can do to unblock you. On a side note, it appears that some older api levels (19 <) have kernel issues when running within Docker. It is likely that those images will not properly run. |
|
Based off your comments, I cleaned out all the old images and containers, and rebuilt everything from scratch, and was able to get video as well as screenshots working. However, I was unable to get past the boot screen, and there is no further logcat output besides and it looks like I'm still getting the kernel problems mentioned above. Also for reference, I am running API 22 on emulator v29.1.13 canary. Will retry with higher API level to see if I can reproduce there. EDIT: I was able to get it working with API 28, emu v29.1.13 canary |
It is possible that the emulator container has data left around. This can cause trouble where: - PulseAudio fails to initialize, disabling the video bridge - Dangling snapshot locks, disabling emulator launch. Usually this is due to unexpected exits of the emulator executable. This also includes some cleanup of the Dockerfile to introduce multiple layers. This makes it faster to rebuild the containers. Updates the documentation to explain why pre-O images will not work. Fixes issue google#10
|
Thank you! I've verified that we cannot launch images before O due to kernel issues. We are tracking this in https://issuetracker.google.com/issues/140881613. |
|
Let me know if you are unblocked and we can close the issue. |
|
Feel free to close. We actually run our test suite on API 22, but I'll follow the issuetracker for updates regarding that. Thanks for your help in resolving this! |
- Fixes a bug where we could not launch older API levels - Setup a default formatter (black) - Enable GPU detection, if docker exposes your gpu we will use it - Fix Docker file order to improve caching Bugs: https://buganizer.corp.google.com/issues/140773032 Fixes: google#10
- Fixes a bug where we could not launch older API levels - Setup a default formatter (black) - Enable GPU detection, if docker exposes your gpu we will use it - Fix Docker file order to improve caching Bugs: https://buganizer.corp.google.com/issues/140773032 Fixes: google#10
So I have got the containers and images all up and running, but am unable to see any video or images on the React site.
I thought maybe this was due to the
no-windowflag used inlaunch-emulator.sh, but removing this flag ended up causing a Qt error, since it seems like not all the dependencies are installed in docker.Is the video/image feature supposed to just work out of the box, with
-no-windowparam set?For reference, the error I am getting with Qt when running without
-no-windowis:which seems to be this error therecipe/qt#775.
Any insight is appreciated, thanks!
The text was updated successfully, but these errors were encountered: