Ensure ci is properly updated if seeking before track load completes

If in the middle of a manual skip, playback would try to seek, and
therefore start, the codec before the audio handle was available.
This wasn't really a problem since the codec would just bail out
and be retried later. But, it is a problem for a change I was working
on with seeking where the codec could get caught in a full-speed
loop trying to seek itself (stoppable, not lockup).

The main side effect of this change that you may notice, if using an
HDD with dircache turned on and the disk is not spinning, is that you
can keep holding down prev/next if dir skipping and the WPS will
start FF/RW mode. By the time the new track shows up, you will have
seeked into it some amount.

Well, the PBE is getting the info ASAP anyway and as far as it's
concerned, the next track is under way. On that end of things, it's
correct. Perhaps WPS should lock out its own seek mode at certain
times.

Change-Id: Ifc7409a886df399cec189d1bae2adba3872e857a
This commit is contained in:
Michael Sevakis 2017-12-07 11:20:09 -05:00
parent bef75a94f8
commit 83e8e35a58

View file

@ -2904,7 +2904,9 @@ static void audio_on_ff_rewind(long time)
/* Track must complete the loading _now_ since a codec and audio
handle are needed in order to do the seek */
if (cur_info->audio_hid < 0 &&
bool finish_load = cur_info->audio_hid < 0;
if (finish_load &&
audio_finish_load_track(cur_info) != LOAD_TRACK_READY)
{
/* Call above should push any load sequence - no need for
@ -2914,7 +2916,7 @@ static void audio_on_ff_rewind(long time)
break;
}
if (pending == TRACK_SKIP_AUTO)
if (pending == TRACK_SKIP_AUTO || finish_load)
{
if (!bufreadid3(cur_info->id3_hid, ci_id3) ||
!audio_init_codec(cur_info, ci_id3))