Hi - I’m trying to run ffplay /dev/video0
and I’m getting this message:
Invalid MIT-MAGIC-COOKIE-1 key[1] 8313 segmentation fault (core dumped) ffplay /dev/video0
Any help on what might be happening or where I can start debugging?
Thanks!
Jamie
I fixed part of the message it looks like:
From https://unix.stackexchange.com/a/199892
export DISPLAY=desktop:0
This removed the MIT-MAGIC-COOKIE-1 key
Now the message says
[1] 10980 segmentation fault (core dumped). ffplay /dev/video0
I couldn’t say for sure, but have you tried instead “DISPLAY=:0
”? Is the same user launching ffplay
also the user which is logged in to the GUI? Do you see your user listed in:
grep 'video' /etc/group
Thanks @linuxdev
I reflashed my sd card with the latest Image blob JP4.5.1 to my jetson nano 4gb B01 board and ran ffplay /dev/video0
and got a new message that says:
dbus[7838]: arguments to dbus_message_new_method_call() were incorrect, assertion "path != NULL" failed in file ../../../dbus/dbus-message.c line 1362.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
Aborted (core dumped)
I tried DISPLAY=:0
and now the message Invalid MIT-MAGIC-COOKIE-1
has returned.
Running the command:
grep 'video' /etc/group
outputs:
video:x:44:bg-user,gdm,lightdm
“bg-user” is my user name so yes it is listed in the group.
Anything else that it might be?
Really appreciate your help!
Jamie
I don’t develop for ffplay
, so I can’t answer the questions specific to that. However, if your user is “bg-user
”, and you run ffplay
as that user, then your software has full access to GPU hardware (if things are set up correctly, then there is no reason that user would not succeed). The content of “/etc/group
” verifies this is set up correctly.
If you start ffplay
from the GUI itself, and are running ffplay
as the user logged in to that GUI, then there would be no need to “export DISPLAY=....something...
”. If you were to log in to your user in a non-GUI console, then you would need to export the correct DISPLAY
to associate to the available GUI. If you are in your GUI and run command “echo $DISPLAY
”, then this would guarantee the correct DISPLAY
to export when not running from that GUI while trying to associate the ffplay
with that GUI. Usually it is this:
export DISPLAY=":0"
…what do you see from your GUI with “echo $DISPLAY
”?
In most cases DISPLAY
is “:0
”, but in other cases, DISPLAY
is “:1
”; you would use the correct DISPLAY
from the non-GUI console (if running ffplay
from outside of the X GUI) prior to running ffplay
:
export DISPLAY=":1"
...some ffplay command...
(but keep in mind I don’t have to run from a text-based non-GUI console…you can ignore all of that export
and DISPLAY
information when launched in a GUI your user already owns…launching from inside the GUI automates setting this up)
Note that all of the MIT-MAGIC-COOKIE
errors are part of the X GUI security setup. This is a big reason why I mention the “export
” and “DISPLAY
” information. You should never see an error related to that when a user logged in to a GUI launches software from that GUI…at least it wouldn’t be a security issue. Can you launch the ffplay
without error from the GUI your user is already logged in to? If you can, then your ffplay
command should be valid; if not, then regardless of running from a non-GUI terminal or from the GUI I would expect failure. If you can run ffplay
directly on the GUI, expect a similar error by specifying the wrong “DISPLAY
”, e.g., if you are really on “:0
” and specify “:1
” (or vice versa), then you would get such an error. Also, if using a non-GUI and specifying DISPLAY
such that it is lost prior to running ffplay
(e.g., not using export
from that console prior to running ffplay
), then I would also expect such an error.
Thanks again @linuxdev
This makes sense. I’ve been ssh-ing in to the nano from my macbook and that could’ve been part of the problem.
When I run echo $DISPLAY
from a nano terminal I get :1
. When DISPLAY
is set to :0
I get the MIT-MAGIC-COOKIE
error but when set it to :1
there is NO error.
So I seemed to get ffplay
to run after I searched for dbus
errors and found a workaround here.
Running the command export DBUS_FATAL_WARNINGS=0
allowed video to be displayed from my camera running ffplay
but it still says the warning:
dbus[8099]: arguments to dbus_message_new_method_call() were incorrect, assertion "path != NULL" failed in file ../../../dbus/dbus-message.c line 1362.
This is normally a bug in some application using the D-Bus library.
Apparently DBUS is related to the emulator. As another piece of information regarding my setup, I have both the nano 2GB running jp441 and the nano 4GB B01 running jp441 as well and I only see this error on the 4GB B01 machine.
maybe this is useful information?
Any suggestions on if or how I should investigate this dbus issue?
Thanks so much,
J
Yes, if you ssh
in from a Mac it won’t know which “$DISPLAY
” the command is intended to display to. I will assume you don’t want it to remote display to the Mac itself, which would be its own topic on forwarding (and pointless if the Mac doesn’t have an X server, and I don’t have a Mac…while Macs have a lot in common with Linux I have no idea if they use X or not…though probably not).
The best thing to do, at least while testing and setting up, is to actually go to a terminal in the video output GUI of the Jetson, and see what occurs from “echo $DISPLAY
”. This would be the DISPLAY
to export prior to the command from the ssh
terminal. E.g., if it is “:0
”, then from the ssh
terminal:
export DISPLAY=":0"
…followed by running your “ffplay
” command.
Also be certain that the user which has the Jetson GUI open is also the user the ssh
session is logged in as.
Note that dbus
is a secure mechanism for certain communications between applications in the X environment. MIT-MAGIC-COOKIE can be related to this, and so can “$DISPLAY
” and the user name you are logged in as. Basically it is either an issue of security, or an issue of being able to find and associate the correct GUI to display to.
Also, note that if you are trying to display to the Mac what you are running on the Jetson, that this will fail unless the Mac is running X and security has allowed the forwarding. I don’t know Mac setup, so I couldn’t tell you what is needed to remote display to a Mac without a virtual desktop.
1 Like
Thanks @linuxdev
I will do some research on dbus
and the X environment.