[mythtv-users] VU+ HDTV Receiver as IPTV Tuner

Greg Oliver oliver.greg at gmail.com
Fri Oct 4 01:19:36 UTC 2019

On Thu, Oct 3, 2019 at 8:14 PM Stephen Worthington <stephen_agent at jsw.gen.nz>

> On Thu, 3 Oct 2019 16:55:51 +0200, you wrote:
> >On Sun, 18 Aug 2019 8:01 AM, Stephen Worthington wrote:
> >
> >> I presume that the "vuplusip" name is in your /etc/hosts file.
> >
> >vuplusip is just a dummy, but name resolution works.
> >
> >> The error messages all seem to be about losing connection to the
> >> database server, and everything else seems consequential from that. So
> >> I think we need to know a bit more about the MythTV setup. Is this a
> >> new MythTV install? What Linux distro is it? What database are you
> >> using, MySQL or MariaDB? Is MythTV configured to use localhost, or is
> >> it set up to allow external connections and use the Ethernet port's
> >> address? Are there any tuners other than the IPTV ones?
> >
> >My Installation:
> >
> >Mythtv 0.29+fixes on Ubuntu 18.04 (mythbutbu-packages):
> >1 master-backend configured with a HDHR3-4DC DVB-C tunerbox and the
> vu+-IPTV
> >1 combined (slave-)BE/FE configured with two DVB-C pci-tuner-cards (KNC
> >ONE TV Station) + 1 CI-Module (Alphacrypt).
> >1 FE on an Intel NUC
> >
> >MariaDB 10.4.8 in a separate docker container (Ubuntu 18.04).
> >
> >Everything works fine, but when I switch livetv to the vu+-tuner I get
> >this error:
> >
> >Oct  3 15:14:35 homer mythfrontend.real: mythfrontend[19587]: E
> >CoreContext livetvchain.cpp:289 (GetEntryAt) It appears that your
> >backend may be misconfigured.  Check your backend logs to determine
> >whether your inputs, lineups, channels, or storage configuration are
> >reporting errors.  This issue is commonly caused by failing to complete
> >all setup steps properly.  You may wish to review the documentation for
> >mythtv-setup.
> >
> >Then the mariadb crashes:
> >191003 15:14:34 [ERROR] mysqld got signal 11 ;
> I have never had MariaDB crash - that is a pretty drastic problem. It
> is a likely the cause of your problems, as MythTV can not work without
> access to its data from the database, and does many database accesses
> when starting Live TV.  Signal 11 is SIGSEGV - a segmentation error.
> Something in MariaDB is attempting to access memory outside the
> allocated areas.  So this pretty much has to be a MariaDB bug, but
> triggered by whatever MythTV was doing at the time.  Since you are
> running your MariaDB in a container, which is unusual for MythTV
> users, that raises suspicions that there could be a misconfiguration
> of the container that is causing the problem.  Some sort of resource
> starvation comes to mind.  If you want to find out exactly what MythTV
> is doing that triggers the problem, you can turn on debug output of
> all the database SQL requests in mythbackend.  While mythbackend is
> running, this command will tell it to start verbose logging of the
> SQL:
> mythbackend --setverbose database
> and this will turn off that verbose SQL output:
> mythbackend --setverbose nodatabase
> You should run this second copy of mythbackend as the same user that
> the main mythbackend is run from.  In my case (Ubuntu) that is root.
> The second copy of mythbackend just sends the appropriate logging
> command to the main copy and shuts down again.  But if you mistype the
> options on its command line, it will try to run as a daemon like the
> main copy, and you will need to manually kill it.
> There should also be a MariaDB log file that has more information
> about the crash.  You may need to change your MariaDB and/or Docker
> setup to get that.  In Ubuntu 18.04, the MariaDB log files are
> normally found in /var/log/mysql.
> It would also be helpful to increase the logging for mythbackend's
> recording process, so it logs more about how it starts up its tuners:
> mythbackend --setverbose record
> You can set multiple logging options in the same command:
> mythbackend --setverbose database,record
> When testing tuners, it is often better to do that by starting a
> recording, rather than using Live TV.  Live TV is rather more
> complicated than normal recordings.  I usually just set up a manual
> recording (Manage Recordings > Schedule Recordings > Manual Schedule)
> to test a tuner.  Although you can only make a manual recording start
> at 5 minute intervals, you can get the time down to one minute from
> the current time by using the pre-roll setting when you create the
> manual recording.  So if the current time is 15:20 and you want to
> start your test recording at 15:21, you set the start time to be 15:25
> and the duration to 5 minutes.  Then on the next screen you go into
> Schedule Options and set the pre-roll to be 4 minutes ("Start
> recording 4 minutes early").  You can then set the post-roll to "End
> recording 8 minutes early" and get a one minute recording.  Or you can
> just manually stop the recording from Manage Recordings > Upcoming
> Recordings once it has started.

I also find it easier to rely on packet dumps versus MySQL logging.  To
find the query that is causing it, you can run tcpdump on lo (for a
combined backend/database server), or on your ethernet interface is the
database is on another server.

tcpdump -i lo -s0 -nn -w dump.cap port 3306

Once it crashes, the last query will be show (open dump.cap in wireshark)
and you can search for issues with said query afterward.

> >So it seems tuner configuration is broken somehow...
> >
> ><CaptureCard xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >version="1.1" serializerVersion="1.1">
> ><CardId>140</CardId>
> ><VideoDevice>file:///data/mythtv/wz-vuplus/services.m3u</VideoDevice>
> ><AudioDevice/>
> ><VBIDevice/>
> ><CardType>FREEBOX</CardType>
> ><AudioRateLimit>0</AudioRateLimit>
> ><HostName>homer</HostName>
> ><DVBSWFilter>0</DVBSWFilter>
> ><DVBSatType>0</DVBSatType>
> ><DVBWaitForSeqStart>true</DVBWaitForSeqStart>
> ><SkipBTAudio>false</SkipBTAudio>
> ><DVBOnDemand>false</DVBOnDemand>
> ><DVBDiSEqCType>0</DVBDiSEqCType>
> ><FirewireSpeed>0</FirewireSpeed>
> ><FirewireModel/>
> ><FirewireConnection>0</FirewireConnection>
> ><SignalTimeout>1000</SignalTimeout>
> ><ChannelTimeout>30000</ChannelTimeout>
> ><DVBTuningDelay>0</DVBTuningDelay>
> ><Contrast>0</Contrast>
> ><Brightness>0</Brightness>
> ><Colour>0</Colour>
> ><Hue>0</Hue>
> ><DiSEqCId>0</DiSEqCId>
> ><DVBEITScan>true</DVBEITScan>
> ></CaptureCard>
> >
> ><VideoSource xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >version="1.0" serializerVersion="1.1">
> ><Id>110</Id>
> ><SourceName>wz-vuplus</SourceName>
> ><Grabber>/bin/true</Grabber>
> ><UserId/>
> ><FreqTable>default</FreqTable>
> ><LineupId/>
> ><Password/>
> ><UseEIT>false</UseEIT>
> ><ConfigPath/>
> ><NITId>0</NITId>
> ></VideoSource>
> >
> >/data/mythtv/wz-vuplus# cat services.m3u
> >#EXTM3U
> >
> >#EXTINF:0,40 - 13th Street
> >#EXTVLCOPT:program=1042
> >http://wz-vuplus.home.giaco.de:8001/1:0:1:412:4:85:FFFF0000:0:0:0:
> >#EXTINF:0,3 - 3sat HD
> >#EXTVLCOPT:program=41101
> >http://wz-vuplus.home.giaco.de:8001/1:0:19:A08D:19B:270F:FFFF0000:0:0:0:
> >#EXTINF:0,70 - Al Jazeera International
> >#EXTVLCOPT:program=20112
> >http://wz-vuplus.home.giaco.de:8001/1:0:1:4E90:10F:270F:FFFF0000:0:0:0:
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20191003/a62b003b/attachment.htm>

More information about the mythtv-users mailing list