Skip to content

Rewrite and fix plugin cache file(s) logic #6501

@bastimeyer

Description

@bastimeyer

Opening this as a task for myself...

Streamlink's Cache implementation used for storing plugin data and cookies is not ideal and should finally be fixed.


Main issues:

  • A single plugin-cache.json file is used among all plugins
  • That single file is accessed whenever any plugin class is initialized, meaning a file-exists check, a file-read operation, data pruning and a file-write operation
  • Data is stored in potentially non-unique key-value pairs, with arbitrary key prefixes (cookies and other cache data are mixed)
  • Data is written as soon as any key is updated (really bad for storing multiple cookies, especially since everything is monolithic JSON data from all plugins combined)
  • The file path on macOS is based on Linux's XDG base dir spec, which is wrong

Related issues:

  • Plugin cookies are always loaded and we don't have an option to disable that behavior
  • There's the Zattoo plugin which uses a separate cache instance on the same file instead of the main Plugin.cache instance, because of the key namespace nonsense. Two independent cache instances with their independent file handles are not supported, which means this is broken when writing data to both.

Plan:

  • Implement a new PluginCache class and deprecate the old Cache one
  • Move plublic interfaces to streamlink.plugin.api, as this is the intended package for plugin implementors to import from
  • Make plugins use their own respective cache file (that should already fix the main key-value namespace issue)
  • Make it write data in batches on object destruction or with a debounce timer
  • Split cookie data and other data into their own distinct namespaces
  • Fix the macOS file path and add fallback logic for the old path
  • Optionally implement (temporary) translation logic for moving the old monolithic data into separate plugin files
  • Optionally implement a separate cache file for cookies, similar to the curl cookie file format

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions