Incorrect seek position on song change

[m-y-u]

Describe the bug
The ui_event_type : PLAY outputs seek_position value as non-zero at the start of a song.

To Reproduce
Steps to reproduce the behavior:

1. Start the MUSER application.
2. Search for the song Air 'On The G String from Suite No. 3 in D BWV1068 in the songs list.
3. PLAY the song Air 'On The G String from Suite No. 3 in D BWV1068 in the list.
4. After 60 seconds, PAUSE this song.
5. While still running the application, go to the song list again.
6. Search for the song Adagio in the list and tap on it to PLAY it.
7. PLAY the song for 30-60 seconds and quit the application.

Expected behavior
When a user presses the PLAY song button, the expected seek_position to be received from the ui_event is zero. Whenever a new song starts playing (on previous song completion or through PLAY event), it should start playing from the beginning and the seek position should be 0.

Thus, from Step 6, the received seek_position on ui_event_type : PLAY for the song Adagio should be 0.

Observed behavior
On the ui_event_type : PLAY of a new song with song_name field as Adagio, the event_seek_position_in_milliseconds outputs a value of 38669 ms while the player_event_type : PLAY outputs the expected event_seek_position_in_milliseconds value of 0.

Device and Android version:

This bug has been experienced on the Lenovo Tab M8 (Model: TB-8705F, WIFI, 3G + 32GB), i.e. the current tablet being used for this research study.
It is running the OS ANDROID 10 version.
It is a stock version from the manufacturer.

[barbeau]

@antcoder007 Thanks for opening this. Could you or @kanch21 attach the raw CSV file for the above screenshots to this issue so we have it documented?

[m-y-u]

music-analysis.csv
This is the CSV file with the data for a tested user for the above bug. The songs in this file namely: Air On G String from Suite No. 3 and Adaigo are the initial and new song played as mentioned in the report above.