Right now, syncing is one way, meaning repositories update the values in the unicast server, but not the other way around.

This means that when importing media from the repositories, the watched status should be imported.

However, when syncing media that was already imported, it is important to decide whether to keep the value in the server already, or use the one retrieved from the repository, or maybe make it configurable.

Also, it is important to pay attention to watched totals in TV Shows and seasons.

While HLS seems to be the most seamless option for enjoying transcoded media in formats that Chromecast does not natively support, it's reliability has left a little to be desired. As such, and as a fallback, we should implement a simpler, alternative transcoding format that writes to an mkv/mp4 container as a stream, saving it to the disk, all while serving the Chromecast stream as fast as possible.

Limitations

Since it is impossible to know the duration, or the indexes of where in the file each timestamp is until the file is finished, seeking does not work natively. A custom made alternative may be considered for this use-case.

Create a tool that transcodes only the selected times to a file on the computer and allows to preview if the trigger timestamps are correct.

When listing media records, allow the request to contain compelx parsable search expressions. A complex search expression must always come after one question mark ?.

Examples

? (category = ClassA or Saturday) or (category = Rewatch or lastPlayed > 5months)

Design Notes

When evaluating an expression, an optional schema object can be passed that customizes the evaluation of each property.
For example, when evaluating the category property, the schema can define custom variables inside the subexpression corresponding to each of the categories in the media record.

Hi, great Job!
Can you please tell me if you plan to add a new provider like Plex (plex.tv) ?
Can you alse please tell me if it possible to read movies, ... in another way for chromecast: with my chrome browser ?
Thank you.
Best Regards,
Julien Taverne.

Make this configurable. Ideally it should detect if the resulting string is to big to be part of the command, and if so, try to run it from a file. This can happen when there are a lot of trigger timestamps, resulting in a complex FilterGraph.

Some endpoints should have an WebSockect/server side events corresponding endpoint. The system should be abstracted in a way so that the same code is used for the three of them.

When syncing and cleaning the media database, any records that no longer exist should be marked as deleted in the database, as opposed to being removed from it. This way, any references to them (such as in playlists) will continue to work (partially).

In addition, there should be a way to identify removed records that have not references to them, and to clean them up.

When seeking transcoded media, the HLS segments where the seeking is done and any segments that might have already been transcoded, from a previous seeking to a time further in the future, can cause slight hiccups when playing with Chromecast.

Currently when downloading subtitles, the language is hardcoded: make it use the configured language in the settings files and optionally allow each request to specify custom languages to use instead.

When synchronizing with the file system media provider, there was some regression that caused episodes to be created in the database without correct foreign keys.

Keep a log of user-made actions (such as creating playlists, adding/removing items to/from a playlist, marking items as watched, etc...). This log should also be able to be then applied to a different database, so as to keep them in sync.

Right now the only repository that is implemented makes use of Kodi's API. While this should be maintained for flexibility and compatibility, since Kodi's system is much more mature and flexible than anything we could create in a reasonable amount of time, for simpler cases, such as smaller media collections, there should be a lightweight, native alternative that does not require external tools.

As such, there should be created a custom FileSystem repository that can be configured (and instanced) multiple times.

Features

• Configurable through the config.hjson file.
• Recognize both Movies and Tv Shows
• Zip together tv shows episodes scattered around multiple folders

Implementation

The first implementation should strive to be simple but reliable. As such, it should cover only the most common use cases. Anything more specific should be relegated to existing tools.

Scanning

Parsing of the file names could be delegated to existing npm's modules, such as torrent-name-parser or torrent-files-library.

Scraping

Initially only The TVDB and TheMovieDB will be available as scrapers.

Some of the functionality in this media repository might be extracted so as to be used by other repositories that need it too.

Some movies have a field named lastPlayed, while others have it named lastPlayedAt. Rename all to lastPlayed and make sure this field is correct, if there is information in the history records about it.

Allow the remote to delay/advance the subtitles.

Chromecast

The implementation for the flagship Chromecast receiver can be as follows:

• While maintaining the same play session (and transcoding processes if any is running) re-send a load message to the Chromecast device with the same parameters except: initial time should be the time before changing subtitles; the subtitles URL should include a query parameter declaring the new time offset.
• Aditionally, the receiver can send a predefined number of subtitles already delayed/advanced that can be changed to first, without requiring to re-load the media.

