1. Go to http://radio.dos.nl/ 2. Click on the menu button on the lower right corner 3. Select "Jazz" 4. Click on the "Bert's Bytes" icon. This should play this radio stream, but it does nothing with WebKitGTK 2.24.2. It reportedly works fine with 2.24.0 and fails with 2.24.1. It is likely related to bug 197410. This bug was originally reported in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929749
(In reply to Alberto Garcia from comment #0) > 2. Click on the menu button on the lower right corner Sorry, I meant the lower *LEFT* corner.
That's not a live stream though, http://www.bertvandenbrink.com/bertsbytes/concert.mp3
No, it's not a live stream, but 2.24.0 plays it and 2.24.1 does not. Richard
Actually it might if you wait long enough :D It's an issue with the on-disk buffering, I started a patch.
Created attachment 373217 [details] Patch
Comment on attachment 373217 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=373217&action=review > Source/WebCore/ChangeLog:16 > + No new tests, existing media tests cover this patch. Why is no test turning green associated with the bug then? > Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:1474 > + auto updateMaxTimeLoaded = [&]() { Sometimes it is hard to choose when to use a lambda like this or just another regular object method. My preference in this case would be the latter. > Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:1508 > + case GST_BUFFERING_TIMESHIFT: > + case GST_BUFFERING_LIVE: maybe just "default:" ?
Comment on attachment 373217 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=373217&action=review >> Source/WebCore/ChangeLog:16 >> + No new tests, existing media tests cover this patch. > > Why is no test turning green associated with the bug then? There is no test and there should be. I know we are in a hurry for the release, so let's land it and open a bug for the test.
I am testing gtk queue on new EWS and it seems to fail for this patch. Can someone look if EWS caught a real issue or it's a false positive? https://ews-build.webkit-uat.org/#/builders/7/builds/281 Retry: https://ews-build.webkit-uat.org/#/builders/7/builds/282
(In reply to Aakash Jain from comment #8) > I am testing gtk queue on new EWS and it seems to fail for this patch. > > Can someone look if EWS caught a real issue or it's a false positive? > > https://ews-build.webkit-uat.org/#/builders/7/builds/281 > Retry: https://ews-build.webkit-uat.org/#/builders/7/builds/282 I'll check it, thanks for the heads-up!
It's a WPE issue, not GTK. I forgot an include: GLibUtilities.h:38:15: error: ‘GUniquePtr’ does not name a type; did you mean ‘GUniquePtr_h’?
(In reply to Philippe Normand from comment #10) > It's a WPE issue, not GTK. Yeah, I confused that. Thanks for the correction.
Created attachment 373236 [details] Patch
Comment on attachment 373236 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=373236&action=review > Source/WTF/wtf/glib/GUniquePtr.h:27 > +#include <memory.h> That was the EWS issue I think. Let's see if EWS likes it now.
Still red, I'll check it :)
Created attachment 373239 [details] Patch
One of those weird issues with Forwarding headers and unified builds :(
Created attachment 373242 [details] Patch
Committed r247010: <https://trac.webkit.org/changeset/247010>