simpz 2 Posted March 5 Share Posted March 5 Hi I have an issue where when the container I have running TVHeadend is restarted the EmbyServer process goes to 100% CPU and stays there. If Emby is then restarted it goes back to normal largely idle. I have TVHeadend setup as a live TV source in Emby and seems to work fine. 1433350 emby 20 0 5266664 323020 54652 S 101.0 0.5 4:29.22 EmbyServer The TVHeadend and Emby Server run on the same Debian 12 machine. I see nothing in the logs of either subsystem. Anyone seen this before? Link to comment Share on other sites More sharing options...
Luke 37066 Posted March 6 Share Posted March 6 Hi there, please attach the emby server log from when the problem occurred. Thanks. Link to comment Share on other sites More sharing options...
Luke 37066 Posted March 7 Share Posted March 7 HI, if you wait until the cpu usage calms down, then run the refresh guide scheduled task, does it go back up again? Link to comment Share on other sites More sharing options...
simpz 2 Posted March 7 Author Share Posted March 7 The CPU never calms down that I can see, it stays at 100% a day after the TVHeadend was restarted. Link to comment Share on other sites More sharing options...
Luke 37066 Posted March 7 Share Posted March 7 If you remove the TVH plugin, how do things compare? Link to comment Share on other sites More sharing options...
simpz 2 Posted March 8 Author Share Posted March 8 It only happens when the Live TV TVH Plugin is enabled. Otherwise it doesn't happen. 1 Link to comment Share on other sites More sharing options...
simpz 2 Posted March 9 Author Share Posted March 9 A bit more analysis, it seems to maybe happen approx every once out of 2-3 times the TVHeadend is restarted. So not quite every times, just 33-50% of the time. Link to comment Share on other sites More sharing options...
simpz 2 Posted March 14 Author Share Posted March 14 Not sure if there is any more I can give you here. Maybe I could attached an strace to embyserver when it's spinning it's wheels? Link to comment Share on other sites More sharing options...
Luke 37066 Posted March 14 Share Posted March 14 9 hours ago, simpz said: Not sure if there is any more I can give you here. Maybe I could attached an strace to embyserver when it's spinning it's wheels? Sure. Link to comment Share on other sites More sharing options...
simpz 2 Posted March 15 Author Share Posted March 15 Okay the strace is interesting, and simple. From a threaded top: 2772754 emby 20 0 5527680 495148 92472 S 94.1 0.8 161:02.43 EmbyServer 2991061 emby 20 0 5527680 495148 92472 R 94.1 0.8 158:50.23 .NET ThreadPool , the 100% CPU is actually a ".NET ThreadPool" thread. Digging further (attached in an strace to this thread), you get a fast continuous stream of (50000-70000 per second!): recvmsg(236, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="", iov_len=1024}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 0 lsof on this pid we see this: Quote EmbyServe 2772754 emby 236u IPv4 10394798 0t0 TCP localhost:54552->servername.lan:9982 (CLOSE_WAIT) ,where "servername" is my server name, this is the same box running Emby as the TVHeadend Container. So the issue seems to be that the process is stuck waiting for a CLOSE_WAIT from the socket to the original TVHeadend Container (this has been restarted and is listening again on this port 9982). This CLOSE_WAIT is never likely to happen as the service (process) that Emby was opened to has now gone (container was torn down and brought back up again). Now it's possible things aren't so simple, as container networking has a lot of firewall manipulation for port forwarding ports, so maybe this old connection is just getting all it's packets dropped silently. But in any case, Emby probably shouldn't wait forever for a CLOSE_WAIT here and especially not in a tight loop! Thoughts.... 1 Link to comment Share on other sites More sharing options...
simpz 2 Posted March 22 Author Share Posted March 22 Any thoughts on this? Looks pretty clear cut to me... Link to comment Share on other sites More sharing options...
Luke 37066 Posted March 25 Share Posted March 25 Hi, for testing purposes, what if you remove the TVH plugin from Emby Server, and then import the TVH content into Emby Server using m3u? TVH has an m3u output feature so you could just use that without the plugin. It would be helpful to see how that compares. Thanks. Link to comment Share on other sites More sharing options...
simpz 2 Posted March 26 Author Share Posted March 26 curl -o channels.m3u -u admin:password http://servername:9981/playlist/channels.m3u I can create a channel.m3u but Emby doesn't like this type "No compatible streams are currently available. Please try again later or contact your system administrator for details." Link to comment Share on other sites More sharing options...
Luke 37066 Posted March 27 Share Posted March 27 12 hours ago, simpz said: curl -o channels.m3u -u admin:password http://servername:9981/playlist/channels.m3u I can create a channel.m3u but Emby doesn't like this type "No compatible streams are currently available. Please try again later or contact your system administrator for details." HI, can you please attach the emby server log? How to Report a Problem Thanks. Link to comment Share on other sites More sharing options...
Luke 37066 Posted April 1 Share Posted April 1 @simpz? Link to comment Share on other sites More sharing options...
simpz 2 Posted April 1 Author Share Posted April 1 I sent that to you privately I think Link to comment Share on other sites More sharing options...
Luke 37066 Posted April 9 Share Posted April 9 On 4/1/2024 at 4:53 AM, simpz said: I sent that to you privately I think HI, regarding m3u usage, please see if this helps: Thanks. Link to comment Share on other sites More sharing options...
simpz 2 Posted April 11 Author Share Posted April 11 So my channels.m3u file look like this and works with VLC. #EXTM3U #EXTINF:-1 logo="http://admin:password@server.lan:9981/imagecache/44" tvg-id="1879fe7c8731a05a75a73ea7dd8ad2c8" tvg-chno="1",BBC ONE EastHD http://admin:password@server.lan:9981/stream/channelid/2097051928 #EXTINF:-1 logo="http://admin:password@server.lan:9981/imagecache/45" tvg-id="ae1a5e99bf2b858fd0395d122abd24cf" tvg-chno="2",BBC TWO HD http://admin:password@server.lan:9981/stream/channelid/425597614 Where "password" is the real admin password of my tvheadend service. The log file shows: 2024-04-10 08:22:47.990 Info HttpClient: GET http://admin:password@host1:9981/x_path1_x/x_path2_x/x_path3_x 2024-04-10 08:22:47.990 Info HttpClient: Found userInfo in url: admin:password ... url: http://admin:password@host1:9981/x_path1_x/x_path2_x/x_path3_x 2024-04-10 08:22:47.991 Info HttpClient: Http response 401 from http://admin:password@host1:9981/x_path1_x/x_path2_x/x_path3_x after 1ms. Headers Server=HTS/tvheadend, Cache-Control=no-cache, WWW-Authenticate=Digest realm="tvheadend", qop=auth, algorithm=SHA-512-256, nonce="OBFUSCATE", opaque="OBFUSCATE" Digest realm="tvheadend", qop=auth, nonce="OBFUSCATE", opaque="OBFUSCATE", Connection=close Where OBFUSCATE is a secret hash I have obfuscated, and the password is shown as the plain text matching the above in the URLs from channels.m3u. However the "@host1:9981/x_path1_x/x_path2_x etc" doesn't match anything passed I can see. I could add the tvheadend container systemd unit file: ExecStartPost=/bin/systemctl restart emby-server.service But of course this doesn't help you address what is clearly a bug in Emby Server (or possibly (even likely) in the .NET framework), that if a connection drops out to the TvHeadend backend and just drops packets it waits for ever on CLOSE_WAIT. Seems like a very similar issue in dotnet but appears resolved? https://github.com/dotnet/runtime/issues/36293 Link to comment Share on other sites More sharing options...
Q-Droid 643 Posted April 11 Share Posted April 11 This works if you create a no-auth account in TVHeadend then credentials are not needed for the m3u streams. If you're worried about open access to TVH you can use source IP restrictions to limit account access. Link to comment Share on other sites More sharing options...
simpz 2 Posted April 12 Author Share Posted April 12 The no-auth account has indeed allowed M3U playlist to work and I can stream Live TV. The 100% CPU issue doesn't seem to occur on restarting the TVHeadend container. It seems pretty obvious why this might, with an M3U playlist I'd guess there is no connection being made until a stream is started. However, with a TVHeadend backend there is a persistent connection from Emby to TVHeadend (for TV Guide etc). So the issue with a connection not being closed properly an looping on close_wait will pretty much always occur with the TVHeadend backend. Did you look at the .NET Framework bug I posted that pretty much fits this? Is the version of the .NET framework you use, one that likely has this issue resolved or not? Link to comment Share on other sites More sharing options...
Luke 37066 Posted April 12 Share Posted April 12 Hi, we’ll take a look at it. Thanks. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now