Open smcv opened 3 years ago
I saw this on version 1.1.1 on OpenBSD yesterday. Not seen it since.
I didn't get more than this, it was on screen and the preceeding lines that were in the backlog weren't much more informative...
(collectiongain:284075): GStreamer-WARNING **: 21:20:39.083: ../gst/gstpad.c:4463:gst_pad_chain_data_unchecked:<rg:sink> Got data flow before segment event
(collectiongain:284075): GStreamer-WARNING **: 21:20:39.083: ../gst/gstpad.c:4736:gst_pad_push_data:<rg:src> Got data flow before segment event
3acfc09e-2acb-4ec6-892d-2fc2aacea952:Checking for Replay Gain information ...
./Khruangbin/Khruangbin -- 2019-04-20: Greek Theatre, Berkeley, CA (2019)/Khruangbin -- 01 - Bin Bin.flac:none
./Khruangbin/Khruangbin -- 2019-04-20: Greek Theatre, Berkeley, CA (2019)/Khruangbin -- 02 - The Infamous Bill.flac:none
./Khruangbin/Khruangbin -- 2019-04-20: Greek Theatre, Berkeley, CA (2019)/Khruangbin -- 03 - Dern Kala.flac:none
./Khruangbin/Khruangbin -- 2019-04-20: Greek Theatre, Berkeley, CA (2019)/Khruangbin -- 04 - August 10 >.flac:none
./Khruangbin/Khruangbin -- 2019-04-20: Greek Theatre, Berkeley, CA (2019)/Khruangbin -- 05 - Night Nurse.flac:none
./Khruangbin/Khruangbin -- 2019-04-20: Greek Theatre, Berkeley, CA (2019)/Khruangbin -- 06 - Lady and Man.flac:none
Running a derivative of Ubuntu noble.
I'm updating from 1.0.0 to 1.1.0 in Debian unstable, and during my build/test procedure I found that an automated test was intermittently getting stuck. As a smoke-test for new versions, I run this script https://salsa.debian.org/python-team/packages/rgain3/-/blob/debian/master/debian/tests/replaygain in a virtual machine. The expected result is that it performs replay gain analysis on the four test audio clips found in the same directory as the script itself, as though they were an album (they're actually short clips taken from sound-theme-freedesktop), then terminates successfully.
However, the result I'm actually getting in the test VM is that it hangs, like this:
Message https://marc.info/?l=gstreamer-devel&m=138703546904972&w=2 on the GStreamer upstream mailing list suggests that this might be to do with the change in commit d5cfdd86 - maybe it shouldn't be sending a flush event?
Unfortunately I can't seem to reproduce this when not in the virtual machine, so perhaps it's timing-related.