<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace"><span style="font-family:Arial,Helvetica,sans-serif">On Wed, May 22, 2024 at 11:06 AM Paul Gardiner <<a href="mailto:lists@glidos.net">lists@glidos.net</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 22/05/2024 15:29, Stephen Worthington wrote:<br>
> On Wed, 22 May 2024 13:55:30 +0100, you wrote:<br>
> <br>
>> On 20/05/2024 16:35, Paul Gardiner wrote:<br>
>>> On 20/05/2024 15:47, Klaas de Waal wrote:<br>
>>>> Hi Paul,<br>
>>>><br>
>>>> SatIP has been supported in Mythtv already for a long time via IPTV<br>
>>>> with M3U playlists, as you mentioned, but since V32 it is also<br>
>>>> natively supported. This means you can do the channel scanning etc as<br>
>>>> if it is a /dev/dvb/*/* tuner and also EIT does work, if present in<br>
>>>> the signal. Note that EIT does not work with IPTV.<br>
>>>> See the Wiki page <a href="https://www.mythtv.org/wiki/Channel_Scanning" rel="noreferrer" target="_blank">https://www.mythtv.org/wiki/Channel_Scanning</a><br>
>>>> <<a href="https://www.mythtv.org/wiki/Channel_Scanning" rel="noreferrer" target="_blank">https://www.mythtv.org/wiki/Channel_Scanning</a>> and specially paragraph<br>
>>>> <a href="https://www.mythtv.org/wiki/Channel_Scanning#Scanning_with_Sat.3EIP_tuners" rel="noreferrer" target="_blank">https://www.mythtv.org/wiki/Channel_Scanning#Scanning_with_Sat.3EIP_tuners</a> <<a href="https://www.mythtv.org/wiki/Channel_Scanning#Scanning_with_Sat.3EIP_tuners" rel="noreferrer" target="_blank">https://www.mythtv.org/wiki/Channel_Scanning#Scanning_with_Sat.3EIP_tuners</a>><br>
>>>><br>
>>>> Hope this helps,<br>
>>>> Klaas.<br>
>>><br>
>>> Thanks Klaas. That information has saved me a load of unnecessary work -<br>
>>> creating an M3U file I don't need. And the native support makes the use<br>
>>> of minisatip a vastly more attractive solution to my problems.<br>
>><br>
>> Ultimately proved to be a failure. Setting up minisatip proved easy<br>
>> enough, and the MythTV integration is simple to use, but the stream<br>
>> corruption was still apparent. It seems my server is no better at<br>
>> servicing the tuners under the VM Host than under a VM. While using<br>
>> minisatip, I was seeing some drop out both from the USB-based DVB-T2<br>
>> tuner and from the PCI-based DVB-S2 one. Going back to PCI pass-through,<br>
>> I also now see it on both. I guess I noticed it only from one before<br>
>> because of it's intermittent nature. I'm wondering now if my server just<br>
>> isn't fast enough to handle servicing of the tuners in a KVM context:<br>
>> although this server is faster than either of the ones I previously<br>
>> used, it's still 10 year old hardware - a Z77 based motherboard and an<br>
>> i7-3770S.<br>
>><br>
>> So, the tuners are back in one of my old servers now and reception looks<br>
>> to be back to being flawless. An experiment I've only just thought of is<br>
>> to try using the old server as a minisatip server with new one running<br>
>> mythbackend. I wouldn't want to stick with that set up but, if it works,<br>
>> perhaps I can find something small and innocuous to house my tuners and<br>
>> run minisatip (although that's one more thing to administer - not the<br>
>> direction I was wishing to go). That set up working would also be more<br>
>> evidence that a Homerun would work, although using a Homerun means<br>
>> losing my DVB-S2 feed.<br>
>><br>
>> Paul.<br>
> <br>
> When I first started using minsatip, I was running it and MythTV on a<br>
> 2012 Asus M5A97 EVO motherboard with an AMD FX-4100 processor and it<br>
> worked fine.  It is only about 13 months ago I upgraded to a modern<br>
> system.  Minisatip itself has very low resource usage - it was<br>
> designed to be able to be used in embedded systems.<br>
<br>
Yes, it wasn't minisatip I was suspecting as the core of the problem. I <br>
was thinking that the tuner drivers may be failing to react to <br>
interrupts fast enough because of the virtualisation overheads. When you <br>
were running minisatip on that old system, was it running under a VM or <br>
was that old system acting as a host for other software running in VMs <br>
symultaneously with running minisatip?<br>
<br>
> One thing to try would be having the tuners on the new server and the<br>
> MythTV VM running on a different box.  If there are no problems with<br>
> that, then it is likely a problem with the scheduling of the VM.<br>
> Mythbackend only has small buffers for receiving tuner data and<br>
> storing it before it gets to disk.  When there are problems with<br>
> reception, the data is often being lost there, rather than between the<br>
> tuners and mythbackend.  If the VM scheduling is such that there is<br>
> too much delay in getting the data written to disk, that would explain<br>
> what you are seeing.<br>
<br>
Yes, that would explain it too. I hadn't considered that. Certainly <br>
splitting up minisatip and mythbackend, having them running on different <br>
machines should help track down where the problem lies.<br>
<br>
> When you are getting this data loss, does it happen if you are only<br>
> recording from one tuner?  Or does it require multiple tuners in use<br>
> before it happens?  If the latter, how many hard drives are you using<br>
> on the new system to record to, compared with the old system?  Maybe<br>
> the disk heads are thrashing?<br>
<br>
Strangely the drop out seems largely independent of number of <br>
simultaneous recordings. Most of my initial tests were with live TV, <br>
with nothing else recording. More recently, I've tried three concurrent <br>
recordings, and the drop out seemed about the same. I'm using just one <br>
hard drive for recordings. It's the one I've been using for many years - <br>
moving it between servers each time I perform an upgrade.<br>
<br>
> Other people have reported using mythbackend successfully inside a VM<br>
> using VirtualBox and VMware, so it could be a problem with the VM<br>
> software you are using, or its setup.<br>
<br>
It could easily be that. It's my first use of KVM and virt-manager.<br>
<br>
Paul.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:monospace">One thing I know of for using heavy IRQ workloads in a a virtualized environment that is recommended by kernel maintainers is to dedicate a single CPU core for nothing but IRQs and using CPU affinity on all of your guests to not use that core for anything,  There is plenty of documentation out there on it, but I seriously doubt a (4) tuner cards is creating more IRQs than an Infiniband or 25GB ethernet card this type of config is set to fix.  I would imagine it is somewhere else.  Have you checked all of the various knowledge bases, etc for your hardware and make sure there are no kernel quirks that you need to add some obscure PCI setting on the kernel command line?</div></div></div>