[Bug] Transcoding gets stuck in a loop when resuming playback on LG WebOS client #7234

Open
opened 2025-12-22 05:26:18 +01:00 by backuprepo · 6 comments
Owner

Originally created by @adgh-dev on GitHub (Aug 9, 2025).

Description of the bug

When playing a media file with DTS audio on an LG WebOS client, the server identifies the client as a "Web" player and initiates an audio transcode (even though the device natively supports DTS audio). Playback works fine initially.

However, if playback is stopped mid-way and then resumed after a significant delay (e.g., a few hours or a day), the transcoding process enters an infinite loop over a small segment of the video. On the client (LG TV), the image freezes, but the playback timer may flicker or not advance. On the server dashboard, the transcode process is shown to be repeatedly playing the same few seconds of the file (e.g., looping between 30:54 and 31:02).
This issue seems to be related to how Jellyfin handles resuming a stale transcoding session.

Jellyfin server is deployed in a docker container running on top of Ubuntu server 24.04. Local network connection between client and server.

Reproduction steps

  1. On an LG WebOS TV, open the Jellyfin client.
  2. Play a media file that requires audio transcoding (e.g., a file with DTS audio).
  3. Confirm on the Jellyfin server dashboard that the session is "Transcoding".
  4. Play the file for some time and then stop it at a random point (e.g., 30 minutes in).
  5. Wait for several hours or a day.
  6. Navigate back to the same media file and select "Resume".
  7. Observe that the image on the TV freezes.
  8. Check the server dashboard. The playback report will show the transcode process looping over a small time segment indefinitely.

What is the current bug behavior?

Video freezes while transcoding audio, when resumed at mid point after stopped for hours/days.

What is the expected correct behavior?

The media file should resume transcoding and playing from the point where it was stopped, regardless of how long the pause was.

Jellyfin Server version

10.10.0+

Specify commit id

No response

Specify unstable release number

No response

Specify version number

No response

Specify the build version

Server version 10.10.7 Web version 10.10.7 Build version 10.10.7

Environment

- OS:Ubuntu 24.04
- Linux Kernel: Linux vvb 6.8.0-64-generic #67-Ubuntu SMP PREEMPT_DYNAMIC Sun Jun 15 20:23:31 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
- Virtualization: Docker
- Clients: LG Oled WebOS TV
- Browser: - 
- FFmpeg Version:ffmpeg version 7.0.2-Jellyfin Copyright (c) 2000-2024 the FFmpeg developers built with gcc 12 (Debian 12.2.0-14)
- Playback Method: Direct Video, Trancoding Audio
- Hardware Acceleration: no
- GPU Model: - 
- Plugins: - 
- Reverse Proxy: no
- Base URL: /jellyfin
- Networking: Local
- Jellyfin Data Storage: local SSD
- Media Storage: local SSD
- External Integrations: no

Jellyfin logs

Attached as server-log.txt in the Additional information block.

FFmpeg logs

Attached as transcode-log.txt in the Additional information block.

Client / Browser logs

No response

Relevant screenshots or videos

No response

Additional information

This issue appears to be caused by the server trying to resume a transcode session where the temporary transcode segments from the previous session may have been cleaned up or are otherwise inaccessible.
The root of the problem is that the LG WebOS client is treated as a generic web client and is not profiled to direct play DTS, which modern LG OLED TVs fully support. A potential workaround/solution could be to update the WebOS device profile to allow DTS direct play, avoiding the transcode altogether. However, the bug with resuming a transcode session remains valid.

server-log.txt

transcode-log.txt

Originally created by @adgh-dev on GitHub (Aug 9, 2025). ### Description of the bug When playing a media file with DTS audio on an LG WebOS client, the server identifies the client as a "Web" player and initiates an audio transcode (even though the device natively supports DTS audio). Playback works fine initially. However, if playback is stopped mid-way and then resumed after a significant delay (e.g., a few hours or a day), the transcoding process enters an infinite loop over a small segment of the video. On the client (LG TV), the image freezes, but the playback timer may flicker or not advance. On the server dashboard, the transcode process is shown to be repeatedly playing the same few seconds of the file (e.g., looping between 30:54 and 31:02). This issue seems to be related to how Jellyfin handles resuming a stale transcoding session. Jellyfin server is deployed in a docker container running on top of Ubuntu server 24.04. Local network connection between client and server. ### Reproduction steps 1. On an LG WebOS TV, open the Jellyfin client. 2. Play a media file that requires audio transcoding (e.g., a file with DTS audio). 3. Confirm on the Jellyfin server dashboard that the session is "Transcoding". 4. Play the file for some time and then stop it at a random point (e.g., 30 minutes in). 5. Wait for several hours or a day. 6. Navigate back to the same media file and select "Resume". 7. Observe that the image on the TV freezes. 8. Check the server dashboard. The playback report will show the transcode process looping over a small time segment indefinitely. ### What is the current _bug_ behavior? Video freezes while transcoding audio, when resumed at mid point after stopped for hours/days. ### What is the expected _correct_ behavior? The media file should resume transcoding and playing from the point where it was stopped, regardless of how long the pause was. ### Jellyfin Server version 10.10.0+ ### Specify commit id _No response_ ### Specify unstable release number _No response_ ### Specify version number _No response_ ### Specify the build version Server version 10.10.7 Web version 10.10.7 Build version 10.10.7 ### Environment ```markdown - OS:Ubuntu 24.04 - Linux Kernel: Linux vvb 6.8.0-64-generic #67-Ubuntu SMP PREEMPT_DYNAMIC Sun Jun 15 20:23:31 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux - Virtualization: Docker - Clients: LG Oled WebOS TV - Browser: - - FFmpeg Version:ffmpeg version 7.0.2-Jellyfin Copyright (c) 2000-2024 the FFmpeg developers built with gcc 12 (Debian 12.2.0-14) - Playback Method: Direct Video, Trancoding Audio - Hardware Acceleration: no - GPU Model: - - Plugins: - - Reverse Proxy: no - Base URL: /jellyfin - Networking: Local - Jellyfin Data Storage: local SSD - Media Storage: local SSD - External Integrations: no ``` ### Jellyfin logs ```shell Attached as server-log.txt in the Additional information block. ``` ### FFmpeg logs ```shell Attached as transcode-log.txt in the Additional information block. ``` ### Client / Browser logs _No response_ ### Relevant screenshots or videos _No response_ ### Additional information This issue appears to be caused by the server trying to resume a transcode session where the temporary transcode segments from the previous session may have been cleaned up or are otherwise inaccessible. The root of the problem is that the LG WebOS client is treated as a generic web client and is not profiled to direct play DTS, which modern LG OLED TVs fully support. A potential workaround/solution could be to update the WebOS device profile to allow DTS direct play, avoiding the transcode altogether. However, the bug with resuming a transcode session remains valid. [server-log.txt](https://github.com/user-attachments/files/21698673/server-log.txt) [transcode-log.txt](https://github.com/user-attachments/files/21698674/transcode-log.txt)
backuprepo added the
stale
bug
labels 2025-12-22 05:26:18 +01:00
Author
Owner

