Issues with playback from HDMI modulator via HDHOMERUN Duo

[kaledi 41]

I've got a HDHOMERUN duo set up with freeview (here in the UK) channels available in Emby.  I can connect directly to HDhomerun server, or via TVHEADEND and the channels all work as expected and recordings too. 

I've added a HDMI modulator to have a HDMI source converted to DVB-T so it can be watched around the house.  If I view this channel on a TV using the inbuilt DVB tuner, it works perfectly.  However, if I watch it via Emby then it is more problematic.  When viewed on a TV via a Shield TV with either the shield app or android app, the video stutters, and it can even be a problem to lock onto the channel.  On mobile devices it is better.  I'll post log files for watching via Shield TV in a moment.

Configuration:

HDMI modulator>HDhomerun duo> Emby and also tried HDMI modulator>HDhomerun duo>TVheadend>emby

[kaledi 41]

OK, strangely, a EMby server reboot improved things.  At least the channel played correct.  Lipsync was way out, at least on the shield TV app.  I've uploaded the log file.

Also played on a laptop.  I notice in stats for nerds it shows video 'recovering from error' incompatible container, or some such wording

I've replaced the log file.  NOw playing on Shield TV and every 30 sec or so, the video stops fora moment or two and then returns.  Lipsync is completely out.  I'll add another log playing from mobile device

 

 

 

embyserver2.txt

Edited February 23, 2025 by kaledi

[kaledi 41]

Updated log file

embyserver.txt

[Carlo 4560]

Hi, the logs are full of lines like these:

2025-02-23 13:30:45.656 Debug GraphRunner:    5198838: Apply expected delta 3281 instead original:539788 - Factor: 164 PcrPid: 2001
2025-02-23 13:30:45.799 Debug GraphRunner:    5200017: Apply expected delta 3281 instead original:539788 - Factor: 164 PcrPid: 2001
2025-02-23 13:30:45.947 Debug GraphRunner:    5201263: Apply expected delta 3281 instead original:539788 - Factor: 164 PcrPid: 2001
2025-02-23 13:30:46.249 Debug GraphRunner:    5203482: Apply expected delta 3281 instead original:539788 - Factor: 164 PcrPid: 2001

These messages are timing related to discrepancies in expected and actual delta values during stream processing.

1. Expected Delta: This is the value FFmpeg expects as a change in timestamps or packet sizes.
2. Original: This represents the actual delta value that the stream is reporting.
3. Factor: This could refer to a scaling factor that FFmpeg is trying to apply when processing timestamps or packet sizes.
4. PcrPid: This is indicating the PID (Packet Identifier) used for the Program Clock Reference in the MPEG-TS stream, which is crucial for synchronizing audio and video.

Typical Causes

• Corrupted Stream: The input file may be corrupted or poorly encoded, leading to timing issues.
• Incorrect Input Format: FFmpeg might be expecting a different format or structure in the input file.
• Mismatched Timing: The timestamps may not align properly, possibly due to incorrect handling of the stream.
• Container Issues: There might be problems with the container format, especially if the stream has been edited or muxed improperly.

This clearly tells us there are timing issues with the stream and it's out of spec.
This could be as simple as a configuration that needs adjusting but is likely an incompatibility of the hardware device doing the modulation.

RF Modulators are no where near as common as they used to be in the Analog TV days.  Most devices of this type these days take the HDMI input and return it via USB or more likely to a IP stream compressed using AVC or HEVC.

What kind of configuration options does the device have?

 

[kaledi 41]

I guessed these HDMI modulator wouldn't be perfect.  There isn't a lot you can change on them in terms of settings.  As you say they encode an AVC into an RF stream to the Dvb-t standard.  However, they encoding would suggest that either they are not quite to Dvb-t spec, or FFMPEG isn't configured optimally?

I've actually acquired another device (Edison HDMI modulator) and this seems to behave much better.  Things trip up occassionally and require a reboot along the chain, but it appears to be much more stable to view.  Recordings don't appear to produce truly compliant streams (what ever I mean by that), but there are a few workarounds I'm working on.  For these, my use case is rather specific and only want to be able to record for time shifting so I can view something when I'm travelling.

[Carlo 4560]

Just curious, but how come you didn't go with a HDMI to IP solution vs modulation to RF?

[kaledi 41]

That's a good question.  Hadn't really given much consideration for a HDMI to IP product.  I'm curious now.  Do you have any specific products in mind?

[Carlo 4560]

There are quite a few devices like this.
I've had good luck with URayCoder 4K HDMI Video Streaming Encoder https://www.amazon.com/URayCoder-Encoder-Encoders-Broadcast-Facebook/dp/B0C5CM33VV?utm_source=chatgpt.com&th=1  This is a single HDMI input model with 4 output streams that can be set to different codecs and bitrates.

They have 2 & 4 input models for 4K encoding up to $499. They also have 1080p models up to 8 inputs $759

You can find no-name Chinese versions of similar units for 1/3 to 1/2 the cost as well. As long as you purchase from a site that allows 30 days no question refunds you could give one of these units a shot.