Commit Graph
9 Commits
Author SHA1 Message Date
euzuandGitHub 4c5d966248 Reduce heap allocation (#764)
- Refactored PlaylistSource to avoid Box<dyn> whre possible
- Some other small heap allocation fixes
2026-05-28 17:58:41 +02:00
euzuandGitHub 31a48bc1f3 Feature/structured errors landing page (#705)
- structured errors
- landing page
- fix: table header background
2026-04-06 10:20:52 +02:00
euzuandGitHub 38813bb672 Feature/makefile ci and log with local time (#582)
- Add Makefile to simplify installing required tools
- Add CONTRIBUTING.md welcome new contributors
- Add fmt, lint, test tasks to makefile and update CONTRIBUTING.md
- Add CI workflow
-  Log with local date
2026-02-14 12:12:59 +01:00
euzuandGitHub 555bc2cce1 Feature/provider config (#570)
New Features
- Automatic provider failover & rotation across multiple provider URLs with a provider:// scheme and capped retries
- Configurable failover redirect patterns to influence retry/failover behavior
UI

- New interface to view and edit failover redirect patterns in reverse proxy configuration

- Expanded docs covering Provider Failover & Rotation and enriched messaging templating
Reliability

- Improved URL resolution, error reporting and logging for more robust provider handling
2026-02-10 11:53:42 +01:00
euzu ccdbf1dfce Retry request from reverseproxy retry options 2026-01-22 13:30:59 +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 1abf9e81c8 Updated database structure
- Using Slotted Pages
- Using compression
- Using file locking to prevent race conditions
2025-12-29 13:46:55 +01:00
euzu bd052562b9 web ui config pages 2025-08-13 23:07:21 +02:00
euzu 7f54327bfd config added to shared model 2025-06-19 16:37:37 +02:00