After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 673888 - Unable to resume playback after an error occurred during gapless playback.
Unable to resume playback after an error occurred during gapless playback.
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.34
Other Linux
: Normal normal
: 0.10.37
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 670321 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-04-11 07:58 UTC by Lev
Modified: 2012-06-17 09:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Full log, sample python script, and media files to reproduce the problem. (9.70 KB, application/gzip)
2012-04-11 07:58 UTC, Lev
  Details
playbin2: remove uridecodebin from bin when it fails to switch to PAUSED (962 bytes, patch)
2012-06-08 16:30 UTC, Vincent Penquerc'h
committed Details | Review
1 second long audio file (86.16 KB, audio/x-wav)
2012-06-13 03:41 UTC, Lev
  Details
Python script to reproduce the problem with short file. (48.28 KB, application/gzip)
2012-06-13 03:56 UTC, Lev
  Details

Description Lev 2012-04-11 07:58:53 UTC
Created attachment 211811 [details]
Full log, sample python script, and media files to reproduce the problem.

I'm using playbin2 and about-to-finish signal to implement gapless playback.
It works well with valid sound files.
However after it encounters invalid media file it's impossible to resume playback with playbin2. 

I'm trying to set state to NULL, set URL to a valid media file, and then set state to PLAYING, but it doesn't work and I'm getting an assert message in the log (full log is attached):
CRITICAL **: deactivate_group: assertion `group->active' failed

I have attached a python script and test media files to reproduce the issue.
Comment 1 Vincent Penquerc'h 2012-06-08 14:49:07 UTC
This looks very suspiciously like something that was fixed in january:

commit c433ef9b701f48bae2d0268323d4f69972b91c7f
Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk>
Date:   Wed Jan 18 14:58:08 2012 +0000

    playbin2: do not try to deactivate an inactive group
    
    A group may have failed to activate due to an error (for instance,
    having set the URI to a non existent location in about-to-finish).
    
    https://bugzilla.gnome.org/show_bug.cgi?id=666395


Can you try with either this commit in, or with latest -base release and see if this still happens ?
Comment 2 Vincent Penquerc'h 2012-06-08 14:53:00 UTC
Missed the test case.

I'm not getting the assert with git -base, but playbin2 still fails to chain to the next valid stream, so setting back to NEW for debuging.
Comment 3 Vincent Penquerc'h 2012-06-08 16:30:35 UTC
Created attachment 215974 [details] [review]
playbin2: remove uridecodebin from bin when it fails to switch to PAUSED

This avoids that bin being leftover and being found when reusing playbin2,
and fixes restarting on a new URI after failing to activate with a previous
URI.
Comment 4 Vincent Penquerc'h 2012-06-08 16:32:46 UTC
The test case now goes on with the new URI (albeit not gaplessly, as the intervening invalid URI prevents this).

commit 9f2e829bf5b373fe7cee21c7bc2e2262dc2c285b
Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk>
Date:   Fri Jun 8 17:28:28 2012 +0100

    playbin2: remove uridecodebin from bin when it fails to switch to PAUSED
    
    This avoids that bin being leftover and being found when reusing playbin2,
    and fixes restarting on a new URI after failing to activate with a previous
    URI.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=673888
Comment 5 Lev 2012-06-13 03:41:54 UTC
Created attachment 216244 [details]
1 second long audio file

Pipeline doesn't switch into PLAYING state and doesn't play the valid file if it is too short.
Comment 6 Lev 2012-06-13 03:56:18 UTC
Created attachment 216245 [details]
Python script to reproduce the problem with short file.
Comment 7 Lev 2012-06-13 03:58:39 UTC
(In reply to comment #4)
> The test case now goes on with the new URI (albeit not gaplessly, as the
> intervening invalid URI prevents this).
> 
> commit 9f2e829bf5b373fe7cee21c7bc2e2262dc2c285b
> Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk>
> Date:   Fri Jun 8 17:28:28 2012 +0100
> 
>     playbin2: remove uridecodebin from bin when it fails to switch to PAUSED
> 
>     This avoids that bin being leftover and being found when reusing playbin2,
>     and fixes restarting on a new URI after failing to activate with a previous
>     URI.
> 
>     https://bugzilla.gnome.org/show_bug.cgi?id=673888

Thank you very much for fixing this bug.
I have noticed another related issue and not sure if I need to file separate bug for it.
With the same test script if I use short 1 second long sound file, about-to-finish signal is emitted before playbin switches into PLAYING state and starts playback.
After an error is reported for the invalid file, playbin never switches to PLAYING state to start playback of the valid file.
I have attached updated script with sample media files.
Could you please have a look?
Comment 8 Lev 2012-06-13 06:27:46 UTC
I have also submitted another bug which might be related:
"Unable to tell when playback stops after an error occurred during gapless playback"
https://bugzilla.gnome.org/show_bug.cgi?id=677991
Comment 9 Jonathan Matthew 2012-06-17 09:21:47 UTC
*** Bug 670321 has been marked as a duplicate of this bug. ***