#94 Downloads failing immediately correctly update UI

[Chralu]

Fixes #94

Add a Lock to DownloadService. This ensures that download status updates are not processed while a download start/stop is requested (they are processed right after).

[amugofjava]

Hi @Chralu,

Thanks for this pr. I think this gets us part of the way there, but I need to revisit this section as there are still problems - for example when in airplane mode. If you start a download, it appears to cancel, but when you return it is queued but never gets any further.

Screen_recording_20230929_181525.webm

[Chralu]

Hi @amugofjava ,

I've reworked this PR a bit to handle the case you described.

The issue was caused by an inconsistency between :

• episode state stored in Sembast
• episode state streamed through DownloadService, Bloc to UI

The fix mainly consists in using the standard download progress workflow when download initialization fails.

[amugofjava]

Hi @Chralu,

Thanks for the updated PR.

Moving the download parts fully into the DownloadService makes sense; however, doing so has introduced a regression. Previously, hitting download would change the status to DownloadState.queued and push the update to the stream. What happens now is hitting download calls downloadEpisode but the status is not updated until we receive an update from the manager. The end result is it takes a while for the UI to update.

If you take a look at the capture below that shows current behaviour:

download_before.mp4

And compare to the behaviour in the PR:

download_after.mp4

There is a noticeable delay between hitting download and the UI being updated.

I think it should be an easy fix. The episode stream needs updating before the download process kicks in.

[Chralu]

Hi @amugofjava ,

thanks for the review !
I don't have much time to look at it for now, but I will check how to fix that behavior in the next weeks.