Tvheadend

I believe there is some issue regarding IPTV threads.
If I set IPTV threads to 2 -> issue occurs after 10-15 mins of streaming.
If I set IPTV threads to 4 -> this issue occurs after 30-40 mins of streaming.

What's in Tvheadend logs?

Thanks for the reply. I enabled debug/trace in all subsystems from the UI, but unfortunately could not see any further error-like logs when the issue happens. If there is any other way to debug this, or any patch I could apply to view further debug info please let me now.

You won't see more error messages, only additional debug output. Probably iptv would be the right subsystem to trace here.

I checked the logs again with iptv as debug/trace subsystem, but I could not find any errors/warnings the issue occured. The only thing I see is the bandwidth becoming zero in the Status > Subscriptions page when the streaming freezes.

One thing that puzzles me is that the problem goes away if I just add a pipe with ffmpeg in the mux as stated in the description. This is something I would reather avoid due to the delay incurred, but why do you think this is extra pipe is a workaround to the issue ?

Look at the traffic in Wireshark then. Your description sounds like the source is just stopping to send traffic.

No clue why using a pipe works as I don't know why the direct retrieval does not work.

Thanks. Will look into it and report back again

Just set up tshark (wireshark cli) to check the traffic between src and dst hosts.

src: streaming server using Jalle19/node-ffmpeg-mpegts-proxy to send the stream using a ffmpeg pipe (wireguard peer)
dst: TVH server connecting to streaming server using IPTV network (wireguard "server")

The streaming froze in the TVH client after 10 minutes of streaming.
At that time, both src and dst wg interfaces still kept sending traffic for like 1 more minute until the ffmpeg pipe closed.

I think that there is no problem with the src, and it is just some issue in the TVH server host causing the ffmpeg pipe to close.
It is unknown why adding an extra ffmpeg pipe at TVH side makes the problem go away (stream can keep going for hours with this extra pipe)

I am using a Raspberry Pi 4 with 2GB RAM as the TVH server, running 32 bit Raspbian.
Will try with a different hardware as the TVH host to check if the problem persists.

After further testing, I am experiencing the following:

In TVH, if the URL of the mux is set to:
- the IP of the wireguard (streaming) peer, the freezing issue happens after 10 - 15mins.
- the same IP as the TVH host, but then I redirect with nginx to the wireguard (streaming) peer, the issue no longer happens.

Can there be any issues when using an external IP (different network) in the mux, after streaming for X minutes ?

No, for me it is working even with external IP addresses.