webbrowser-app

grooveshark playback has stopped functioning

Bug #1301341 reported by Dave Morley
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Oxide
Fix Released
Undecided
Unassigned
webbrowser-app
Invalid
Undecided
Unassigned
oxide-qt (Ubuntu)
Fix Released
High
Unassigned

Bug Description

STEPS:
1. Move to the music scope
2. Select an online track from grooveshark
3. Select play in grooveshark
4. Once grooveshark opens in the browser select the track to play

EXPECTED:
Musc starts to play

ACTUAL:
The player looks like it is stating up but then actually plays nothing

Revision history for this message
Olivier Tilloy (osomon) wrote :

I’m seeing a few messages in the logs:

[0404/094150:INFO:CONSOLE(1)] "localStorage read error:", source: http://html5.grooveshark.com/build/app.min.js?1394645215 (1)
[0404/094150:INFO:CONSOLE(1)] "localStorage read error:", source: http://html5.grooveshark.com/build/app.min.js?1394645215 (1)
[0404/094150:INFO:CONSOLE(1)] "localStorage read error:", source: http://html5.grooveshark.com/build/app.min.js?1394645215 (1)
[0404/094151:INFO:CONSOLE(1)] "localStorage write error:", source: http://html5.grooveshark.com/build/app.min.js?1394645215 (1)
Detectable autorepeat not supported.
[0404/094158:INFO:CONSOLE(1)] "localStorage read error:", source: http://html5.grooveshark.com/build/app.min.js?1394645215 (1)
[0404/094158:INFO:CONSOLE(1)] "localStorage write error:", source: http://html5.grooveshark.com/build/app.min.js?1394645215 (1)
[0404/094159:INFO:CONSOLE(1)] "No data received", source: http://html5.grooveshark.com/build/app.min.js?1394645215 (1)
[0404/094207:INFO:CONSOLE(1)] "MEDIA_ERR_SRC_NOT_SUPPORTED", source: http://html5.grooveshark.com/build/app.min.js?1394645215 (1)

Changed in webbrowser-app:
status: New → Confirmed
Revision history for this message
Olivier Tilloy (osomon) wrote :

The MEDIA_ERR_SRC_NOT_SUPPORTED error is probably a consequence of the error just above, "No data received".

Revision history for this message
Olivier Tilloy (osomon) wrote :

Note that I can reproduce the same error on desktop by browsing to e.g. http://html5.grooveshark.com/#!/popular and clicking any song in the list.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Setting "preferences.localStorageEnabled: true" on the webview makes the localStorage read/write errors go away, but doesn’t fix the playback issue.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Using wireshark to monitor the network traffic, I can see that the track is requested and correctly sent by the server.
It looks like the problem is with the file format, apparently MP3 is not supported by default.

This is evidenced by this very simple HTML test page:

    <html>
      <body>
        <audio controls autoplay>
          <source src="test.mp3" type="audio/mpeg">
        </audio>
      </body>
    </html>

which doesn’t play, however if I replace the source by <source src="test.ogg" type="audio/ogg"> then the audio plays.

Revision history for this message
Olivier Tilloy (osomon) wrote :

More info from Chris:

<oSoMoN> chrisccoulson, what would it take to enable support for mp3 for the audio tag by default in oxide?
<chrisccoulson> oSoMoN, basically, we need 2 build steps (the current one and one with proprietary_codecs=1), so that libffmpeg can be built twice
<chrisccoulson> the chromium source package does something like this, but it actually gets it a bit wrong (it breaks incremental builds for some reason)
<chrisccoulson> i think because it reconfigures gyp after building chromium to build ffmpegsumo a second time with h264/mp3

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

Adding a packaging task for Oxide as well - if we add an option to oxide for enabling proprietary codecs, and we can change that option without forcing a rebuild of the entire tree (not sure about that), then the 2 build steps could be added to the packaging by running cmake, building, re-running cmake and then doing an incremental build

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

Ok, the incremental build won't work, as setting the proprietary_codecs flag in gyp changes a compiler definition in build/common.gypi which is applied to every source file in the tree, resulting in a full rebuild :(

Didier Roche-Tolomelli (didrocks)
Changed in oxide-qt (Ubuntu):
importance: Undecided → High
Chris Coulson (chrisccoulson)
Changed in oxide:
status: New → Fix Released
Changed in oxide-qt (Ubuntu):
status: New → Fix Committed
Selene ToyKeeper (toykeeper)
tags: added: r283
Selene ToyKeeper (toykeeper)
tags: added: qa-touch-blocker
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package oxide-qt - 1.0.0~bzr490-0ubuntu1

---------------
oxide-qt (1.0.0~bzr490-0ubuntu1) trusty; urgency=medium

  * Update to r490
    - Build with enable_plugins: 0 and toolkit_views: 0 to trim the size
      a bit
    - Ensure subframe navigations that require a new window become top-level
      navigations for webviews that don't implement WebView.newViewRequested
    - Add an option for enabling proprietary codecs (ENABLE_PROPRIETARY_CODECS)
    - Build and install the l10n pak files
    - Add file picker support (LP: #1260008)
    - Add some resources to oxide.pak that were missing (eg, directory listing
      HTML)
    - Fix a crash that occurs when handling events from some mouse buttons
    - Add cursor support (LP: #1257662)
    - Reimplement Chromium's RenderSandboxHostLinux so that it runs the sandbox
      IPC helper process as a proper child process rather than just forking
      the browser process, which is dangerous for Oxide (LP: #1304648)
  * Split libffmpegsumo.so in to 2 separate packages (oxideqt-codecs and
    oxideqt-codecs-extra) (LP: #1301341)
 -- Chris Coulson <email address hidden> Tue, 08 Apr 2014 15:27:09 +0100

Changed in oxide-qt (Ubuntu):
status: Fix Committed → Fix Released
Olivier Tilloy (osomon)
Changed in webbrowser-app:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.