Lots of buffering and pixelation in Live TV with HDhomerun Extend

[sharrisct25@hotmail.com 2]

So I have been running Emby for years but just recently pushed back into Live TV.  I purchased 2 HDhomerun Extends to do that.  I choose the Extends because I wanted to minimize load on the server. 

 

For understanding 

• My clients are Roku devices of assorted versions, Roku 3, Roku 4, a couple of Roku sticks.  I occasionally use my Android app.  There are 10 devices total but only 2 maybe 3 are running at a time.
• About half of my Roku devices are connected to my 1gig ethernet switch and the other half connected to a wireless network 
• My server is a virtual install of Emby on Windows 10 with 6 cores and 16GB or RAM.  Trans coding goes to local storage which is on a RAID 5 array of SSD drives
• I am Emby premier running version 4.4.2 and the Roku beta app

 

So everything setup super easily and technically works; however the quality and reliability is horrible.  Since I have nothing else hooked up to my new antenna my first thought was that the reception is poor so I downloaded the HDhomerun Roku app and tried that.  To my surprise the HDhomerun app is perfect, no interruptions, great picture quality, fast switching etc.  So I did some testing swapping back and forth between Emby and the HDhomerun app on the same device and the results are consistent, the problem is only in Emby.

 

I have read a number of posts around this and most of the items I have covered.  The problem does look to be I am trans-coding despite having the HDhomerun extend.  That said none of the other posts seem to have a way to keep that from happening.  Is there a setup guide I did not find or something?  Has anyone else conquered this.

 

Thanks

[rbjtech 4929]

Do you have any ffmpeg logs to share ?

 

Assuming the extend is converting to a compatible h264 stream - then the devices should direct play - but the ffmpeg logs should advise why it is transcoding which will give you a clue on why this is happening.

[sharrisct25@hotmail.com 2]

So I looked at the ffmpeg logs.  They are a bit hard to follow but I can see in the first of the log files for a specific Roku that there is a section called Processing Plan.  This says that CanDoInHardware is False for all 4 options.  I am guessing this confirms that Emby thinks it can't do direct plan from the HDhomerun Extend right?  The question is why.

 

Interestingly after reading the logs and trying the same channel on the same Roku I can see it show in the Emby dashboard as Direct play but then I seen the files being created in the transcoding temp directory.  

Edited April 28, 2020 by sharrisct25@hotmail.com

[rbjtech 4929]

Share the logs if you can - but if it direct plays - then you will not get an ffmpeg log at all - thus it is doing something to the stream (be it direct play, direct stream, remux or whatever) if you get an ffmpeg log file.

 

If you search for the stream mapping - then it will tell you what it is having to convert.

 

As an example of a low quality MPEG2 Transport Stream (TS) in the UK - this is what Emby has to do -

 

16:04:29.827 Stream mapping:
16:04:29.827 Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (libx264))
16:04:29.827 Stream #0:1 -> #0:1 (mp2 (native) -> mp3 (libmp3lame))

 

but for native HD 264 streams, only the sound is transcoded.

[sharrisct25@hotmail.com 2]

Ok from my test today there were three log files generated.  Two are named as directstream 1 as transcode.  All from live tv on the same Roku.  The Transcode one is the latest one created.

 

Both directstream ones say

11:57:42.031 Stream mapping:

11:57:42.031   Stream #0:0 -> #0:0 (copy)

11:57:42.031   Stream #0:1 -> #0:1 (copy)

 

The transcode one says

12:05:46.002 Stream mapping:

12:05:46.002   Stream #0:0 (h264) -> scale

12:05:46.002   format -> Stream #0:0 (libx264)

12:05:46.002   Stream #0:1 -> #0:1 (copy)

 

Files are attached.

 

Thank you for your assistance btw.  

ffmpeg-directstream-3c828b76-715a-45b2-a0e6-88129df75c8d_1.txt

ffmpeg-directstream-f0777b66-7875-47c8-94e2-32756e9b5cbb_1.txt

ffmpeg-transcode-6d6723e4-1562-41d1-8361-146280324e91_1.txt

[rbjtech 4929]

ok - so the good news is the directstream logs are just copying the HDHomeRun h264 streams (both video and audio) into a compatible stream for the Roku - they are not transcoding at all - just changing the 'container' as such.  So your HDHomerun's are working just fine.  Unless you can get direct stream working from the App (where the App talks to the HD Homerun directly and bypasses Emby entirely) - this is the best you are going to get and should be perfectly fine.   The transcode log is transcoding obviously, but it's from h264 > h264 and looks as if ffmpeg can't recognise the stream.  

 

So as you say, technically it's fine - and looking at the bitrate for a 720p stream, it should be excellent as it's around 8-10 Mbit/sec - so the question is why it is not ... 

 

Do you have any other clients ?  How does it look in a web browser for example ?  This may be a Roku client issue.

 

You probably need one of the Dev's to take a look at the logs to see if they can spot anything...

Edited April 28, 2020 by rbjtech

[sharrisct25@hotmail.com 2]

Thanks rbjtech.  I will see if I can do some more widespread testing.  This is my only Roku 4 device, maybe other Rokus are working better.  I can also test with my Android device too.

 

Then I will submit something for the dev team.

 

Have a great day!