@jfrancisco-neto commented on GitHub (Aug 10, 2025):

This happened to me too and doesn't even need to wait long, just try to skip forward a big video file.

@jfrancisco-neto commented on GitHub (Aug 10, 2025): This happened to me too and doesn't even need to wait long, just try to skip forward a big video file.
Author
Owner

@nyanmisaka commented on GitHub (Aug 10, 2025):

You can give 10.11-RC4 a try and see if there is any change.

@nyanmisaka commented on GitHub (Aug 10, 2025): You can give 10.11-RC4 a try and see if there is any change.
Author
Owner

@jfrancisco-neto commented on GitHub (Aug 12, 2025):

10.11.0-rc4 Fixed the issue for me but add some issues with audio. The previously stream didn't have any issues with audio and now it says the audio channel is not compatible and need to transcode it:

The video stream is compatible with the device, but has an incompatible audio format (DTS, Dolby TrueHD, etc.) or number of audio channels. The video stream will be repackaged losslessly on the fly before being sent to the device. Only the audio stream will be transcoded.
Power consumed by direct streaming usually depends on the audio profile. Only the video stream is lossless.
@jfrancisco-neto commented on GitHub (Aug 12, 2025): 10.11.0-rc4 Fixed the issue for me but add some issues with audio. The previously stream didn't have any issues with audio and now it says the audio channel is not compatible and need to transcode it: ``` The video stream is compatible with the device, but has an incompatible audio format (DTS, Dolby TrueHD, etc.) or number of audio channels. The video stream will be repackaged losslessly on the fly before being sent to the device. Only the audio stream will be transcoded. Power consumed by direct streaming usually depends on the audio profile. Only the video stream is lossless. ```
Author
Owner

@adgh-dev commented on GitHub (Aug 12, 2025):

@jfrancisco-neto wasn't it transcoding audio before? The reported issue is strictly related to audio transcoding

@nyanmisaka do you have some pointers on testing non-released/RC versions? I run jellyfin server in docker container, so would need a registry where I can fetch the RC from

@adgh-dev commented on GitHub (Aug 12, 2025): @jfrancisco-neto wasn't it transcoding audio before? The reported issue is strictly related to audio transcoding @nyanmisaka do you have some pointers on testing non-released/RC versions? I run jellyfin server in docker container, so would need a registry where I can fetch the RC from
Author
Owner

@nyanmisaka commented on GitHub (Aug 12, 2025):

do you have some pointers on testing non-released/RC versions? I run jellyfin server in docker container, so would need a registry where I can fetch the RC from

Read the changelog, back up your data, then switch from jellyfin/jellyfin to jellyfin/jellyfin:10.11.0-rc4 and wait for the database migration to complete.

https://hub.docker.com/r/jellyfin/jellyfin/tags?name=10.11

@nyanmisaka commented on GitHub (Aug 12, 2025): > do you have some pointers on testing non-released/RC versions? I run jellyfin server in docker container, so would need a registry where I can fetch the RC from Read the [changelog](https://notes.jellyfin.org/v10.11.0_features), **back up your data**, then switch from `jellyfin/jellyfin` to `jellyfin/jellyfin:10.11.0-rc4` and wait for the database migration to complete. https://hub.docker.com/r/jellyfin/jellyfin/tags?name=10.11
Author
Owner

@jellyfin-bot commented on GitHub (Dec 11, 2025):

This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs.

If you have any questions you can use one of several ways to contact us.

@jellyfin-bot commented on GitHub (Dec 11, 2025): This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs. If you have any questions you can use one of several ways to [contact us](https://jellyfin.org/contact).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#7234
No description provided.