My Library - use file_list data instead of resolving #1203

New issue

Open

opened 2018-03-29 15:03:22 +02:00 by tzarebczan · 2 comments

tzarebczan commented

2018-03-29 15:03:22 +02:00

(Migrated from github.com)

The Issue

Currently when the Downloaded/Published list is processed the first time, each URL is resolved to capture metadata required to populate tile information. With the recent file_list changes, we should have all the information required in the file_list api call so the resolve calls can be spared. This also applies to Published files which should be part of file_list and if they are not, the fall back would be claim_list_mine. We should also take into account a claim that has been abandoned (would fix https://github.com/lbryio/lbry-app/issues/694) - in this case, the file_list entry stays in tact but new resolves would fail - we can add a note that the claim was removed but the user can still see the claim/play the file.

We should only have to resolve when accessing the claim in case there are any updates to metadata/files. I will open a separate issue on how to deal with both scenarios. Think it would be nice to alert the user that metadata updated on a claim they had downloaded. When a source file is updated on an existing claim, a user should also receive a notice with the option to download the new content.

Expected behaviour

Faster listing of Downloads/Published data

Actual behaviour

All Downloads/Published files need to be resolved.

System Configuration

LBRY Daemon version: 0.19.1
LBRY App version: 0.21.2
LBRY Installation ID:
Operating system: Windows

Anything Else

Screenshots

## The Issue Currently when the Downloaded/Published list is processed the first time, each URL is resolved to capture metadata required to populate tile information. With the recent file_list changes, we should have all the information required in the file_list api call so the resolve calls can be spared. This also applies to Published files which should be part of file_list and if they are not, the fall back would be claim_list_mine. We should also take into account a claim that has been abandoned (would fix https://github.com/lbryio/lbry-app/issues/694) - in this case, the file_list entry stays in tact but new resolves would fail - we can add a note that the claim was removed but the user can still see the claim/play the file. We should only have to resolve when accessing the claim in case there are any updates to metadata/files. I will open a separate issue on how to deal with both scenarios. Think it would be nice to alert the user that metadata updated on a claim they had downloaded. When a source file is updated on an existing claim, a user should also receive a notice with the option to download the new content. ### Expected behaviour Faster listing of Downloads/Published data ### Actual behaviour All Downloads/Published files need to be resolved. ## System Configuration   - LBRY Daemon version: 0.19.1 - LBRY App version: 0.21.2 - LBRY Installation ID: - Operating system: Windows ## Anything Else  ## Screenshots

tzarebczan commented

2018-03-29 20:00:54 +02:00

(Migrated from github.com)

Just realized we'd run into an issue with sorting if using only file_list since we sort Published content by claim height which is only available in claim_list_mine / resolves. After running claim_list_mine, are the claims still resolved or does it just use the metadata from claim_list_mine?

neb-b commented

2018-10-09 19:20:18 +02:00

(Migrated from github.com)

Just noting that this should fix #694 too