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 754375 - tagdemux/id3demux: Validate change state intensive fails for mp3 with ID3 tags
tagdemux/id3demux: Validate change state intensive fails for mp3 with ID3 tags
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 755123
Blocks:
 
 
Reported: 2015-09-01 04:19 UTC by Vineeth
Modified: 2018-01-20 14:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Vineeth 2015-09-01 04:19:27 UTC
When i run change state intensive validate scenario for mp3 files with ID3 tags

GST_VALIDATE_SCENARIO=change_state_intensive gst-validate-1.0 playbin uri=file:///home/user/gst/master/temp/10sec.mp3

i get the below error sometimes(1 out of 10 times)
     Critical error Got error: Could not detect type of contents -- Debug message: gsttagdemux.c(1417): gst_tag_demux_element_find (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin1/GstDecodeBin:decodebin1/GstID3Demux:id3demux1


The same becomes an always issue with fake sink

GST_VALIDATE_SCENARIO=change_state_intensive gst-validate-1.0 playbin uri=file:///home/vineethtm/gst/master/temp/10sec.mp3 audio-sink='fakesink'

Sometimes the above error message will come, and at times it will be
Critical error Got error: Could not get start and/or end tag -- Debug message: gsttagdemux.c(1403): gst_tag_demux_element_find (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin1/GstDecodeBin:decodebin1/GstID3Demux:id3demux1



This seems to be more of a timing issue..
basesrc seems to be in flushing mode, so whenever tagdemux calls
gst_pad_pull_range on its sinkpad, it returns flushing and it is not able to typefind the element.

0:00:00.813397698 [332m 9625[00m  0x8282000 [36mINFO   [00m [00m            tagdemux gsttagdemux.c:1373:gst_tag_demux_element_find:<id3demux1>[00m Found type (NULL) with a probability of 0
Comment 1 GstBlub 2015-09-16 16:21:52 UTC
You might be interested in trying the patch I submitted in bug #755123, it *might* fix this issue.
Comment 2 Vineeth 2015-09-17 06:02:41 UTC
tried the patch.. and it is not helping :)...
Comment 3 Tim-Philipp Müller 2016-12-06 18:44:58 UTC
Could you try whether this helps:

commit 7c1a32e28b9d145ee25e3d3141dee7821ba8a7e2
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Tue Dec 6 16:29:23 2016 +0200

    tagdemux: Fix crash when shutting down element during getrange()
    
    Ensure that nothing is in any of the streaming thread functions
    anymore when going from PAUSED to READY. While the parent's state change
    function has deactivated all pads, there is nothing preventing
    downstream from activating our srcpad again and calling the getrange()
    function. Although we're in READY!
    
    https://bugzilla.gnome.org/show_bug.cgi?id=775687
Comment 4 Tim-Philipp Müller 2018-01-20 14:33:37 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!