HDHR5-4DT - Google/Android Devices

[GrumpyNick 2]

Hi All,

So I've been moving from Plex to Emby and 95% of this has been plain sailing apart from the Live TV.

Adding my HDHomeRun device was simple and mapping of the channels to the guide data was all fairly simple.

I've an issue though whereby when a Google TV device, Android Phone and Nvidia Shield use the Live TV section.

Some channels will take a minute or two to load and then play whereas others are pretty instant, in the Emby Dashboard the channels that take a while to load have a status of "Recovering from playback error".

When using Emby Theater on my Kubuntu device it's flawless and all channels work as expected.

What logs/info is needed to assist in trying to find where the issue is please as this is the only thing holding me back from binning off Plex as Live TV works as expected on that.

Thanks,

Nick

[Carlo 4535]

Hi,

Here is the information on how to report a media playback issue. 

Thanks!

 

 

[Luke 39395]

@GrumpyNick?

[GrumpyNick 2]

@LukeJust need to gather what is needed.

Should have it later today hopefully.

[GrumpyNick 2]

Okay then here goes!

On Google TV device/Nvidia Shield/Android Phone when I go to watch some channels like "Quest" which is channel 12 on Freeview for me in the Midlands, UK it takes just over a minute to actually show the channel.

During this minute the Emby dashboard shows no activity, then just after a minute I see activity on the dashboard and it has "Recovering from playback error" at the bottom of the "stream" section, screenshot attached.

On all devices I am using the what I believe is classed as the "Universal" Android app so not the dedicated Android TV one.

Emby server is hosted in a Proxmox LXC with Nvidia pass-through working on an Quadro P4000.

Clients and server are on different subnets, everything else Emby works beautifully.

As to add from before I don't get this issue if using Emby Theatre on my Kubuntu device. 

ffmpeg-directstream-5fa8abce-506c-47b9-af19-30b09fdbeb6d_1.txt embyserver.txt

[Carlo 4535]

Hi,

Hi, does this only happen on Quest?

I noticed in the ffmpeg log there is a huge offset between the video and audio channels of 780ms or more than 3/4 of a second. The HLS segment length being used is 3 seconds so the offset itself is roughly 1/4 of the segment.

In your app setting in the subtitle menu, try setting the subtitle mode to "no subtitles" and see if that helps at all.

Try the above and send another set of logs after, if it didn't help.

Carlo

 

[GrumpyNick 2]

Hi @Carlo

Tried with the subtitle mode set to "no subtitles" and the same thing happens so I shall grab additional logging.

Think this happens on other channels but not all, I shall check and if so provide logs for both.

Apologies in the delay responding but the day job has been crazy since coming back from the holidays.

[Luke 39395]

On 12/23/2024 at 5:29 PM, GrumpyNick said:

Okay then here goes!

On Google TV device/Nvidia Shield/Android Phone when I go to watch some channels like "Quest" which is channel 12 on Freeview for me in the Midlands, UK it takes just over a minute to actually show the channel.

During this minute the Emby dashboard shows no activity, then just after a minute I see activity on the dashboard and it has "Recovering from playback error" at the bottom of the "stream" section, screenshot attached.

On all devices I am using the what I believe is classed as the "Universal" Android app so not the dedicated Android TV one.

Emby server is hosted in a Proxmox LXC with Nvidia pass-through working on an Quadro P4000.

Clients and server are on different subnets, everything else Emby works beautifully.

As to add from before I don't get this issue if using Emby Theatre on my Kubuntu device. 

ffmpeg-directstream-5fa8abce-506c-47b9-af19-30b09fdbeb6d_1.txt 18.99 kB · 1 download embyserver.txt 3.08 MB · 1 download

Hi, we’ll take a look at this, thanks.

[Carlo 4535]

@GrumpyNick
Thanks for the update.

[GrumpyNick 2]

Me again, so sorry for the delay.

As before issue persists with Subtitle Mode set to "No Subtitles".

Relevant logs attached.

Also this log snippet from Homerun device, not sure it will help.

20250310-17:19:30 Tuner: tuner0 tuning 12 QUEST (t8dvbt:690MHz-27328)
20250310-17:19:30 Tuner: tuner0 streaming http to 172.22.0.167:57238
20250310-17:21:01 Tuner: tuner0 http stream ended (remote closed)

embyserver.txt ffmpeg-directstream-7279e91b-e733-4136-928a-06d164fa4dd7_1.txt

Edited March 10 by GrumpyNick
Add log snippet

[Carlo 4535]

The ffmpeg log shows a similar issue as it did last time on the Quest channel.

The video start-time is 51,664,504ms
The audio start-time is 51,663,979ms
=> Offset is 525ms
 
How many other TV channels besides Quest does this happen on?
Can you do a playback on a couple other problem channels, to create ffmpeg logs you can upload for us?
 

[emveepee 123]

That delay is pretty normal on DVB-T and DVB-S in the UK That mux has lots of channels https://www.digitalbitrate.com/dtv.php?lang=en&liste=2&live=528

[Carlo 4535]

Delay between the video and audio tracks?

[emveepee 123]

For sure.

[GrumpyNick 2]

I believe other channels do it as well yes, I shall collect some logs.

My existing Plex server has access to the same tuner and the same channels see no such delay hence my raising this one.

If the same delay happened everywhere then fair enough I suppose.

[Carlo 4535]

yes please

 

[GrumpyNick 2]

Here we go, this was for BBC Two, you'll likely see from the logs other channels working as expected.

Always get the same error on the Emby Dashboard with regards to "Recovering from playback error" as well.

Do let me know if you need anything else and thank you for your efforts.

embyserver(1).txt ffmpeg-directstream-4db78e4c-7495-41ee-8679-df853a5a53c1_1.txt

[Carlo 4535]

One interesting thing I noticed is that each ffmpeg file so far shows one or more unknown tracks in the stream.
 

[GrumpyNick 2]

Anything more I can do to look into this please do let me know.

If I'm honest I rarely watch "Live TV" but this is needed for the "WAF" so I can bin of Plex altogether

[Luke 39395]

Hi, we are looking into it. Thanks.

[GrumpyNick 2]

Take all the time you need, I wasn't exactly speedy with the follow up logs.