Add the functionality for Chromecast receivers to auto-detect devices in the local network.

Should be configurable whether to sync/clean the media database automatically after the app has started.

Also, if the repository is a remote one, the synchronization process should recognize when the remote endpoint is down.

Additionally, in case the repository is indeed down, if possible to be notified when it is back up, the sync process should start when available.

Create a system that allows to install custom plugins, such as receivers, providers, repositories and so on.

Current Proposal

Allow the application to register custom entity containers, with a folder associated to each one. After that, every plugin can define several entities and several files for each entity. On install, each file is then copied to the <entityFolder>/<pluginName>/<file>.

Still under consideration is the strategy used that will be used for registering the entities:

1. Should it be done in an automatic and standardized way for all entities;
2. Should each plugin be responsible for the initialization;
3. A combination of both;

Create a separate package unicast-api that will expose public types returned by the API and can be used by client packages to stay up to date with the returned types of the API.

Goals

• Test if transcoded HLS playback works with Chromecast.
• Fix it (if it does not)

Background

Playback with HLS, although promising for transcoded media, has proven tricky when it comes to support from Chromecast. Altough it is stated that the format is supported, it is unclear what parameters are accepted when it comes to the video and audio codecs.

Additionally, an opaque update system enabled by default in Chromecast frequently means that media that once worked and played fine, no longer does. And lately, HLS seems to have suffered particularly a lot from this.

One possible explanation comes from a thread in StackOverflow detailing the sudden lack of support for HLS audio with more than two channels (stereo). A temporary fix was implemented, but it seems to have stopped working again.

This major feature is divided into three categories:

Subtitles Providers

Create a system that allows for subtitles providers to be added (as plugins), and to be configured. Standardize the returned objects.

Create also a global caching system for the subtitles.

Repositories Subtitles

Each repository should, optionally, be able to manage subtitles for a media record, listing, inserting, renaming and removing them. If not implemented, then it should fall back to a default global system that stores the subtitles in a folder in the application and associates them in the database with the media record.

HTTP Controller

Create an HTTP Controller that allows to communicate with both these Services. also think about a possible pre-fetch system that automatically tries to guess, in certain situations, which subtitles the user will search/download next and start the request before it is asked to do so, saving time.

Currently the server crashes when subtitles are not found, if the media sources are already cached.

The user should be able to automatically mark media as watched.

Additionally, when playing a media item, and it reaches a certain duration, mark that item as watched automatically.

Watched items should also include a play count and a last watched date.

When playing, allow to get the previous and next media for a specific media session.

Several strategies can be used. If the media session playing belongs to a playlist, then the next/previous should be the next/previous item in the playlist.

Otherwise, if the media is a TV episode, then the previous/next media should be the next/previous episode of the same TV show.

The code that updates the position when playing a media session is faulty and not working.
Investigate any issues and fix them.

When playing media, it should periodically update it's status in the database, such as time played.

Create a diagnostics service. Such service should allow other services to measure how long their tasks are taking every time, log any debugging messages.

It should also allow the application to measure the CPU and RAM usage periodically, as well in certain time periods specifically requested by other services.

The format in which this data is saved should be consistent, so that later tools to analyze the performance and find bottlenecks can be easily devised.

Each receiver should be able to return a custom remote layout with it's own available commands.

They should also implement the method callCommand<T = any>( command : string, args : any[] ) : Promise<T>.

Rank subtitles by score for the media record they belong to and by their apparent quality (downloads, author rank, etc..)

Right now, artwork is cached by media record ids. This means that if the artwork is changed in the media repository and updated in the server database, the same image is still served.

Also, the artwork currently has an unlimited lifespan. A ttl option should be added.

All the code is currently handled in the artwork controller. This should be changed to include a custom service class called ArtworkCache to handle all the specific logic.

Finally, better handling of concurrent requests for the same artwork to avoid duplicate processing.

Before stopping, some parts of the application may want to perform some cleanup actions. As such, create a mechanism that detects when the server is being shutdown and calls all registered hooks asynchronously.