So, I’ve been thinking about one way Firecore might have organized Infuse’s code, if conceived in a modular fashion.
Using somewhere between 2 and 4 key modules (depending on the degree of entanglement between them) …
My thought is you’d first begin with a module that includes all the code designed to access content on the large and growing variety of Infuse-supported local and remote servers and cloud services. This module would deal exclusively with reaching out from the Apple TV and establishing read-privileges to users’ content, wherever it lives, and the management of users’ shared folders.
———
Next you’d have a module that exclusively builds and manages Infuse’s database cache. This would apply to all items in users’ shared folders that are included in Infuse’s library. This module would scrape the filenames of users’ video files to determine content type (TV / Movie) and appropriate search terms with which to query TMDB for identification of the files and the downloading of all supported metadata for each title from TMDB’s own massive database.
Essentially, this database should be a matrix of datapoints for each file; including links to the users’ video files, file accessed, created, and modified dates, tagged data fields for all the textual metadata downloaded from TMDB, links to all of the relevant image files on TMDB, and links to all the users’ local image files (stored alongside the video content).
Ideally among the tagged data fields for video files listed above should be links to all cast and crew information derived from TMDB (and links to their headshot images), that would be available to be pulled on demand when a user request the complete list through the UI.
It feels as if Infuse does build its own cast & crew database independent of the users’ video files database — which Infuse populates as it processes new video files — with the entries for the video files each containing tagged fields linking to cast and crew entries in this database — which appears to either be made up of links to the persons’ headshot photos plus Infuse generated links to other collection items in which that person appears …
… Or else it’s all simply a dataset created anew each time, on demand, by querying the entire video metadata database (which seems less efficient).
Because Infuse is able to return search entries for collection titles in which an actor/crew member is credited but not displayed as being a cast/crew member of when viewing that title’s cast/crew bar; it doesn’t seem Infuse’s internal cast/crew database is artificially limited to only the number of entries per title that the UI is currently capable of displaying.
The above would seem to indicate that the UI has room to grow to improve display of cast and crew without necessarily requiring changes to Infuse’s underlying database structure.
Aside:
When Infuse added support for override of TMDB-derived cast and crew data via local .nfo, it became obvious to me that Infuse did this by creating an entirely separate (.nfo-derived) cast and crew database to the default (TMDB-derived) one.
These two databases fail to “play nicely” together in many instances — such as when doing a manual cast member search from the Home Screen. Even when local .nfo is sourced from the same provider as TMDB, and links to the same actor/crew entries at TMDB, Infuse does not combine the duplicated entries. You’ll therefore have duplicated entries in all search results.
Adding insult to injury, the two entries won’t be linked to identical lists of the person’s body of work among a users’ entire collection:
While the TMDB-derived Cast and Crew database eventually builds to completion in the background; that is not the case for the .nfo-derived version. The .nfo-derived Cast and Crew database is only added to when a user actually browses to the folders containing videos for which .nfo data is provided. To force Infuse to fully complete the .nfo-derived database, a user must tediously navigate manually to every collection folder.
This could definitely stand to be investigated and improved.
An even easier solution might match the one that was recently implemented for the Trailers button — give a user the option to Opt Out of managing their own Cast & Crew via .nfo. I formally used .nfo to customize the displayed titles of my movie and TV series (as a way to better control sequential sorting among franchise titles, for example, or chronological sorting for a musical artists’ or comedians’ body of work, for two more). I’m not longer able to do that because of the breaking of Cast and Crew representation.
———
Third, you’d also need a module dedicated simply playing back all of a users’ files, regardless of their specific encoding and quality standards. This module would simply begin streaming video files from links already established by the above two modules (as directed by the user via the next-to-be-discussed UI module); identifying the file-type and encoding via file headers or deeper examination of the file itself, choosing the correct decoder and decoder parameters with which to process the streamed file, and pushing the decoded audio/video file to the playback UI.
This module, and the one that reaches out from the AppleTV to users’ intranets or the internet to gain access to the files in the first place, seem to be the two elements most effected by updates to Apple’s operating systems, remote networking protocols, and technological advances in video and audio encoding techniques.
These modules also seems most susceptible to being broken by users who utilize non-standard or poorly encoded content or improperly utilized cloud storage options — yet regardless of fault, Firecore still seems to invest a large percentage of their efforts into frequently updating their grabbers and decoders to support even poorly sourced and poorly encoded content.
———
Finally, you’ve got to have an attractive, intuitive, feature-rich UI module: the code which governs the user-facing interactive elements that visually represents various matrices of playback links to all of a users’ indexed content, as organized per users’ various preferences, and accompanied by attractively presented metadata that assist a user in browsing and locating specific files and viewing information about those files to help the user decide what they want to watch at any given time.
For Library included content, those various matrices should be customizable and sortable based on the widest possible selection of specific metadata fields as is collected in Infuse’s internal metadata cache — data ingested during Infuse’s original content import process and periodic Library updates.
Assuming the cached metadata database is structurally sound, a lot of unrealized potential still exist within the Infuse UI; with some new or enhanced features governed by options modified or added to an updated configuration settings dialog.
Some such features would require the coding or recoding of various onscreen elements or “pages” of elements (including the Infuse Homescreen; the Movie and TV specific versions of the poster wall and list views; the movie and episode specific versions of the details page views, and perhaps the Library Menu page itself.
Many features would merely require the modification or addition to options in the settings menu; or modification or addition to various long-press options already widely present in the UI.
Currently missing features such as the enabling of per-folder (or per-filtered view) sorting options should presumably only require the code necessary to save and read back specific user-defined sort options to folders and views that already exist in the UI. If Infuse creates those views dynamically, brand-new each time, it will of course need to start recording their various view states and preserving these in Infuse’s allocated persistent memory register.
———
I’ve got to say, I’d really love to get access to the source code governing Infuse’s metadata database(s) and UI, and poke around, and see how I might contribute.
Couldn’t care less to see how the content is accessed, streamed, decoded, or played back — I feel Firecore has got that well under control.
Very much looking forward to this list of long-anticipated upcoming UI enhancements — especially one surprisingly added item very dear to me; seemingly present to address a long-ranted-about pet-peeve of mine.
This is a fantastic to-do list. I very much can’t wait to see how improved the Infuse experience will be afterwards.
7.5.5 (May)
7.5.x (in progress)
7.5.x (pending)
]
]
]
]
]
]
TL:DR