mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-07-16 05:43:54 +03:00
10.11.4 HDHomeRun tuner locking #7901
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Esslingers on GitHub (Dec 11, 2025).
Description of the bug
Im using Jellyfin 10.11.4 and I have 3 HDHomeRun tuners setup. When I tune to a channel, it plays just fine. HDHomerun reports 100% signal strength, Signal quality is 98% and symbol quality is 100%. After exiting the stream I can see on the HDHomerun that the tuner is still locked/in-use and I see bandwidth still coming into Jellyfin, despite the fact that the client has stopped streaming and ffmpeg has terminated.
I did find a similar GitHb report that you guys wont fix because you said its an ffmpeg bug, but its related to signal quality and streams getting interrupted, this is NOT the case here.
https://github.com/jellyfin/jellyfin/issues/13877
If I use TVHeadend to feed LiveTV into Jellyfin I don't have any issues with tuner locking/in-use post stream termination, but when I natively add the tuners to Jellyfin is where I'm experiencing this issue.
Reproduction steps
What is the current bug behavior?
Jellyfin never gracefully drops the stream from the tuner. Tuner is unseable and required a reboot/power cycle to use again.
What is the expected correct behavior?
Upon stream termination by a client, it frees up the tuner. TVHeadend and Plex both do this correctly.
Jellyfin Server version
10.11.4
Specify commit id
No response
Specify unstable release number
No response
Specify version number
10.11.4
Specify the build version
10.11.4
Environment
Jellyfin logs
FFmpeg logs
Client / Browser logs
No response
Relevant screenshots or videos
No response
Additional information
No response
@Esslingers commented on GitHub (Dec 11, 2025):
either this is random luck or this may be a Jellyfin client issue. Using a web browser to view the stream, I see the tuner unlock right away. In Roku and Android apps it wont unlock the tuner after.
This is what I see on the HDHomeRun after a successful stream termination:
20251211-20:44:50 Tuner: tuner0 http stream ended (remote closed)
@VTRunner commented on GitHub (Dec 12, 2025):
I've been looking at this for both Android and Roku. Here is what I've found when running with server 10.11.4:
For the JF android client there is a workaround, which is to use the web player in the client. (Change at Settings->Client Settings->Video Player Type)
My plan going forward for Roku is to try to identify what changed between 3.0.12 and 3.0.13 that causes the tuner to not be released. For Android I'm going to set up an LXC where I can run old server versions to see if something changed, possibly between 10.10.x and 10.11.x, that makes the Android client's current tuner release request not work. (Ideally a code change could be made in the JF Android client since we know the server CAN release tuners.)
Update: I've confirmed that the current JF Android client (v2.6.3) does correctly release tuners when used with Jellyfin Server v10.10.7. The same client fails to release tuners when I upgrade that JF Server instance to v10.11.0. I'll try to find what the most recent JF server needs from the client to release tuners.
@rob297 commented on GitHub (Dec 12, 2025):
I am having the same issue. It works fine and unlocks the tuner until the stream has been running for some time. I did notice the problem after updating the firmware in the HDHomerun to 20250815. I am sending an email to see if I can try and go back on the firmware to test. However Jellyfin keeps executing an ffmpeg task to try and start encoding the m3u8 file. It repeats . A restart of Jellyfin stops this and the channel is avaliable again. With the tuner released in the HDHomerun and you try in jellyfin it fails until you restart Jellyfin. That ffmpeg task will continue to execute until you restart Jellyfin. Then everything works fine. Until you watch a channel for a long period of time and it locks up again.
@VTRunner commented on GitHub (Dec 14, 2025):
I have found that jellyfin server 10.11.x needs liveStreamId to be provided with playback start for it to be able to close the tuner when playback ends. Server 10.10.7 did not have this requirement. The change is that in 10.11.x a dictionary list is built of liveStreamId, and if the playback end call provides a liveStreamId that is not in this list, then it will not release the tuner until the server is restarted. The list is built based on an expectation that liveStreamId is being provided in the playback start and progress calls. The android client does not currently provide liveStreamId with the start or progress calls, but the web client provides it with both calls.
I have a locally built copy of the most recently released Jellyfin android client (v2.6.3) that is changed to provide liveStreamId with playback start and progress calls, and it successfully releases tuners. However, I'm having an issue with the android jellyfin:main branch. I've opened issue 1869 on the android repository to see how to proceed with the PR. (Any suggestions are welcomed!)
I'll start looking at the JF Roku tuner release issue now.
@nategee commented on GitHub (Dec 15, 2025):
Having the same issue with Roku client. I transcode to the Roku client, so after an hour or so they'll disconnect but the tuner stays locked and the transcode just keeps growing. I had my HDHomerun quad tuner on the previous release but just upgraded to 20250815 to see if that helped, no good.
If I reboot the HDHomerun obviously the tuners are freed and the transcoding stops.
-Summary
Roku Client with transcoding
10.11.4 for Server, Web, and Build
20250815 for the HDHomerun firmware
@nategee commented on GitHub (Dec 15, 2025):
So based on your comments its an issue with the client type? If so, then the Roku must have issues as well as that is my issue with the tuners not being released. Web works just fine, just the Roku clients.
@VTRunner commented on GitHub (Dec 15, 2025):
Yes, the tuner release issue is specific to the client. In my testing the web client and the jellyfin media player correctly release tuners, but the android mobile and roku clients do not. (This is all of the clients I can test.)
Both the JF android and roku clients are going to require code changes to fully fix the tuner release issues. However, I did find workarounds for both clients that will allow correct tuner releases:
If you need subtitle burn in when transcoding on Roku, or functionality specific to the Integrated player in android then I apologize, I do not have a solution right now. While the bug behavior was similar in the two clients, the root causes were different. The needed code changes for the final fixes will need to go through the normal release cycles for each client, and I'm working to get those submitted.
@ThyGhy commented on GitHub (Dec 16, 2025):
I also hit the same issue after upgrading to 10.11.x, and have only had it occur on the Roku client.
I've been using a workaround shell script to force release tuners of the HDHR, It works but means you have to clear tuners at your own pace.
Firstly, you're gonna need to extract hdhomerun_config from https://github.com/Silicondust/libhdhomerun
Build Example
sudo apt update
sudo apt install -y git build-essential
git clone https://github.com/Silicondust/libhdhomerun.git
cd libhdhomerun
make
./hdhomerun_config
The script will prompt for your HDHomeRun IP and (if needed) the path to hdhomerun_config
hdhr-force-release.sh
Example Commands
./hdhr-force-release.sh --device 192.168.1.50 --bin /home/user/libhdhomerun/hdhomerun_config --tuners 0,1
./hdhr-force-release.sh --tuners 0,1
A little bit of a workaround but hopefully this helps someone until this can get fixed!
Small Edit: I tested VTRunner’s workaround above and it works. It’s a better fix for this problem. If you still need burn-in subtitles during transcodes, this script can still be useful as a workaround.
@VTRunner commented on GitHub (Dec 16, 2025):
I've opened PR #627 in the JF Roku repository for the fix of this issue in the Roku client.
I'm waiting for a response from the JF android team for how to submit the PR since I'm having issues with the integrated player when I build from master from that repository.
@VTRunner commented on GitHub (Dec 29, 2025):
The fix for the JF Roku client tuner lock was implemented with the 3.0.15 Roku client release.
For android I'm still awaiting a response to issue 1869 to be able to submit the PR for the fix.
@Esslingers commented on GitHub (Jan 27, 2026):
I just verified that the Roku bug is fixed, but the bug still exists on Android. Tested on my Pixel 8 phone.
@VTRunner commented on GitHub (Jan 27, 2026):
@Esslingers Thank you for the check! The android jellyfin team has merged the PR that I submitted for the fix, and has targeted it to be released as part of v2.7 of the Android client. I don't have any insight on when v2.7 may be released. In the interim the workaround is to use the web player (instead of the integrated player) in the android client.
@Esslingers commented on GitHub (Jan 27, 2026):
@VTRunner ....thanks for the update! Do we know if this is also a bug on AppleTV?
@VTRunner commented on GitHub (Jan 28, 2026):
@Esslingers I did a quick search of issues in the Swiftfin github repository and didn't see any reports of tuners locking. However, I don't have any Apple devices and don't program for Apple, so I'll have to defer to others that can verify functionality.
@jrbski commented on GitHub (Jan 30, 2026):
I can't confirm the same issue on Swiftfin 100%, as I haven't replicated the issue so far. I was testing Swiftfin on IOS (iPad mini 5), and it appears that I experienced the tuner lock issue. I got the "HDHomeRun simultaneous stream limit has been reached" error and could not start any LiveTV sessions on the same iPad with the standard Jellyfin client, or on Safari. I'm fairly sure Swiftfin was no longer running.
I found that restarting the Jellyfin server released the locks, and got things working again. I did not need to do anything with the HDhomerun to recover. Note this was with server v10.11.6