Choppy image on all type of clients and occasional freezes

[GTsitouridis 2]

Hallo,

I am having a strange issue, which does not seem to be easy to resolve.

I have a raspberry with TVHeadEnd which works perfectly when streaming to VLC.

When I use it with as an m3u tuner in Emby, I get lot of choppiness. Emby server is running an a brand new QNAP (TS-253D) and during live streaming CPU is 4%-10% (HW transcoding), while RAM is at 45%-50%. I have tried it also with xteve with the same result (tvheadned -> xteve -> emby). Occasionally the image freezes completely and I have to stop playback and restart it.

I have had similar issues with xteve and plex, if this is any help and this is the reason why I bought emby in the first place.

Finally there are days during which live TV may perform almost flawlessly. 

[Carlo 4330]

Hi, what's you source that you need to use TVHeadEnd?

What Emby client are you using when you have this issue?

[GTsitouridis 2]

As I said, I am using a raspberry pi with tvheadend. Raspberry offers a special GPIO Hat which is a TV tuner. 

[Carlo 4330]

Hi, you've covered half of the environment.  We still need to know what Emby client you're using, What it shows when playing back in Stats for Nerds to get a feel for where the problem is.

[GTsitouridis 2]

15 hours ago, cayars said:

Hi, you've covered half of the environment.  We still need to know what Emby client you're using, What it shows when playing back in Stats for Nerds to get a feel for where the problem is.

Well the test is run on a Win 10 Pro system. Problem appears on web emby with Edge Cromium and native emby UWA. As fae as statistics goes.... I have got none. What I get is something like in the screenshot.... though some times much heavier. Finally after an unknown amount of time...maybe 5 minutes maybe 3 hours.... the image freezes forever (at east for 1h that I waited for).
 

Edited January 23, 2021 by GTsitouridis

[Carlo 4330]

Click the cog icon and choose Stats for Nerds which will display diagnostic info.

Question, when testing in VLC are you also feeding it the m3u playlist?

[GTsitouridis 2]

17 minutes ago, cayars said:

Click the cog icon and choose Stats for Nerds which will display diagnostic info.

Question, when testing in VLC are you also feeding it the m3u playlist?

Ok I got the stats option..... when it happens again, I shall have a look, cause now it is working fine.....
In the meanwhile.... I set VLC exactly as I would with emby....with opening m3u url.

[Carlo 4330]

"Raspberry offers a special GPIO Hat which is a TV tuner"

Is that an OTA tuner?

If so do you have any signal strength software to check the signal of the broadcast?

Often times you can get pixelation like you see when the signal is week or on the verge which can be weather or environmental related.

[GTsitouridis 2]

1 minute ago, cayars said:

"Raspberry offers a special GPIO Hat which is a TV tuner"

Is that an OTA tuner?

If so do you have any signal strength software to check the signal of the broadcast?

Often times you can get pixelation like you see when the signal is week or on the verge which can be weather or environmental related.

This is OTA, but signal has nothing to do. Signal is coming into house from central antenna. 3 TVs have no problem at all. The same goes for my previous TV solution (TVMosaic).

[Carlo 4330]

All tuners aren't created equal. My LG vs Samsung vs Sharp TV vs HDHomeRuns vs VBox OTA tuners all report slightly different and some pixelate much earlier than others so you can't take this for granted based on what another device shows.  Also you obviously have the signal split and depending on what type of splitter can have very different dB loss per connection.

[GTsitouridis 2]

17 minutes ago, cayars said:

All tuners aren't created equal. My LG vs Samsung vs Sharp TV vs HDHomeRuns vs VBox OTA tuners all report slightly different and some pixelate much earlier than others so you can't take this for granted based on what another device shows.  Also you obviously have the signal split and depending on what type of splitter can have very different dB loss per connection.

This is true.... none the less, the RPi lead was tested with the other devices. For the specific tuner the current signal is around -50dBm (tvheadend reports as much).
But for DVB-T.... how would it be affected sporadically , if the signal is to blamed?

[Carlo 4330]

Now another way to test since it's using m3u files is playback at the same time.

So if Emby is pixilating five up VLC at the same time and see if it does the same as well!

If so the pixelation is being delivered to both VLC and Emby.

Process of elimination to find where the problem is.

[GTsitouridis 2]

