Roku beta video error Live TV

[bardmaster 17]

Hi, I am on the Emby Server Beta 3.2.12.11 with the Roku beta channel and am periodically getting "Video error:  An unexpected problem (but not server timeout or HTTP error) has been detected" when watching HD live TV.

 

My server runs Windows Server Essentials 2012R2 with a Core i7-3770 and 16GB RAM.  I am running HDHomeRun Prime with firmware version 20161117 with a Comcast cablecard.  I have been a Plex person for several years and share my media to TVs via Roku, but they don't have a native Live TV function.  I do use the HDHRViewerV2 plug-in, which has come a long way but is still prone to errors, lacks polish, and is not integrated well.  Nor does it allow recording, for which I run NextPVR - but often those videos record a bit choppy and I cannot control this via Roku.

 

So I am trying Emby as it looks well-integrated for all these needs and appears to record video quite cleanly.  But all is lost unless I can stream to my 5 TVs via 5 Roku devices.

 

Right now I am testing on a Roku2 (4210R) on a gigabit ethernet with Xfinity 100Mbps (120 on speedtest.net), with video quality set to 2.5Mbps.  I am simultaneously playing a separate HD channel on my Windows 10 PC via Chrome and it is still playing back well - just one pause in the past half-hour or more.

 

But the Roku2 crashed with the above error, after about 15 minutes.  Attached are the most recent logs.  Any thoughts?

 

BTW When I had the Roku quality set to AUTO I would get way too many "loading" bars while watching.  So I settled on the 2.5Mbps which looks fine on a 32" TV.  But in both cases I have experienced the video error mentioned above.

ffmpeg remux.txt

ffmpeg transcode.txt

server log.txt

Edited April 21, 2017 by bardmaster

[Luke 42078]

hi @@bardmaster, welcome. I notice the input is 60fps and it looks like ffmpeg is just barely keeping up with that. I wonder if we should consider reducing the framerate as part of the transcoding process. I can talk to @@ebr about putting up a beta build that would allow you to test that.

[bardmaster 17]

Thanks, happy to help.  Also note the purple rain on the Chrome video that I had running for 4+ hours - the video was still going, audio was fine, but every 3 seconds or so the screen washed out with color.

[bardmaster 17]

Also, this morning I'm having trouble starting up live TV, I am getting the "Video Error: The connection timed out" almost every time.  Same specs as posted above with a modest 2.5Mbps quality.  I don't see this error verbiage in either transcode or server log but they are attached.

ffmpeg-transcode.txt

server log.zip

[ebr 16178]

When you get 3.0.17 try it and see if it makes any difference.  Thanks.

[ebr 16178]

Thanks, happy to help.  Also note the purple rain on the Chrome video that I had running for 4+ hours - the video was still going, audio was fine, but every 3 seconds or so the screen washed out with color.

 

Please put this in the other thread I created for you.  Thanks.

[bardmaster 17]

apologies for that & thanks @@ebr.

 

So I am using the new Roku Beta and so far so good!  I have 3 channels running on 3 separate Roku ethernet devices for an hour without crash or any perceived "loading" messages (though I cannot claim to be staring at any one of them - I'll watch NBA playoffs a bit later which will be more telling).  @@Luke appears to be on to something, kudos!

 

However, I do still get connection timeout errors during the initial buffering phase for a new channel.  When I try the same channel again it works - commonly between 15-20 seconds from selecting the channel.  So I'm wondering if the buffer timeout needs to be extended slightly, or if there is a way to speed up the buffering process somehow?

 

BTW I put the video quality back to AUTO for this testing on all boxes.

Edited April 21, 2017 by bardmaster

[bardmaster 17]

Update:  After 3 hours, two of the three streams are still going strong.  The one that failed did crash with the "video error: an unexpected problem..." error again, I don't know at what time and cannot find this verbiage in any of the logs but I've attached the latest.  But definitely great progress!

ffmpeg-directstream.txt

ffmpeg-transcode.txt

server log.zip

[bardmaster 17]

Posting another instance of the error - it seems to show up sporadically, but definitely less frequently than before.

server log.zip

transcode log.txt

directstream log.txt

[bardmaster 17]

OK @@ebr I finally figured out where you send log in the Roku app - plus it turns out the "Send Log" option does not appear until you close the app and restart it, so I was confused.  When I last used this Roku device I got the "Video error:  An unexpected problem (but not server timeout or HTTP error) has been detected" error, though I'm not certain if the log will show that as debugging was not enabled yet.

 

Roku 2 - 4A653H049552

Roku SG 3.0.17

[ebr 16178]

Yeah, I'll need you to send the log after that error happens but still within the same app session.  Then tell me when you sent it, what you played and the name of your Emby server.  Thanks.

[bardmaster 17]

Just sent another log as the Video Error occurred about 15 minutes in while streaming Live TV (channel 707 ABC HD).  Emby server is Matrix under username Bardmaster.  I do notice my disk I/O usage is often hitting 100% while this transcode is occurring - nothing else significant is running on my server.

 

Roku 2 - 5F461P192081

Roku SG 3.0.18

[ebr 16178]

Okay, thanks.  Unfortunately, all we got was this:

[VideoPlayer] Unrecoverable error - aborting

So, there must be a problem of some sort with the stream.  The question is - is that a problem at the source or being created by some sort of malfunction or over-utilization of the system.

[bardmaster 17]

OK I upgraded my server's OS drive to a SSD - and have not gotten this error anymore, and very few buffer "loading" messages as well.  Looking at the disk I/O it is consistently low now, so it appears like many of my playback issues were related to my transcoding drive hitting max utilization.  However, I did see a marked improvement after your update to throttle the transcode fps for ffmpeg per @@Luke's suggestion, so this was a combination of that improvement and my hardware upgrade.  Thanks to you both!

[ebr 16178]

Thanks for reporting back.  Maybe that other disc is on its last legs...