Seanime: Fix Transcoder Issue For HLS Streaming

by Admin 48 views
**Seanime Bug: Transcoder Destroyed on Playback**

Hey guys,

I'm here to talk about a pretty annoying bug I've found in Seanime, specifically related to the transcoder and HLS streaming. This is a big deal because it completely breaks the ability to watch videos on mobile devices when using the "Transcode" option. Let's dive into the details and hopefully get this fixed!

The Problem: Transcoder Lifecycle and HLS Failure

The core issue revolves around how Seanime handles the transcoder process. The transcoder, which is responsible for converting videos into a format suitable for streaming, is being destroyed and recreated with every single playback request. This is like tearing down a building every time someone wants to walk through the door and then rebuilding it – completely inefficient and, in this case, a total showstopper for HLS (HTTP Live Streaming).

Why is this happening?

  • Transcoder Destruction: Every time you hit play, the transcoder is killed off. This means any ongoing FFmpeg process, which is used to generate the necessary .ts segments for HLS, is abruptly stopped.
  • Cache Clearing: The /cache/transcode/streams/ directory, where these crucial .ts files are supposed to be stored, gets wiped clean on each playback attempt. So, even if FFmpeg did manage to start, it wouldn't have anywhere to put the segments.

Steps to Reproduce the Bug:

  1. Fire up Seanime.
  2. Pick a video file.
  3. In the streaming options, select "Transcode."
  4. Hit the play button.
  5. Watch as the video endlessly buffers, never actually playing.
  6. Check /Library/Application Support/Seanime/cache/transcode/streams/ and notice that it remains empty. No .ts files are being generated, confirming the HLS breakdown.

Impact and Expected Behavior

The most significant impact of this bug is the complete failure of HLS streaming. This means that when you try to access Seanime from a mobile device on your local network (e.g., using your server's IP address), the video just won't play.

What we expect:

When accessing Seanime from a mobile device on the local network (e.g., http://192.168.1.156:43211), media streaming through the /mediastream endpoint should work correctly. The video should load and play without errors, just as it does when accessed locally on the host machine.

System Information

For context, here's the environment where this bug was observed:

  • OS: macOS (darwin/arm64)
  • Seanime Version: 3.0.1-Rettō
  • Hardware Acceleration: VideoToolbox
  • Browser: Chrome

Detailed Logs and Evidence

Here are some snippets from the logs and console that highlight the problem:

Server Logs: Key Takeaways

  • The server logs show the transcoder being initialized and then destroyed immediately after each playback request.
  • You'll see lines like: DBG| transcoder > Destroying transcoder, followed by DBG| transcoder > Transcoder destroyed. This cycle repeats endlessly.
2025-11-09 13:38:09 |DBG| mediastream > Transcode stream requested filepath="/Users/eugenefedotov/Anime/[Reaktor] Prison School - E11 Uncensored v2 [1080p][x265][10-bit][Dual-Audio].mkv"
2025-11-09 13:38:09 |DBG| transcoder > Destroying transcoder
2025-11-09 13:38:09 |DBG| transcoder > Transcoder destroyed
2025-11-09 13:38:09 |INF| transcoder > Initialized

Mobile Chrome Console Logs:

The browser console on a mobile device accessing Seanime provides further clues:

  • You'll see messages indicating that the media container is loading and the stream URL is being set.
  • However, the console also shows that the codec isn't supported and the stream type is transcode, which is expected.
  • The critical issue is the repeated attempts to change and update the URL which never successfully completes.
[MEDIASTREAM]  Stream type is transcode
[MEDIASTREAM]  Codec not supported for direct play video/x-matroska; codecs="hvc1.1.4.L78.BO, mp4a.a5"
[MEDIASTREAM]  Stream URL available /api/v1/mediastream/transcode/master.m3u8
[MEDIASTREAM]  Changing URL http://192.168.1.156:43211/api/v1/mediastream/transcode/master.m3u8 streamType: transcode

Debugging and Potential Fixes

Based on the logs and observed behavior, here's what needs to be addressed:

  1. Transcoder Lifecycle Management: The transcoder needs to persist across multiple playback requests. It should be initialized once and reused to generate the HLS segments. Only when the user stops playback or the video is finished should the transcoder be shut down.
  2. HLS Segment Generation: Ensure that FFmpeg is allowed to run long enough to generate the .ts segments. The current behavior of killing the process on every request prevents this.
  3. Cache Handling: The /cache/transcode/streams/ directory shouldn't be cleared on every request. It should be used to store the generated segments. The cache could be managed by deleting old segments periodically to save storage space.

Call to Action

If you're experiencing this issue, please chime in! The more people who can confirm this bug, the more likely it is that the developers will prioritize a fix. Also, any insights or workarounds you've found would be greatly appreciated.

Let's get this fixed so we can all enjoy seamless streaming on our mobile devices!