<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 26, 2022 at 10:47 AM Jan Ceuleers <<a href="mailto:jan.ceuleers@gmail.com">jan.ceuleers@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 26/11/2022 19:26, John P Poet wrote:<br>
> On Sat, Nov 26, 2022 at 10:22 AM Jan Ceuleers <<a href="mailto:jan.ceuleers@gmail.com" target="_blank">jan.ceuleers@gmail.com</a><br>
> <mailto:<a href="mailto:jan.ceuleers@gmail.com" target="_blank">jan.ceuleers@gmail.com</a>>> wrote:<br>
> <br>
>     On 26/11/2022 19:04, John P Poet wrote:<br>
>     > You probably already answered this far above, but is the result of<br>
>     > `curl --silent $URL`<br>
>     > already a transport stream? If so, you could just use that directly:<br>
> <br>
>     There is no URL, because the stream is MPEG TS over UDP. So I can't use<br>
>     curl.<br>
> <br>
> <br>
> Would netcat work?<br>
<br>
I don't know. Do you know what problem we're trying to solve, i.e. what<br>
would give rise to the "TuningSignalCheck: SignalMonitor failed" error<br>
message?<br>
<br>
Is this because the stream doesn't reach myth, is it because there is<br>
some sort of syntax issue with the stream, ... ?<br>
<br>
I'm asking because I suspect that feeding the stream straight into the<br>
backend will lead to problems because the stream contains lots of<br>
zero-length MPEG-TS packets (i.e. 60-byte MPEGTS/UDP packets that<br>
contain no MPEGTS payload), and I believe that ffmpeg filters them out.<br>
<br></blockquote><div><br></div><div>More context in the logs might help. When you run mythbackend add `-v channel, record` to get some more relevant messages. <br></div><div><br></div><div>John<br></div></div></div>