Garbage occurred when Playing the video in the Ubuntu Desktop Guide

upload video which this issue was happening

Thanks for your report! I can't even play it once. :(

The web version seems to work, though:

https://help.ubuntu.com/18.04/ubuntu-help/getting-started.html

Same problem in the current development version (disco).

Terminal output when attempting to run the "Launch applications" video in disco:

$ yelp help:gnome-help
Xlib: sequence lost (0x100e0 > 0xe2) in reply type 0x0!
Xlib: sequence lost (0x100e5 > 0xe7) in reply type 0x0!
Xlib: sequence lost (0x100ea > 0xec) in reply type 0x0!
Xlib: sequence lost (0x100ef > 0xf1) in reply type 0x0!
Xlib: sequence lost (0x100f4 > 0xf6) in reply type 0x0!
Xlib: sequence lost (0x100dc > 0xf6) in reply type 0x0!
Xlib: sequence lost (0x10152 > 0x155) in reply type 0x0!
Xlib: sequence lost (0x10182 > 0x18e) in reply type 0x0!
WebKitWebProcess: ../nouveau/pushbuf.c:723: nouveau_pushbuf_data: Assertion `kref' failed.

On my desktop 18.04 computer this happens for all the videos that I have tried (3 of the 5 so far).

And yes, the web versions seem to work fine, which suggest to me that this is a yelp problem and not a docs problem.

@Gunnar: I do see "WebKitWebProcess" using the most CPU during video play.

The problem seems not to be Ubuntu specific.

https://bugzilla.redhat.com/show_bug.cgi?id=1696788

(I get those "Recursion depth exceeded calculating {bg,fg} color" messages too on eoan and disco.

I think this bug needs attention by the desktop team, so I added the rls-ee-incoming tag. If this cannot be fixed, we should consider to drop gnome-getting-started-docs from the seed.

While the bug is annoying it's not a core feature/blocking work, we should fix it but it's not going to tracked as rls issue

Using disco the videos play fine here so it's not impacting every config

On 2019-05-16 17:48, Sebastien Bacher wrote:
> Using disco the videos play fine here

Same here nowadays - but only sometimes. And my disco is anything but a clean install; I use NVIDIA for instance.

So I tried NVIDIA on my eoan install - nope. (It does obviously not show the same error messages as I reported in comment #6, but it rather hangs.)

I revived an old LapTop, that had Desktop 18.04 on it. Updated to current 18.04.
Verified that this video issue was present.
Upgraded the computer to 18.10.
Ran one help video about 15 times without any issues.
Upgraded the computer to 19.04.
Ran the video only 2 times before it messed up. It messed up every time thereafter.

I am not aware that I did anything different between the 18.04, 18.10 and 19.04 help video tests.

@Doug: Are you using Nouveau or some other graphics driver?

I have also done some further testing - on 18.04, 19.04 and eoan. Basically it works (most of the time) if I use NVIDIA, but fails when I use Nouveau.

The computer I'm using is old (~ 10 years) and is getting 'tired'. Possibly it would have worked with newer more powerful hardware.

Bug #1499419 and bug #1553328 seem kind of related.

@Olivier and @Daniel: Do you possibly have an idea how to deal with this issue? Can yelp be modified somehow?

@Gunnar asked:

> @Doug: Are you using Nouveau or some other graphics driver?

Both desktop computers (one an old MAC with 18.04, and one the old HP LapTop I revived the other day with (now) 19.04) are using Radeon drivers. From the command you gave me off-list:

$ lspci -nnk | grep -i vga -A3 | grep 'in use'
        Kernel driver in use: radeon

Attached is an edited (core dump removed) crash dump file from a yelp crash while trying to "save video as", as per note 2 in the bug description. The interesting stuff starts at line 2019:

2019: May 17 13:48:42 cyd-hp2 yelp[3740]: Invalid UTF-8 string passed to pango_layout_set_text()

The originating error was:

yelp assert failure: free(): double free detected in tcache 2

Comment #6 only demonstrates a nouveau bug. That is bug 1553328, or https://bugs.freedesktop.org/show_bug.cgi?id=92438 whereby nouveau is not thread safe. It's a very old issue so if you experience that my best advice is to just avoid nouveau.

But that wasn't from the original reporter...

hugh, please run this command in a terminal:

  yelp help:gnome-help

and tell us what you see in the terminal text window.

hugh: Please also run this command:

  lspci -k > lspcik.txt

and send us the resulting file 'lspcik.txt'.

I have 3 computers running Ubuntu desktop edition:
An old HP LapTop, 19.04;
An old Apple iMac, 18.04;
And a VM, 18.04, running on my main Ubuntu 16.04 test server.
All 3 have the issues, with one main difference in the 19.04 verses 18.04 "play again" stimulus response.

Attached is the "lspci -k > lspcik.txt" information for all 3 combined into the one file.

Note: I almost always jump to the last few seconds when playing the video, to save time. I have never noticed any difference in system response for subsequent video playing when jumping to near the end verses letting it just play to the end.

For: "yelp help:gnome-help": There are sometimes a few of these, and more on the HP:

Xlib: sequence lost (0x100f2 > 0xf4) in reply type 0x0!

Responses from a new terminal execution of: "yelp help:gnome-help":

0 <= integer N <= infinity (actually tested to N = 4)

Do N times{
  wait > 60 seconds after the video finishes
  play the video again.
  The video plays correctly.
}
wait < 57 seconds after the video finishes
play the video again.
The video plays correctly on the iMac and the VM, both 18.04, but incorrectly on the HP, 19.04.
Now wait either less than 57 seconds or more than 60 seconds and then play the video again.
If the wait was < 57 seconds then the video plays incorrectly now and thereafter, no matter the time waited between plays.
If the wait was > 60 seconds then the video plays correctly now and thereafter, no matter the time waited between plays.

The VM that I revived had not been run or updated since an early development version of 18.04, and it worked fine for playing the help videos. When I updated it, the yelp package did not update, but webkit did:

doug@desk-aa:~$ grep -i webkit /var/log/apt/term.log | grep over
Unpacking libwebkit2gtk-4.0-37:amd64 (2.24.1-0ubuntu0.18.04.1) over (2.20.1-1) ...
Unpacking gir1.2-webkit2-4.0:amd64 (2.24.1-0ubuntu0.18.04.1) over (2.20.1-1) ...

After the update to current package versions, the help video issue was present.
I looked at the changelog at https://launchpad.net/ubuntu/+source/webkit2gtk/+changelog
but am not familiar with this stuff and didn't notice anything, but probably wouldn't have anyhow.

@Daniel,

Sure I will provide the log tomorrow

@Daniel:

The bug is about failures to view the gnome-getting-started-docs videos via yelp. We (at least I) have learned that the videos can't be viewed properly with certain combinations of graphics cards and drivers.

So besides nailing which hardware/driver combination the bug reporter is using - and hopefully fix that issue - I think it's relevant to try to estimate how many users are facing similar failures. Please note that Ubuntu is shipped with a yelp icon in the dock, and the very first link on the index page leads to the page with the videos.

@Gunnar, one way to look at it is that the issue has one report, not a lot of activity and no duplicate which hints it's low importance (or that the users who have issues with don't know how to reach out to us)

On 2019.05.26 19:18 Daniel van Vugt wrote:
> This bug might be getting confused...

I disagree.

> Doug: You are reporting problems with the radeon
> graphics driver,

No, I am providing additional information in support of the original bug report, proving that the issue occurs on multiple platforms and appears to be somewhat independent of the graphics driver involved.

> and vmware.

I don't use vmware. It was a kvm/libvirt/qemu type VM.

> hugh: Please answer comment #20. Your feedback is most needed here.

Given that hugh did not reply, I did and consider my feedback on this bug report to be just as important.

By the way, reverse engineering the system response to the "play again" stimulus, was not an easy task, but I believe provides insight.

@Doug,

please find attached the "lspcik.txt",
and I didn't see anything on terminal after running below command:

yelp help:gnome-help

@hugh: Looks like you forgot to attach the file.

@Sebastien: Yeah, the lack of duplicates is a fact. It may indicate that relatively few users are affected by the problem, or that few users read docs on disk...

sorry I forgot to attach the file...