Totem unable to play video: "The specified movie could not be found"

[Dave Jones]

As part of our ISO testing for the Pi desktop, we attempt to play https://archive.org/download/BigBuckBunny_124/Content/big_buck_bunny_720p_surround.mp4 with the shipped totem video player. Unfortunately, on the current Jammy image, totem simply reports "The specified movie could not be found" when attempting to play the file (the exit code is 0, no other errors are reported at the command line).

I've attempted to install a few gstreamer codecs, in case that might've been the issue (this was necessary on some older versions), but neither gstreamer1.0-plugins-ugly, nor gstreamer1.0-libav made any difference. Just to ensure the video file was intact and playable, I then installed vlc from the archive, which played the video happily.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1969512

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sebastien Bacher (seb128)]

Thank you for your bug report, it seems similar to https://gitlab.gnome.org/GNOME/totem/-/issues/509

[Sebastien Bacher (seb128)]

It works fine on an amd64 desktop, some questions

1. Do you download and try to play locally or do you provide the https URL to totem?

2. do you get more output if you do
$ G_MESSAGES_DEBUG=all totem

3. could you try to
$ G_DEBUG=fatal_warnings totem

and if it's crashing, report the bug or provide the stacktrace

[Dave Jones (waveform)]

We download and try to play locally (see item 12 in http://iso.qa.ubuntu.com/qatracker/milestones/432/builds/247134/testcases/1747/results for an example). I'll try and get some DEBUG output this morning (I can state it's definitely not crashing though; the error message simply appears and totem remains open, without playing anything, until closed).

[Dave Jones (waveform)]

Hmm, some interesting updates here. Firstly, here's the output from totem when run with "G_MESSAGES_DEBUG=all":

(totem:38425): GLib-GIO-DEBUG: 11:13:06.494: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
(totem:38425): dconf-DEBUG: 11:13:06.495: watch_fast: "/org/gnome/Totem/" (establishing: 0, active: 0)
(totem:38425): dconf-DEBUG: 11:13:06.503: watch_established: "/org/gnome/Totem/" (establishing: 1)
(totem:38425): dconf-DEBUG: 11:13:06.530: watch_fast: "/org/gnome/desktop/interface/" (establishing: 0, active: 0)
(totem:38425): dconf-DEBUG: 11:13:06.530: watch_fast: "/org/gnome/desktop/peripherals/mouse/" (establishing: 0, active: 0)
(totem:38425): dconf-DEBUG: 11:13:06.530: watch_fast: "/org/gnome/desktop/sound/" (establishing: 0, active: 0)
(totem:38425): dconf-DEBUG: 11:13:06.531: watch_fast: "/org/gnome/desktop/privacy/" (establishing: 0, active: 0)
(totem:38425): dconf-DEBUG: 11:13:06.531: watch_fast: "/org/gnome/desktop/wm/preferences/" (establishing: 0, active: 0)
(totem:38425): dconf-DEBUG: 11:13:06.531: watch_fast: "/org/gnome/settings-daemon/plugins/xsettings/" (establishing: 0, active: 0)
(totem:38425): dconf-DEBUG: 11:13:06.531: watch_fast: "/org/gnome/desktop/a11y/" (establishing: 0, active: 0)
(totem:38425): dconf-DEBUG: 11:13:06.531: watch_fast: "/org/gnome/desktop/a11y/interface/" (establishing: 0, active: 0)
(totem:38425): dconf-DEBUG: 11:13:06.532: watch_established: "/org/gnome/desktop/interface/" (establishing: 1)
(totem:38425): dconf-DEBUG: 11:13:06.532: watch_established: "/org/gnome/desktop/peripherals/mouse/" (establishing: 1)
(totem:38425): dconf-DEBUG: 11:13:06.534: watch_established: "/org/gnome/desktop/sound/" (establishing: 1)
(totem:38425): dconf-DEBUG: 11:13:06.534: watch_established: "/org/gnome/desktop/privacy/" (establishing: 1)
(totem:38425): dconf-DEBUG: 11:13:06.534: watch_established: "/org/gnome/desktop/wm/preferences/" (establishing: 1)
(totem:38425): dconf-DEBUG: 11:13:06.535: watch_established: "/org/gnome/settings-daemon/plugins/xsettings/" (establishing: 1)
(totem:38425): dconf-DEBUG: 11:13:06.535: watch_established: "/org/gnome/desktop/a11y/" (establishing: 1)
(totem:38425): dconf-DEBUG: 11:13:06.535: watch_established: "/org/gnome/desktop/a11y/interface/" (establishing: 1)
(totem:38425): GLib-GIO-DEBUG: 11:13:06.678: _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ‘gio-vfs’
(totem:38425): GLib-DEBUG: 11:13:06.793: unsetenv() is not thread-safe and should not be used after threads are created
(totem:38425): Gtk-DEBUG: 11:13:06.793: Connecting to session manager
(totem:38425): Handy-DEBUG: 11:13:06.797: Trying to initialize portal
(totem:38425): dconf-DEBUG: 11:13:07.282: watch_fast: "/org/gnome/Totem/" (establishing: 0, active: 1)
(totem:38425): dconf-DEBUG: 11:13:07.282: watch_fast: "/org/gnome/desktop/lockdown/" (establishing: 0, active: 0)
(totem:38425): dconf-DEBUG: 11:13:07.283: watch_established: "/org/gnome/desktop/lockdown/" (establishing: 1)
(totem:38425): dconf-DEBUG: 11:13:07.549: watch_fast: "/org/gnome/desktop/thumbnailers/" (establishing: 0, active: 0)
(totem:38425): dconf-DEBUG: 11:13:07.550:...

[Sebastien Bacher (seb128)]

Thanks Dave. The error report didn't get an useful stacktrace though. The error also suggests that a valgrind log would be needed. Could you perhaps install the debug packages and get a debug log?

[Florian Echtler (floe)]

I'm pretty sure this is not a Totem issue, but rather a GStreamer issue.

E.g. for the linked video, if I try to play it through playbin on Jammy (`gst-launch-1.0 playbin uri=file:///home/floe/Downloads/big_buck_bunny_720p_surround.mp4`), I get a black window with the audio track playing in the background. Same happens for any movie that also has the same issue with Totem.

Running with GST_DEBUG=3 gives a lot of
```
0:00:00.381581482 183712 0x7f5f6c05b640 ERROR vaapivideomemory gstvaapivideomemory.c:254:map_vaapi_memory: failed to make image current
0:00:00.381663666 183712 0x7f5f6c05b640 ERROR default video-frame.c:168:gst_video_frame_map_id: failed to map video frame plane 0
0:00:00.381711318 183712 0x7f5f6c05b640 WARN xvimagesink xvimagesink.c:1038:gst_xv_image_sink_show_frame:<xvimagesink0> could not map image
```
so this may be VAAPI-related?

[Florian Echtler (floe)]

Update: can confirm that this issue can be worked around by uninstalling gstreamer1.0-vaapi package.

[Florian Echtler (floe)]

One more datapoint, vlc seems to be using VAAPI on the same machine & distro without issues:

```
$ vlc big_buck_bunny_720p_surround.mp4
VLC media player 3.0.16 Vetinari (revision 3.0.13-8-g41878ff4f2)
[000055cebcc6f580] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[00007f9b1c003e50] gl gl: Initialized libplacebo v4.192.1 (API v192)
libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
[00007f9b39141220] avcodec decoder: Using Intel iHD driver for Intel(R) Gen Graphics - 22.3.1 () for hardware decoding
```

[Dave Jones (waveform)]

@floe -- thanks for the extra info! Unfortunately I'm not sure this is a gstreamer issue (or more precisely, there may well be a gstreamer issue on amd64, but it doesn't appear to be the case on arm64 with the Pi Desktop image). gstreamer1.0-vaapi isn't seeded on the Pi Desktop images, and indeed running your gst-launch reproducer plays the video happily with no mention of gstvaapi in the console output. Just in case it's useful, here's the output I saw:

