Design #524
Library design needs to be modified to hold all json data
| Status: | Closed | Start date: | 01 May 2016 | |
|---|---|---|---|---|
| Priority: | Immediate | Due date: | ||
| Assignee: |  Hammel | % Done: | 100% | |
| Category: | Local DB | |||
| Target version: | PiBox - 0.12.0 | |||
| Severity: | 02 - High |
Description
The library shouldn't be a single flat file. It should be one flat file per movie file that contains all the json data for a single movie or TV show. This will allow me to more easily save all json data and only parse out what I support in the UI, making future updates to the UI easier. It should also be faster since I don't have to maintain the entire json data in memory. I can just read them in at start up to create a sorted list of movies, even sorting on different fields (title, date, etc.).
Associated revisions
RM #524, RM #486, RM #468, RM #344, RM #343: Refactored code to be much simpler, putting more of the load in MovieDB from UI. Also allows saving and better use of JSON data from upstream db. Changed from flat file db to saving all JSON data for all movies. Added VideoLib specific fields to json to make it easier to edit which alternative to use. Fixed scanning to only scan new videos unless specifically requested to rebuild database. Dropped multiple poster sizes to simplify code.
RM #524, RM #486, RM #468, RM #344, RM #343: Refactored code to be much simpler, putting more of the load in MovieDB from UI. Also allows saving and better use of JSON data from upstream db. Changed from flat file db to saving all JSON data for all movies. Added VideoLib specific fields to json to make it easier to edit which alternative to use. Fixed scanning to only scan new videos unless specifically requested to rebuild database. Dropped multiple poster sizes to simplify code.
History
#1
Updated by Hammel 12 months ago
- Status changed from New to In Progress
- Priority changed from Normal to Urgent
- % Done changed from 0 to 10
- Severity changed from 03 - Medium to 01 - Critical
The database should be in JSON, not plain text. A newline specifies a new video entry. This would be the same JSON data retrieved for a video file but with the path to the video added as an identifier for the record. Posters may need alternate handling from what happens now - I'll have to research that some more.
This will be a rewrite of LocalDB in videolib and will require a rewrite of videofe:db.c:dbLoad() to read the data.