wmichael3 7 Posted September 3, 2020 Posted September 3, 2020 (edited) I've looked at other postings of this type but don't see anything really exactly similar to this situation - Situation: Chromecast goes black (no image or sound) after pause/resume of Live TV (on NBC, ABC, CBS and Fox) The problem only appears on Live TV - much higher resolution/bitrate/bandwidth movies do not have the problem. Android controlling Chromecast Gen 3 that is wired, not wireless - using gigabit adapter. Playback set to auto. Stream is 720p Comcast via HD Homerun Prime. Stream runs as "Direct Streaming" in the Emby dashboard. No CPU issues on server or network bottlenecks. Network is wired gigabit ethernet. Server indicates 6-8Mbps network load. When the screen goes dark, Emby console indicates that playback continues. However, the play timer in the dashboard panel changes from elapsed time of the stream to "--:--:--" At this point I can't look at the log because it is open. I can see that ffmpeg is still an active process. Android app generally may or may not show connection to Chromecast, but Google Home shows that the Chromecast is still connected to Emby. To look at the log I must first use Google Home to stop the stream. When I do that the Chromecast images reappear on the screen without further intervention - the standard pretty scenery. The logs are attached. The stream started at about 2pm and the screen probably went black about 3:30pm and then I stopped it at 4:03pm. From the log the stream appears to have continued processing normally until I used Google Home to stop it. You can see me stopping it in the log. But there was a black screen a long time before then. When this happens we typically just restart the channel, but it is starting to get annoying. A restart always works perfectly. Have not seen this behavior with Netflix or Prime casting (or before moving to Emby when I used WMC against the same tuner on the same server and network) Full log files attached. Any thoughts? This happens regularly on a TV that is left on during the day and we've also seen it on a second TV with a 4K Chromecast. I've swapped the Chromecast and the ethernet adapter and the HDMI port. Nothing helps. ffmpeg-remux-705a89cd-012e-42b9-9941-6abe02ef7fbf_1.txt embyserver.txt Edited September 28, 2020 by wmichael3 Minor edit/new info.
Luke 38842 Posted September 22, 2020 Posted September 22, 2020 Hi there @wmichael3 can you please try the new Emby Server 4.5 release and see if this helps? Thanks !
wmichael3 7 Posted September 22, 2020 Author Posted September 22, 2020 Thanks! I have upgraded the server and so far, so good. Tested last night and could not reproduce the problem; my "solution" above about faster transcode storage was a red herring and did not solve the underlying problem. I will update this post in a day or two if it appears to be a permanent fix. By the way, it was not just a matter of the Chromecast connection dropping after extended play time - pausing live TV frequently caused the issue immediately after resuming. At first test, that is also resolved.
Luke 38842 Posted September 22, 2020 Posted September 22, 2020 That's great, thanks for the feedback.
wmichael3 7 Posted September 23, 2020 Author Posted September 23, 2020 (edited) Hey @Luke, new information - the problem was not solved with the 4.5 server. What I finally noticed is that the problem is channel dependent. The problem I can consistently and easily reproduce is a variation of what I originally reported: - When using a Chromecast, If I pause live TV for a minute or longer and then resume, the playback will resume for a couple seconds and then the screen will go black (playback of video and audio will cease) - when I look at the dashboard right then, it will be "Direct Streaming" and the left time counter will count from 00:00:00 to maybe 00:00:18, then reset to "--:--:--" and start over back to 18 seconds or something close to that. This is from an HD Homerun Prime with Comcast as the provider. I can restart the stream with my phone without error but any saved buffer will be lost. I can't access the log until I force the stream to stop by restarting it or disconnecting the Chromecast. I'm using a newish 4K Chromecast that is on ethernet, not WiFi. - I noticed that this is completely consistent with our local Comcast NBC affiliate, but on a national stream (MSNBC) I cannot reproduce it - it works flawlessly. The only difference between these two channels that I can see is that the NBC affiliate (the channel with the problem) has a video codec of "H264 Main" with a video bitrate of 576kbps and MSNBC (the channel without the problem) has a video codec of "H264 High" and a video bitrate of 384kbps. Everything else in Stats for Nerds is the same between the two channels. Both are 1280x720 HLS streams. - I have never observed a problem with recorded TV - just live. Later that evening: confirmed that the problem appears to be limited to the four big network local affiliates: ABC, NBC, CBS and Fox. It does not occur on any basic cable station that I've tried (i.e. HGTV, Bravo, ESPN, Comedy Central...) or the local PBS station or another local independent, both of which also broadcast OTA locally. Just those four network channels. Logs: I finally have a good log that shows the problem. This log shows I was using Intel QSV, but if I disable that and just use software I get a similar error. In this example I ran the stream for a minute, paused for a minute and then resumed. 9 seconds later the playback stopped with a black screen. More: The problem occurs, as said above, for the 4 network channels under Direct Streaming. If I force transcoding it appears to work fine for the most part - except that after a pause/resume it can also die if it tries to go back to Direct Stream - I have to set the bitrate limit low enough to prevent that.. Hardware acceleration versus software decoding does not seem to make a difference - it will fail on software decoding as well. It is the combination of those 4 channels plus Direct Stream that consistently fails after a pause/resume - only on Chromecast. ffmpeg-transcode-2b496073-efc4-4a59-abf9-540de5409327_1.txt Edited September 23, 2020 by wmichael3 New info.
wmichael3 7 Posted September 24, 2020 Author Posted September 24, 2020 More info - with hardware transcoding turned off, here is the initial major difference in the logs - in the NBC log (where pausing live TV to Chromecast causes the direct stream to fail) there are these lines that aren't in the MSNBC log (where it works ok). To reiterate, NBC plays fine as long as you don't pause the stream. As soon as you do, it dies a few seconds after resume. >>>>>> Affected codecs Encoder libx264 Software Encoder Profiles: Baseline Profile (Level 6.2), Main Profile (Level 6.2), High Profile (Level 6.2), High 10 Profile (Level 6.2), High 4:2:2 Profile (Level 6.2), High 4:4:4 Predictive Profile (Level 6.2) >>>>>> FindVideoEncoder - Media: h264, UseHardwareCodecs: True, Mode: NoHardwareCodecs Info Checking: 'libx264 Software Encoder' Warning: The required encoding level (AvcLevel51) is greater than the maximum level supported by the client (AvcLevel42) Info Check successful - selecting 'libx264 Software Encoder' >>>>>> FindVideoDecoder - MediaType: h264, Mode: NoHardwareCodecs Info Checking: 'Automatic software decoder' Info Check successful - selecting 'Automatic software decoder' I attached the complete log for the NBC failure with hardware transcoding turned off. ffmpeg-transcode-583c43af-51c6-4d25-879f-3c5a7c140bf3_1.txt
wmichael3 7 Posted September 28, 2020 Author Posted September 28, 2020 Update: went to beta 4.6.0.1 - no improvement. Pause/Resume still fails live streaming to Chromecast from the 4 network Comcast channels. (NBC, CBS, ABC, Fox). I have noticed that it may take up to 10 seconds for the stream to fail after Resume. But it is a reliable failure as long as I pause for at least 10 seconds. Also, .SRT subtitles to Chromecast are also broken - they used to work fine - just noticed that last night. However, .sub/.idx still works ok. I will attach logs if anyone responds to me. Moving from WMC to all-Emby-Chromecast has been more challenging than I thought it would be.
wmichael3 7 Posted October 13, 2020 Author Posted October 13, 2020 Haven't seen any response to this - it is a bit frustrating to explain to the spouse that she can't pause any of the 4 old-timey networks live but she can the rest of your basic cable. So I thought I'd upload some more logs. In this case I started a live NBC stream at about 11:52, paused it several minutes later, waited until just after 12:00 and then restarted the stream. It then continues to play for a few seconds before the screen blanks. - The remux log is the log of the initial stream. It appears to stop by design when the stream is resumed (not after the pause). - The transcode log is a new log that is created after I try to resume the live stream. Seems to be a bigly fail. Note that here QSV is turned on, but it still fails if it is off. QSV works fine in all other cases. - Also uploaded the embyserver log after the failure occurred. I said this before, but the failure seems to be associated with Direct Stream on these four h264 (Main) channels (NBC, ABC, Fox, CBS) on Comcast. It all works fine as long as we don't press Pause. If I force transcoding that will generally fix the problem, but I have to set the bandwidth quite low for it not to try Direct Stream again. Low enough to impact picture quality. Otherwise after a bit it will try to Direct Stream again and the Pause/Resume will fail. The other cable channels don't have this problem - they all read as "h264 (High)" while the 4 old-timey networks are "h264 (Main)." Playing back recorded TV also works fine. Oh, also, if we don't Pause but try to rewind (move backward in time) then that fails as well. Any acknowledgement or response of any kind would be greatly appreciated! Mike ffmpeg-remux-646f12e5-4f16-4b28-9ae2-145fa4db227b_1 (2).txt ffmpeg-transcode-8f095538-8292-4dda-83c6-c0898fd5d4e5_1.txt embyserver (3).txt
Luke 38842 Posted November 3, 2020 Posted November 3, 2020 @wmichael3 are you still running into this?
wmichael3 7 Posted November 3, 2020 Author Posted November 3, 2020 Yes, it has been 100% reproducible on the 4 network channels that are h.264 (Main). I am on 4.6.0.4.
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