Past download failures stuck at 0%, can't download/delete #464

New issue

Closed

opened 2019-03-08 04:13:13 +01:00 by tzarebczan · 4 comments

tzarebczan commented

2019-03-08 04:13:13 +01:00

(Migrated from github.com)

The Issue

This one may be tricky to reproduce, but if you had a download fail (not sure if it got sd blob, or nothing at all), and then go back into the claim page (not sure if before/after a restart), the thumb will show 0% and not download. There will be no download/delete buttons. The items will show in the downloads progress page as with no progress.

If the sd blob fails, there should not be any file list entry. Maybe this happens when a download gets stuck and then the app is closed? Not sure yet...can try to reproduce.

System Configuration

Device:
Android version:

Anything Else

Screenshots

Internal Use

Acceptance Criteria

Definition of Done

Tested against acceptance criteria
Tested against the assumptions of the user story
The project builds without errors
Unit tests are written and passing
Tests on devices/browsers listed in the issue have passed
QA performed & issues resolved
Refactoring completed
Any configuration or build changes documented
Documentation updated
Peer Code Review performed

## The Issue This one may be tricky to reproduce, but if you had a download fail (not sure if it got sd blob, or nothing at all), and then go back into the claim page (not sure if before/after a restart), the thumb will show 0% and not download. There will be no download/delete buttons. The items will show in the downloads progress page as with no progress. If the sd blob fails, there should not be any file list entry. Maybe this happens when a download gets stuck and then the app is closed? Not sure yet...can try to reproduce. ## System Configuration - Device: - Android version: ## Anything Else  ## Screenshots  ## Internal Use ### Acceptance Criteria 1. 2. 3. ### Definition of Done - [ ] Tested against acceptance criteria - [ ] Tested against the assumptions of the user story - [ ] The project builds without errors - [ ] Unit tests are written and passing - [ ] Tests on devices/browsers listed in the issue have passed - [ ] QA performed & issues resolved - [ ] Refactoring completed - [ ] Any configuration or build changes documented - [ ] Documentation updated - [ ] Peer Code Review performed

tzarebczan commented

2019-03-11 16:58:18 +01:00

(Migrated from github.com)

@akinwale , this will happen for any case where the sdblob was downloaded but the rest of the file was not. The reason we save the sdblob + file record is in case it was a paid download...otherwise the user would have to pay for it again. A few users outside the US have been running into download issues, so I think this is occurring fairly frequently.

akinwale commented

2019-03-11 18:24:29 +01:00

(Migrated from github.com)

Ah, this makes sense. I suppose the sdk could have a flag in the file record which should keep track of cases where the download fails and needs to be retried / restarted?

tzarebczan commented

2019-03-11 19:16:29 +01:00

(Migrated from github.com)

  {
    "blobs_completed": 0,
    "blobs_in_stream": 4,
    "blobs_remaining": 4,
    "channel_claim_id": null,
    "channel_name": null,
    "claim_id": "b2e780d3a2d065808f1b044e96956200526cf2a2",
    "claim_name": "no-data-blobs",
    "completed": false,
    "download_directory": "C:\\Users\\thoma\\Downloads\\LBRY",
    "download_path": null,
    "file_name": null,
    "key": "6155469264e98ec1965c6411fcbfa6bc",
    "metadata": {
      "author": "",
      "description": "",
      "language": "en",
      "license": "None",
      "licenseUrl": "",
      "nsfw": false,
      "preview": "",
      "thumbnail": "",
      "title": "sd failure test",
      "version": "_0_1_0"
    },
    "mime_type": "video/mp4",
    "nout": 0,
    "outpoint": "58b36a1a9b3bb4c68dd8a6c3ea4ea6473c2f3010ff323ed208bf9bbe3753b0eb:0",
    "points_paid": 0.0,
    "sd_hash": "73473cada1adc45a2bf2615fa9d30a7836f5bd87e3e6158750942c981a1b6f93a45794cd009a1b56797a46a2761066ef",
    "status": "stopped",
    "stopped": true,
    "stream_hash": "f7b1469a475c86ccc3cc059441b01c9c08607793171cbe08fbcfc6c9da1e4d580b3dd0169eb93667fa937ee42ab147a1",
    "stream_name": "20190308_014227_1.mp4",
    "suggested_file_name": "20190308_014227_1.mp4",
    "total_bytes": 7444029,
    "total_bytes_lower_bound": 7444013,
    "tx": null,
    "txid": "58b36a1a9b3bb4c68dd8a6c3ea4ea6473c2f3010ff323ed208bf9bbe3753b0eb",
    "written_bytes": null
  }
]```

Below is what a file list entry looks like in this case - it would be in completed = false status, with no path. If the path is blank, we should allow users to call get again (this is also the case where if someone moved the file, calling get would result in re-creation from data blobs / redownloading). The connection manager (to be implemented) may handle this scenario in the future, but I think we should give users an option to call get for now. I'm not sure if a separate flag is needed... ```[ { "blobs_completed": 0, "blobs_in_stream": 4, "blobs_remaining": 4, "channel_claim_id": null, "channel_name": null, "claim_id": "b2e780d3a2d065808f1b044e96956200526cf2a2", "claim_name": "no-data-blobs", "completed": false, "download_directory": "C:\\Users\\thoma\\Downloads\\LBRY", "download_path": null, "file_name": null, "key": "6155469264e98ec1965c6411fcbfa6bc", "metadata": { "author": "", "description": "", "language": "en", "license": "None", "licenseUrl": "", "nsfw": false, "preview": "", "thumbnail": "", "title": "sd failure test", "version": "_0_1_0" }, "mime_type": "video/mp4", "nout": 0, "outpoint": "58b36a1a9b3bb4c68dd8a6c3ea4ea6473c2f3010ff323ed208bf9bbe3753b0eb:0", "points_paid": 0.0, "sd_hash": "73473cada1adc45a2bf2615fa9d30a7836f5bd87e3e6158750942c981a1b6f93a45794cd009a1b56797a46a2761066ef", "status": "stopped", "stopped": true, "stream_hash": "f7b1469a475c86ccc3cc059441b01c9c08607793171cbe08fbcfc6c9da1e4d580b3dd0169eb93667fa937ee42ab147a1", "stream_name": "20190308_014227_1.mp4", "suggested_file_name": "20190308_014227_1.mp4", "total_bytes": 7444029, "total_bytes_lower_bound": 7444013, "tx": null, "txid": "58b36a1a9b3bb4c68dd8a6c3ea4ea6473c2f3010ff323ed208bf9bbe3753b0eb", "written_bytes": null } ]```

tzarebczan commented

2019-03-11 21:14:21 +01:00

(Migrated from github.com)

@akinwale actually, just spoke to Jack and this will be changing in a future verison - get will not return unless both sd + headblob is downloaded.