GST_DEBUG=3 gst-launch-1.0 playbin uri=file:///$HOME/big_buck_bunny_720p_surround.mp4
Setting pipeline to PAUSED ...
0:00:00.045303856 31845 0xaaaaf25f9240 WARN basesrc gstbasesrc.c:3688:gst_base_src_start_complete:<source> pad not activated yet
0:00:00.046280739 31845 0xaaaaf25f9240 WARN basesrc gstbasesrc.c:3688:gst_base_src_start_complete:<source> pad not activated yet
Pipeline is PREROLLING ...
0:00:00.096946452 31845 0xaaaaf260eb60 WARN qtdemux qtdemux.c:3121:qtdemux_parse_trex:<qtdemux0> failed to find fragment defaults for stream 1
0:00:00.097408468 31845 0xaaaaf260eb60 WARN qtdemux qtdemux.c:3121:qtdemux_parse_trex:<qtdemux0> failed to find fragment defaults for stream 2
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstPulseSinkClock
Redistribute latency...

About 9 seconds in I closed the window (which was correctly playing the video, and audio), which produced the output:

0:00:09.474384373 31845 0xffff902bc120 WARN xvimagesink xvimagesink.c:568:gst_xv_image_sink_handle_xevents:<xvimagesink0> error: Output window was closed
ERROR: from element /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:vbin/GstXvImageSink:xvimagesink0: Output window was closed
Additional debug info:
../sys/xvimage/xvimagesink.c(568): gst_xv_image_sink_handle_xevents (): /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:vbin/GstXvImageSink:xvimagesink0
Execution ended after 0:00:09.137470426
Setting pipeline to NULL ...
0:00:09.477803649 31845 0xffff800609e0 WARN xvimagesink xvimagesink.c:1045:gst_xv_image_sink_show_frame:<xvimagesink0> could not output image - no window
0:00:09.478389497 31845 0xaaaaf260eb60 WARN qtdemux qtdemux.c:6747:gst_qtdemux_loop:<qtdemux0> error: Internal data stream error.
0:00:09.478468497 31845 0xaaaaf260eb60 WARN qtdemux qtdemux.c:6747:gst_qtdemux_loop:<qtdemux0> error: streaming stopped, reason error (-5)
ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0: Internal data stream error.
Additional debug info:
../gst/isomp4/qtdemux.c(6747): gst_qtdemux_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0:
streaming stopped, reason error (-5)
Freeing pipeline ...

