Update README

[NicholasLe04]

Simple PR to test pr review bot

[sce-pr-review-bot]

[MEDIUM] Overall: The new HLS stream management introduces a robust rotation mechanism that kills and restarts the FFmpeg process, and cleans up old segments, when a signal (via hls_lock) is received. This enhances stream stability and control. However, this rotation might introduce a momentary interruption in the HLS feed, which could be noticeable to clients depending on buffering strategies and network conditions.

[sce-pr-review-bot]

[MEDIUM] The condition for releasing interlude_lock has been expanded to include video_type == State.PLAYING. This means an interlude will now play after a video process exits if it was of type State.PLAYING, regardless of its exit code (e.g., even if it was forcibly stopped). This is a change in behavior for interlude playback.

[sce-pr-review-bot]

[MEDIUM] server.py (line 88): The default value for play_interlude_after in create_ffmpeg_stream has been changed from False to True. This means any calls to this function that do not explicitly specify play_interlude_after=False will now result in an interlude playing afterwards. This could lead to unintended interlude playback if existing callers relied on the previous default behavior.

[sce-pr-review-bot]

[CRITICAL] The HLS stream rotation logic in run_hls_stream has a critical flaw regarding the hls_lock initialization and usage. hls_lock is initialized as unlocked. When run_hls_stream starts, it immediately starts an FFmpeg process for HLS, then acquires the hls_lock (which succeeds immediately as it's unlocked), kills the FFmpeg process it just started, cleans the directory, starts another FFmpeg process, and then blocks indefinitely on the second hls_lock.acquire() call because no hls_lock.release() has occurred yet. This leads to an immediate, unnecessary rotation of the HLS stream on startup, followed by indefinite blocking of the HLS rotation mechanism until the first external hls_lock.release() signal is received from another thread (e.g., when a video starts or stops).

[sce-pr-review-bot]

[MEDIUM] server.py (line 374): The finally block in play_file was commented out, removing the interlude_lock.release() call that previously ensured the interlude stream would resume regardless of exceptions during video playback setup. While interlude_lock.release() is still called within create_ffmpeg_stream (if play_interlude_after is True), an exception occurring before create_ffmpeg_stream (e.g., during video download or cache operations within download_and_play_video) would now prevent the interlude_lock from being released. This could leave the interlude stream permanently blocked, reducing the system's robustness for interlude recovery.

[sce-pr-review-bot]

[LOW] The logging message logging.info(f"process {process.pid} started for {video_type.value} video: {video_path}") is placed after process.wait(). At this point, the FFmpeg process has already exited, not 'started'. For accurate logging, this message should be moved to immediately after subprocess.Popen to reflect when the process actually begins execution.