[mythtv-users] VU+ HDTV Receiver as IPTV Tuner
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
> >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: 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
> >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
> 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">
> ><VideoSource xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >version="1.0" serializerVersion="1.1">
> >/data/mythtv/wz-vuplus# cat services.m3u
> >#EXTINF:0,40 - 13th Street
> >#EXTINF:0,3 - 3sat HD
> >#EXTINF:0,70 - Al Jazeera International
> mythtv-users mailing list
> mythtv-users at mythtv.org
> MythTV Forums: https://forum.mythtv.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-users