6 minutes ago, cayars said:

Now another way to test since it's using m3u files is playback at the same time.

So if Emby is pixilating five up VLC at the same time and see if it does the same as well!

If so the pixelation is being delivered to both VLC and Emby.

Process of elimination to find where the problem is.

Ok.... let me check both in parallel....

[GTsitouridis 2]

45 minutes ago, cayars said:

Now another way to test since it's using m3u files is playback at the same time.

So if Emby is pixilating five up VLC at the same time and see if it does the same as well!

If so the pixelation is being delivered to both VLC and Emby.

Process of elimination to find where the problem is.

Well.... it seems that it is not 100% related. For hours today it was working fine, until 30 minutes ago. Emby web is frozen (I cannot even display stats) while vlc goes on but rather choppy.

[Carlo 4330]

Do you happen to know if it was direct playing ot transcoding in Emby?

The fact it's choppy in VLC tells us a lot.  What's likely happening is pixels/data is missing in the stream but VLC is doing it's best to cope with that.  Emby likely is running this same stream through ffmpeg to transcode which further complicated the issue.  Then the player ultimately gets a stream it just can't cope with because of out of sync and missing data.

It's speculation at this point but typical when this happens.

Couple of things you could try is removing any splitters inline as even the best splitters have a typical 3.5 dB loss on a 3 way splitter to 7 dB loss on more than 3 way splitters.  Remember this is logarithmic so a 3 dB loss is huge and less than 50% of the original signal is let through.  A 6 dB loss and you only have 1/6th of the original signal.

If you have an amp inline you want it within inches of the antenna and not downline where is amplifies noise.

[GTsitouridis 2]

2 minutes ago, cayars said:

Do you happen to know if it was direct playing ot transcoding in Emby?

The fact it's choppy in VLC tells us a lot.  What's likely happening is pixels/data is missing in the stream but VLC is doing it's best to cope with that.  Emby likely is running this same stream through ffmpeg to transcode which further complicated the issue.  Then the player ultimately gets a stream it just can't cope with because of out of sync and missing data.

It's speculation at this point but typical when this happens.

Couple of things you could try is removing any splitters inline as even the best splitters have a typical 3.5 dB loss on a 3 way splitter to 7 dB loss on more than 3 way splitters.  Remember this is logarithmic so a 3 dB loss is huge and less than 50% of the original signal is let through.  A 6 dB loss and you only have 1/6th of the original signal.

If you have an amp inline you want it within inches of the antenna and not downline where is amplifies noise.

Thanks for the info. Emby does transcoding cause it says container is not supported. What I can also do as in term of test would be to place RPi on an antenna main plug, that is not occupied by anything (thus no splitters) and recheck for a few days.

[Carlo 4330]

That should help.  It's amazing how much a few dBs of loss can contribute to a working signal and one that's never 100% reliable!  Same thing with long cable runs which also contribute dB losses.

[GTsitouridis 2]

On 1/24/2021 at 12:32 AM, cayars said:

That should help.  It's amazing how much a few dBs of loss can contribute to a working signal and one that's never 100% reliable!  Same thing with long cable runs which also contribute dB losses.

Well after a few days of testing I found the problem. The signal quality was the issue! But not the antenna signal, rather the wifi one!
It seems like RPi zero may be reporting a good connection over wifi, but it is not. 

The free antenna plug, was next to the wifi router. The antenna signal quality is the same, but the streaming quality has been increased to almost perfect.

I have let emby streaming for 6-7 hours at a time without any glitches and only having dropped 100-150 frames in that time.

My only question is that after 6-7 hours emby web client reverts back to the channel list without any message, is this normal?  

[Carlo 4330]

Glad you got this figured out!

Check you settings "Enable 'Are You Still Watching?" in Playback menu.

6 to 7 hours does seem like a strange time however.

[GTsitouridis 2]

4 hours ago, cayars said:

Glad you got this figured out!

Check you settings "Enable 'Are You Still Watching?" in Playback menu.

6 to 7 hours does seem like a strange time however.

It is not that important, simply I am worried that there may be some other issue as well. I have found the option and give it a try, just to be sure off.

Would you mind having a look at the following as well:

Performance on QNAP : Docker VS qpkg (Transcoding ok) - QNAP - Emby Community