Bug 89195 – [GStreamer][OGG] Unreliable seek to unbuffered regions when using Jamendo

• Component: WebKitGTK
• Status: RESOLVED WORKSFORME

Hello!
They recently created a new JavaScript player on Jamendo.com and now it does not work in Midori web browser (which is built upon Webkit-GTK).
Webkit-GTK version installed on my system is 1.8.1.

I hope there is a way to fix this issue.

Regards, 
  Vladimir

[Lionir]

While I don't doubt they've changed quite a bit from when this issue was made, this issue is still present on :

Epiphany version : 3.33.1-2b3776d2
Webkit version : WebKitGTK 2.24.1

[Philippe Normand]

Works here in Ephy 3.33.91-12-g0782ce4ef Powered by WebKitGTK 2.25.4

[Lionir]

This is still present here in Epiphany 3.36.0-27-g2a31b3fdc powered by WebKitGTK 2.28.0.

Steps to reproduce would be : 

1. Go to for example : https://www.jamendo.com/artist/355621/emerald-cave
2. Clicking play will work and will also change track if you let it do so
3. Trying to move in the seekbar

After trying to move in the seekbar, the song will song playing and the whole page will freeze and not let you scroll.

[Philippe Normand]

Works here in Ephy 3.36.0-24-g11cc94492 / WKGTK 2.28.

[Michael Catanzaro]

Works for me too, with 3.36.0-26.

So we all have effectively the same browser version (as none of the changes there could possibly be related). So the most likely cause for different behavior would be different runtime version, I guess. I have:

$ flatpak info org.gnome.Platform//master

GNOME Application Platform version master - Shared libraries used by GNOME
applications

           ID: org.gnome.Platform
          Ref: runtime/org.gnome.Platform/x86_64/master
         Arch: x86_64
       Branch: master
      License: GPL-2.0+
       Origin: gnome-nightly
   Collection: org.gnome.Nightly
 Installation: user
    Installed: 939.5 MB

Active commit: 70de0d981e4d158e3d377ee7fcd8334d7998706734202952b693a685aa49f8d6
Latest commit: 3b9eb74b56793abb8f3a51090465c4c238c6194648cb5b4e711405da0d080207
       Parent: f748811f8e3fdd6f55d7257115b1f6e8e7d902c7e1fe1fd74eb9c4dc231e5c4a
      Subject: Export org.gnome.Platform
         Date: 2020-03-19 14:43:18 +0000

[Lionir]

Here I have : 

$ flatpak info org.gnome.Platform//master

GNOME Application Platform version master - Shared libraries used by GNOME
applications

          ID: org.gnome.Platform
         Ref: runtime/org.gnome.Platform/x86_64/master
        Arch: x86_64
      Branch: master
     License: GPL-2.0+
      Origin: gnome-nightly
  Collection: org.gnome.Nightly
Installation: system
   Installed: 939.5 MB

      Commit: 3b9eb74b56793abb8f3a51090465c4c238c6194648cb5b4e711405da0d080207
      Parent: 93b9df3afc0c0933f4264f99f57a56f09b997ca8ab3c7ccfe7aec5fe1b643674
     Subject: Export org.gnome.Platform
        Date: 2020-03-21 14:12:05 +0000

I will make a video to showcase the issue since perhaps this is simply a misunderstanding in how the issue manifests and how to reproduce it (as I've started doing more recently with two other issues). Does that sound good?

[Lionir]

Well, I did a video anyways.

Here it is with the timestamp : https://youtu.be/0UqJGq0zcBk?t=35

It seems to be related with the fact that I change the position on the seekbar rapidly.

[Michael Catanzaro]

(In reply to azeikui6ziwjypjgu5w2tixgcxdaapxx from comment #7)
> It seems to be related with the fact that I change the position on the
> seekbar rapidly.

Yup, should have said that at first! Now I can reproduce the bug. I think the web process is probably hung.

BTW, there are a LOT more WebKit bugs with that YouTube link:

 * Video never starts playing
 * Spinner continues spinning even if I pause the video
 * Seeking the video generally does nothing
 * If I seek near to the start of the video, only then does it start playing
 * Video occasionally flashes and briefly displays an old frame (I'm guessing this is a decoding problem and not an issue with your video itself?)
 * If I switch to theater mode, the video turns completely black

That's not even counting the other video playback issues you demonstrated at the start of the video. It's enough to wonder if your faith may be misplaced. ;)

[Lionir]

Huh.. I had not tested the timestamped link...

The video totally works without the timestamp so that's a good way to reproduce. Should I open an issue?

> That's not even counting the other video playback issues you demonstrated at the start of the video. It's enough to wonder if your faith may be misplaced. ;)

Honestly, the tab switching being so snappy, the window resizing performance, the search bar results feeling so smooth, the back/forward gestures feeling magical. These things alone make sure I can never look away. ;)

[Philippe Normand]

The issue happens when seeking to an unbuffered position it seems. As this is OGG, sadly I'm not sure we can do much, that format is known to have seek issues...

[Philippe Normand]

(In reply to Lionir from comment #9)
> Huh.. I had not tested the timestamped link...
> 
> The video totally works without the timestamp so that's a good way to
> reproduce. Should I open an issue?
> 

Seek in MSE videos is currently unreliable. No need to open a new issue about this.

[Xabier Rodríguez Calvar]

It is working now on ToT