Bug 89195 - [GStreamer][OGG] Unreliable seek to unbuffered regions when using Jamendo
Summary: [GStreamer][OGG] Unreliable seek to unbuffered regions when using Jamendo
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-15 03:35 PDT by v_2e
Modified: 2020-03-25 08:00 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description v_2e 2012-06-15 03:35:24 PDT
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
Comment 1 Lionir 2019-05-12 21:52:01 PDT
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
Comment 2 Philippe Normand 2019-08-23 04:07:12 PDT
Works here in Ephy 3.33.91-12-g0782ce4ef Powered by WebKitGTK 2.25.4
Comment 3 Lionir 2020-03-21 19:19:02 PDT
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.
Comment 4 Philippe Normand 2020-03-22 03:06:48 PDT
Works here in Ephy 3.36.0-24-g11cc94492 / WKGTK 2.28.
Comment 5 Michael Catanzaro 2020-03-22 09:57:15 PDT
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
Comment 6 Lionir 2020-03-22 12:59:08 PDT
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?
Comment 7 Lionir 2020-03-22 15:40:30 PDT
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.
Comment 8 Michael Catanzaro 2020-03-22 16:13:43 PDT
(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. ;)
Comment 9 Lionir 2020-03-22 16:28:30 PDT
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. ;)
Comment 10 Philippe Normand 2020-03-23 03:36:33 PDT
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...
Comment 11 Philippe Normand 2020-03-23 03:42:46 PDT
(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.