Display the download button for files that are not downloading and have 0 progress #381

Merged

6ea86b96 merged 1 commit from no-progress-downloads into master

2017-07-24 23:30:42 +02:00

6ea86b96 commented

2017-07-24 19:32:56 +02:00

(Migrated from github.com)

Seems to be a problem where some files start to download but never receive any data. Then the "open" link appears when viewing them after the app has been restarted. This switches it to display the download link still.

kauffj commented

2017-07-24 23:30:37 +02:00

(Migrated from github.com)

I'm merging this because it seems better than the alternative, but both still seem wrong. If the stream descriptor blob has been downloaded, then the daemon will continue to try to download the file without any additional actions by the user. This should really be sitting at 0%, I think.

6ea86b96 commented

2017-07-25 05:52:21 +02:00

(Migrated from github.com)

@kauffj agree, I didn't write a note as it was like 1:30am when I pushed this. It seemed like the simplest possible quick fix. Perhaps we should check if fileInfo.written_bytes < fileInfo.total_bytes && !downloading when this component is mounted/receives props. If the above is true then add it to the downloading files and restart the update download progress timeout code.

@kauffj agree, I didn't write a note as it was like 1:30am when I pushed this. It seemed like the simplest possible quick fix. Perhaps we should check if `fileInfo.written_bytes < fileInfo.total_bytes && !downloading` when this component is mounted/receives props. If the above is true then add it to the downloading files and restart the update download progress timeout code.

kauffj commented

2017-07-25 22:49:09 +02:00

(Migrated from github.com)

@6ea86b96 it seems like we could possibly have the FILE_LIST_SUCCEEDED reducer update the downloading status (or directly read the downloading status directly from all FileInfos)?

Either way, my inclination would be to see if we could get to the proper state from the initial file_list call, rather than re-checking on receive props.

@6ea86b96 it seems like we could possibly have the `FILE_LIST_SUCCEEDED` reducer update the downloading status (or directly read the downloading status directly from all `FileInfo`s)? Either way, my inclination would be to see if we could get to the proper state from the initial `file_list` call, rather than re-checking on receive props.