Commit Graph
8 Commits
Author SHA1 Message Date
knylbyteandGitHub f8ae4c9d56 fix: use manual redirects only for http proxies and apply proxy setting to ffprobe subprocess (#612)
* fix: use manual redirects only for http proxies
* fix: sync panel api on manual playlist update
* fix: route ffprobe probes through configured proxy
* fix: handle non-unicode proxy env vars safely
* fix: serialize panel api sync and align sync naming
* fix: manually follow hls redirects when proxy is configured
* fix: align hls manual redirect with proxy scheme
* fix: emit playlist update failure when lock is closed
* fix: align probe and scheduler paths for upstream merge
* fix: remove playlist lock retry and name hls redirect limit
2026-02-26 20:36:01 +01:00
euzuandGitHub 7b8bdaa49b Feature/stream probe (#585)
Stream probe
2026-02-14 17:52:35 +01:00
euzu 8cc9283a31 Playlist Update Optimization: Reduced Memory Usage
An optimization has been introduced to reduce memory consumption during playlist updates.

Overview
Previously, provider playlists were fully loaded into memory during the update process. For large playlists (e.g. hundreds of thousands of entries or multiple providers), this could result in significant RAM usage.
With the new implementation, it is now possible to optionally read provider playlists directly from disk instead of keeping them entirely in memory.

How It Works
 - users can configure whether:
     - Provider playlists are loaded into memory (previous behavior), or
     - Provider playlists are streamed to/from disk to minimize RAM usage.

Processing remains sequential and batch-based, ensuring identical functional behavior.
This approach significantly lowers peak memory usage, especially on systems with limited resources.

Benefits

- Reduced peak RAM consumption during playlist updates
- Better scalability for large playlists and multiple providers
- Full backward compatibility

Trade-offs / Drawbacks

 - Increased processing time due to reduced in-memory caching
 - Higher disk I/O usage, especially for large or fragmented playlists
 - Performance depends more strongly on disk speed (Nvme SSD, HDD)
 - Slightly increased CPU overhead due to repeated parsing and deserialization
 - Not optimal for environments where fast updates are more important than memory usage

Recommendation

 - Use in-memory mode for systems with sufficient RAM and a focus on update speed
 - Use disk-based mode for large playlists, multiple providers, or memory-constrained environments
2026-01-08 15:11:12 +01:00
euzu eb087825d5 Inputs in source.yml 2026-01-03 18:06:25 +01:00
euzu 30a88bb2ae user editor form 2025-08-26 23:34:04 +02:00
euzu 3cf00a809f api_proxy refactored 2025-06-19 17:20:36 +02:00
euzu 068150561a moved constants, size_utils, string_utils to shared 2025-06-19 13:22:43 +02:00
euzu 2a9c8711e6 project shared added 2025-06-19 12:45:55 +02:00