This commit includes changes to enable and stabilize asyncronous
operation in the auto-organize area. Here are the key points:
- The auto-organize correction dialog is now closed (almost) instantly.
This means that the user does not have to wait until the file copy/move
operation is completed in order to continue. (even with local HDs the
copy/move process can take several minutes or even much longer with
network destination).
- This commit also implements locking of files to be organized in order
to prevent parallel processing of the same item. In effect, there can be
2 or more manual organization operations active even while the normal
auto-organization task is running without causing any problems
- The items that are currently being processed are indicated as such in
the log with an orange color and a spinner graphic
- The client display is refreshed through websocket messages
- A side effect of this is that other clients showing the auto-organize
log at the same time are always up-to-date as well
Previously some methods were just returning null or empty values in case
of encountered errors; as a consequence, the actual reason for failure
was never written to the auto-organize log.
Instead, only a generic message like "Unable to sort xxx because target
path could not be determined." was displayed.
After this change, the actual reason for failure will be saved to the
auto-organize log or displayed in the UI (when completing the organize
dialog).
This information is very important for the user. Examples are "No
permission", "Target folder not available", "Disk full", etc..
When a filename cannot be auto-matched to an existing series name, the
organization must be performed manually.
Unfortunately not just once, but again and again for each episode coming
in.
This change proposes a simple but solid method to optionally persist the
matching condition from within the manual organization dialog.
This approach will make Emby "learn" how to organize files in the future
without user interaction.
This new episode provider implementation does not bulk-download or cache
episode data. It is only meant to be a backup source for situations
where media is not recognized by the default provider (TheTvDb).
Especially with Multi-Episodes, the EpisodeTitle can become quite long,
since all comprised titles get concatenated into it.
By default, the EpisodeTitle is included in the single and multi-episode
naming patterns and this in turn can quickly lead to a
PathTooLongException.
This fix tries to keep as much as possible from the title string while
keeping the final path within the allowed limit.