Admittedly, this was on my usual Pi desktop; I'll try it on an entirely fresh card in a bit (as I need to do that to respond to seb128's request for a proper stacktrace), but I suspect the result will be similar. Still, it may be worth opening a separate bug for the gstvaapi case...

[Sebastien Bacher (seb128)]

The vaapi issue seems a different one indeed, please open a new report

[Steve Nyemba (nyemba)]

I have encountered the issue and have a fix for it:

1- Install VLC and worry about nothing.

2- get gstreamer1.0-vaapi_1.16.2-2_amd64.deb (from 20.04) and install it (it's a downgrade) it will complain upon installation but it will work.

Disclaimer:
While it fixes the issue with totem, I haven't tested what it will do system wide. I will be reporting soon.

[Florian Echtler (floe)]

OK, have also reported this against gstreamer-vaapi as https://bugs.launchpad.net/ubuntu/+source/gstreamer-vaapi/+bug/1971463

[Dave Jones (waveform)]

I've now installed the -dbg packages in an attempt to get a proper stacktrace (as requested by seb128); unfortunately try as I might I've been unable to re-create the crash I experienced a couple of weeks ago. Totem still fails to play anything (same message, same debug output as previously reported), but no crashes.

One thing I have noted, after retrying on a freshly flashed card is that using gst-launch directly fails initially, complaining that it's lacking the AAC codec (perhaps I should amend the ISO test case to use an OGG instead -- though I have a feeling this *used* to work, maybe it prompted to install the necessary codec). Still, installing gstreamer1.0-libav fixes this and gst-launch then happily plays the video (and audio), whilst totem still fails with the aforementioned message.

I'll keep trying to get a proper stacktrace, but at this point I'd say it's likely unrelated to totem's failure to play the video (given there's evidently no issue with gstreamer itself playing the video otherwise, and totem still fails to play the video even when no crash occurs).

[Sebastien Bacher (seb128)]

@Dave, thanks for trying. Do you get some warnings from totem? If so you might be able to get a backtrace as described on https://gitlab.gnome.org/GNOME/totem/-/issues/509#note_1408065

[Dave Jones (waveform)]

Unfortunately we've tried "G_DEBUG=fatal_warnings" before (you suggested it back in comment:4) but I did manage to figure out a couple of things since last time:

The crash I originally observed (back in comment:6) only occurs on the very first run of totem. All subsequent runs (even after a reboot) fail to crash (which makes me suspect the crash is a result of something that's missing on that first run ... maybe something that gets written to the user's home-dir or cache or something? I should try deleting ~/.cache and see what happens). All subsequent runs still display the issue described in the bug (that the video won't play with "the specified movie could not be found" error) but don't actually crash. That also makes me suspect that the crash might not be related to the issue of the movie not playing.

Nonetheless, once I had the ability to reliably reproduce the crash (albeit with the annoyance of having to re-flash the card each time), I did manage to get totem to crash with the totem-dbgsym (and libtotem0-dbgsym, and libgstreamer1.0-0-dbgsym, and basically any other vaguely related -dbgsym I could think of) installed. Unfortunately the results were ... not exactly useful:

https://errors.ubuntu.com/oops/7cd5149e-d1db-11ec-9a6d-fa163e55efd0

Here's another OOPS report which *did* get a partial stacktrace, but unfortunately I'd forgotten to install the -dbgsym package on this one (was kicking myself after realizing I had to re-flash the card *again*!):

https://errors.ubuntu.com/oops/58aa5662-d1cf-11ec-8c2d-fa163e993415

Sorry these probably aren't much use in shedding any further light on the problem! On the other hand, the fact the crash doesn't occur after the first run makes me think that perhaps I'm barking up the wrong tree here (that the crash is distinct from the failure to play the video file).

[Dave Jones (waveform)]

An additional data point; I noted in the linked gitlab bug a couple of messages noting that "it works with the flatpak". Out of curiosity (as to whether this might be a well and truly arm64 specific problem), I tried the flatpak on the pi desktop and: it's got exactly the same problem (same behaviour, same message, etc). So I'm currently thinking this is *not* distro-specific to Ubuntu, but I'm certainly considering that this is possibly arch-specific to arm64 (or possibly just non-amd64? Not sure).

[Chris Hall (cmhallmi)]

This bug may be mutter/wayland related as the player seems to work in xorg but not wayland.

[Sebastien Bacher (seb128)]

Thanks Dave, if you get the issue using the flatpak could you perhaps report it upstream on gitlab?

[Samuel Simon (simon-ximon)]

Run this command:

sudo apt remove gstreamer1.0-vaapi

Got my solution from this article, check it out too.
https://www.makeuseof.com/things-to-do-after-upgrading-to-ubuntu-2204-lts/

[XA Hydra (xa-hydra)]

Got my hopes up for that easy fix, but I discovered that I don't have gstreamer1.0-vaapi installed and I am still having this problem. I have only had it in wayland. X seems to work fine for me.

[Dave Jones (waveform)]

@Samuel that fix is for PCs which is a different bug (LP: #1971463); this bug is about totem on the Pi desktop images (or, I'm beginning to suspect, arm64 more generally).

[Samuel Simon (simon-ximon)]

@Dave @XA Okay. It worked for me though. Just hope it wasn't a temporary fix.

[Dave Jones (waveform)]

Reported issue with flatpak (under arm64) upstream: https://gitlab.gnome.org/GNOME/totem/-/issues/509#note_1468424 (after re-testing just to confirm that the issue still occurred).

[Sebastien Bacher (seb128)]

New upstream report, https://gitlab.gnome.org/GNOME/totem/-/issues/523

which also has to do with https://gitlab.gnome.org/GNOME/gtk/-/issues/2619

GTK doesn't handle opengl < 3.0 correctly, which seems to be the same on the raspi? Does setting MESA_GL_VERSION_OVERRIDE=3.3 workaround the issue?

[Daniel van Vugt (vanvugt)]

I wonder if https://gitlab.gnome.org/GNOME/gtk/-/issues/4950 is related to that (trying to use GLES version 2).

[Dave Jones (waveform)]

@seb128 yes, the following command line plays (for at least 20 seconds -- I didn't watch the whole thing) happily under totem:

MESA_GL_VERSION_OVERRIDE=3.3 totem big_buck_bunny_720p_surround.mp4

So the issue is simply that the pi's GL driver only goes up to 2.1, and/or that GTK doesn't accept GL<3.0 (my vague understanding of the graphics situation on the pi is that the GLES driver has (had?) rather better support than GL, but that Vulkan was the real focus of development efforts -- https://www.raspberrypi.com/news/vulkan-update-version-1-1-conformance-for-raspberry-pi-4/ has some more info on that).

[GreenLeaf (drmac)]

New report: The Videos app will not play .mp4 files comes up with error "The specified movie could not be found.", they play OK on VSCode & Kdenlive, using Ubuntu 22.04, worked OK on 20.04.5

[Leó Kolbeinsson (leok)]

Received this error testing Ubuntu Jammy image dated 2023-02-17.1

[Dave Jones (waveform)]

I'd say this is effectively "Fix Released" at this point in that on lunar (and kinetic? Sorry, I forgot to re-test this before upgrading the old drive), Totem now fails to play the video with "could not initialize OpenGL support" which is the "fix" implemented upstream (and reflected by the upstream tracker).

LP: #1998782 has been filed with this new message so I'll point to that one in the ISO tracker for the current lunar beta.