Sushi broken (again)

Support GNOME
1

Sushi no longer works for video files, the audio plays but video is just a black box.

This was working either yesterday or the day before, so its very recent update that seems to have killed sushi video preview. (vlc etc work fine)

Some other file types are also not working such as odt, docx. I’m not sure if that’s a new issue but certainly the blank video is.

Quite frustrating since I’ve been waiting months for them to fix the last sushi breaking bug & enjoyed about a week before it broke again,

Is this affecting everyone? or just my system?

(FYI to invoke Sushi file previews in Nautilus, select a file & press space. arrow key to move to next file.)

1 Like
2

well its broken in the new manjaro ISO too, so I guess its Gnome Devs to blame again.
Im really tired of them breaking this feature over & over.

1 Like
3

I’ve noticed it too, I’ve been looking around for a solution or at least an issue being tracked on the Nautilus or Sushi Gitlab…but haven’t come up with anything useful.

Been trying to get it to toss an error to report, but nadda there too.

Edit: It just occured to me to try firing up a Gnome OS VM and see if sushi has the same issue there so we can at least track down if it’s a something with the Arch/Manjaro packaging or not… I’ll do some testing and report back when I can.

4

So, sushi in Gnome OS Nightly won’t preview videos at all.

I did notice that the current maintainer is trying to hand it off, and has been since April. I hope some one steps up and can continue development.

Nothing else of interest to report…will chip away at this.

For now, enjoy the holidays!

5

It works on my system. I have even tried multiple video formats.

sushi 43.0-1
nautilus 43.1-1
1 Like
6

Curious if this is a Nvidia/AMD difference. Any chance you are using a Nvidia GPU?

I just fired up a fresh Arch VM to check my sanity and had the same problem where video in sushi previews only have sound and display a black preview.

Edit: I take it back, just tested with an AV1 to make sure it isn’'t anything to do with the h264 nonsense. Noticed the same issue and Totem is actually having problems playing videos…more investigation!

Edit 2: Following the Totem trail led me to this Arch bug report. So I went over to X11 and everything worked! sushi previewed videos perfectly fine. So we now know it’s something on the Wayland side.

2 Likes
7

wow, great detective work! :1st_place_medal:

I had created a gitlab issue for sushi, if you would like to add your findings.

8

Yes. I have tested with an nvidia gpu + X11.

I have just tried a nested wayland session, and it seems to work there as well.

env GNOME_SHELL_SLOWDOWN_FACTOR=2 \ 
    MUTTER_DEBUG_DUMMY_MODE_SPECS=1024x768 \
    dbus-run-session -- gnome-shell --nested \
                                    --wayland
9

I went ahead and provided as much information as I could think of for the upstream report. :slight_smile:

I really appreciate you giving this a whirl for us. Hopefully the discrepencies can help track this down.

1 Like
10

I truly think the sushi issue is linked with the totem issue. And after doing some digging around it seems our woes might have to do with a mesa 22.3.1 regression.

11

Thanks for the update. Thinking back to when I posted, it happened with the 2nd batch of updates after Gnome 43.2 & I seem to remember seeing mesa in that bunch & hoping there might be some improved video. Im sure you are right. Lets hope its not a long wait.

12

Hopefully it isn’t too poor form to revisist this thread. It’s been on-going tracking the issue. Currently it looks like the fix will be somewhere in GTK, following this discussion.

I have found a temporary solution until it gets fixed, place the following as an environment variable in ~/.zshenv:

mesa_glthread=false

For quick testing since our original problem can be shown in totem (Videos) as well, you can launch it with terminal:

mesa_glthread=false totem
13

I saw your comment to the gitlab thread actually.
Perhaps I did something wrong, but it had no effect for me.

I created the file ~/.zshenv because it didn’t exist, added the line as specified, rebooted. the problem remains.
I also tried adding the variable temporarily by just adding it to terminal directly, but there was no change to sushi video blank.

14

Yeah running nautilus from terminal with the variable didn’t seem to change sushi’s ability to preview videos, but the totem test worked for me.

You could try adding export in your ~/.zshenv to see if it makes any difference for you. A logout and back in should suffice.

export mesa_glthread=false

I chose totem as the quick terminal test as it displayed the same behavior sushi did. So running:

mesa_glthread=false totem

I was able to play a video that sushi couldn’t preview. Of course make sure that same video won’t play in totem too.

The GTK/GL disucssion has been crazy heating up on where the problem lies with this issue. But there has been a merge with a “solution”. So a gtk3 point release coming sometime might fix this.

15

That did it! thanks :v:

16

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.