clear old sticky events upon stream-start
Short description: Sticky events are not cleared (checked gstreamer/gst/gstpad.c) when new track is played in gapless mode. This normally does not make a problem as sticky events are marked received (ev->received = TRUE) when they are properly processed. Or when playing without gapless the pad change state would triggers clearing of the events.
Solution/Patch: The solution for this problem is to clear event tags and probably some other sticky events upon stream-start. There is already some clearing done in current code - EOS is cleared for instance. I see no reason to keep the old sticky events on pad after stream-start. It can only introduce problems. Patch is attached for inspiration. There may be other sticky events that could be safely cleared, for my use case I need only tags to go away.
Triggering the bug (complicated/custom logic, cannot be simplified to simple test case):
In some very specific setup with some custom elements like switchbin and gapless logic, the bug was triggered where some event tags were sticked to some pad in the middle of the pipeline and didn't continue to the sink or just wasn't marked received.
The sticky event tag was dormant for another track, and then (probably upon switchbin reswitch) it was revived and continued on the pipeline to sink. This was received on busWatch as normal GST_MESSAGE_TAG and confused user with old metadata.
The tag revival is visible in attached log:
- the first track with metadata (title Papercut) ended around 0:22 sec
- then there was one short wav without metadata
- around 0:53 third track without metadata was played
At step 3, the metadata from 1, was observed. In log we see that the tag with same hash id was revived and continued at third track time.