Mailing List Archive

On Sat, 26 May 2018 18:36:16 +1200, you wrote:

>My mythtv system is having issues. If I try to use it it will play for
>about 30 seconds to a minute then says:
>"Could not connect to master backend MythContext Could not connect to
>the master backend server. Is it running? is the IP Address set for it
>in myth-setup correct?"
>
>Obviously the IP Address is correct or how else does it play 30-60
>seconds of live TV before breaking.
>
>I seem to be able to do this twice before it says all tuners are
>currently busy, and I also can't see any of my recordings.
>
>I'm hoping that if I can see the backend logs it might give me a clue
>as to what is going on. However I can't seem to find out how to view
>them.
>
>A little background:
>This system has been working for years, however around the time of the
>royal wedding we noticed that new recording showed red spinners on
>them and they never stopped (they still have them) Usually they have
>green spinners while recording and then red for a short period after.
>Then this morning my wife noticed edge tv wasn't working (a blank
>screen if you tried to watch it) so she closed mythtv did the ubuntu
>updates (hadn't been done for ages) and restarted the machine. That
>didn't fix the problem so she came to ask me for help. I ran the
>backend setup and tried to do a rescan on the channels but the scan
>didn't work. So I googled it and found out this can happen if the
>backend is still running (the back end setup program should stop it
>but obviously had failed to do so. I stopped the backend from the
>commandline which took ages, and then ran the channel scan which
>worked fine. Now the edge channel was on a different number, it did
>work but only for 30 seconds, then showed the message as per above. So
>I tried other channels and they all have the same problem.
>
>My guess is that the backend is crashing but I need to look at the
>logs to know why, and that does not seem to be documented.
>https://www.mythtv.org/wiki/Logging seems very complicated and doesn't
>actually tell you how to see the logs assuming a default config.

On Ubuntu, the log files are in /var/log/mythtv. The backend log is
"mythbackend.log". You may or may not have enough information in the
log file to work out what the problem is. What version of Ubuntu and
MythTV are you using? In recent versions, you can add extra logging
options to the mythbackend command line by creating a file like this:

root@mypvr:/etc/mythtv# cat additional.args
#ADDITIONAL_ARGS=-v all --loglevel debug
ADDITIONAL_ARGS=-v record,dvbcam

You create a file "additional.args" in the /etc/mythtv directory, and
put in a line which is a Bash variable assignment statement assigning
your extra command line arguments to the variable "ADDITIONAL_ARGS".
The first line in my file (commented out with a # at the start) would
turn on all possible logging. That is enough to slow down the
operation of mythbackend unless you have a fast PC and the log file is
going to a fast SSD. But it will make sure that every possible
message is logged. The second line is the one I run with normally.
The option you probably want is what I use there: "-v record", which
tells mythbackend to log extra messages about how it makes recordings,
including its interaction with the tuners.

When you change the additional.args file, you need to restart
mythbackend to get it to see the new command line arguments:

systemctl restart mythtv-backend

There is also an ability to change the logging at run time. To do
that, you run a second copy of mythbackend with the special command
line options that change the logging. The second copy of mythbackend
finds the first copy and sends the new commands to it, then shuts
down. There are two options you use for this:

--setverbose
--setloglevel

The --setverbose option allows you change the options set for verbose
output, so you would do:

mythbackend --setverbose record

to do the same as the -v record option in the additional.args file. To
turn off the record option, you would do:

mythbackend --setverbose norecord

To change the overall log level, you use:

mythbackend --setloglevel debug

which would set the logging level to "debug". To reduce the logging
again, you would do:

mythbackend --setloglevel info

which turns off the debug level messages, setting the logging level to
"info".

These commands give you the mythbackend command line help:

mythbackend --help
mythbackend -v help

Warning: If you mistype the mythbackend command and it does not have a
valid --setloglevel or --setverbose option, you will get a second copy
of mythbackend trying to run alongside the normal one. That is not
good. So if that happens, do this:

ps -ef | grep mythbackend

to see which is the wrong one, and then kill the wrong one:

kill <PID of wrong mythbackend>

and if that does not work within a few seconds:

kill -9 <PID of wrong mythbackend>

You may need to run some of these commands as root or using sudo
("systemctl" and "kill" will need that).

If you have a log that shows the problems, you can post a copy on
http://pastebin.com for us to look at.

What sort of setup do you have? Is it a combined backend/frontend
box? Is it set up to allow external frontends, or not? What sort of
tuners are you using?

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

In case you are not using any *buntu distro, then you can find the log file
by using the find in the terminal with the below command:

find / -iname '*mythbackend.log*' 2> /dev/null

The 2> /dev/null points stderr to a null file so that it does not clutter
any error output to the terminal.

Stephen has covered a lot of detail to help pinpoint the issue. But pasting
the output for us to check is a good suggestion.

On 26 May 2018 at 23:08, Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

> On Sat, 26 May 2018 18:36:16 +1200, you wrote:
>
> >My mythtv system is having issues. If I try to use it it will play for
> >about 30 seconds to a minute then says:
> >"Could not connect to master backend MythContext Could not connect to
> >the master backend server. Is it running? is the IP Address set for it
> >in myth-setup correct?"
> >
> >Obviously the IP Address is correct or how else does it play 30-60
> >seconds of live TV before breaking.
> >
> >I seem to be able to do this twice before it says all tuners are
> >currently busy, and I also can't see any of my recordings.
> >
> >I'm hoping that if I can see the backend logs it might give me a clue
> >as to what is going on. However I can't seem to find out how to view
> >them.
> >
> >A little background:
> >This system has been working for years, however around the time of the
> >royal wedding we noticed that new recording showed red spinners on
> >them and they never stopped (they still have them) Usually they have
> >green spinners while recording and then red for a short period after.
> >Then this morning my wife noticed edge tv wasn't working (a blank
> >screen if you tried to watch it) so she closed mythtv did the ubuntu
> >updates (hadn't been done for ages) and restarted the machine. That
> >didn't fix the problem so she came to ask me for help. I ran the
> >backend setup and tried to do a rescan on the channels but the scan
> >didn't work. So I googled it and found out this can happen if the
> >backend is still running (the back end setup program should stop it
> >but obviously had failed to do so. I stopped the backend from the
> >commandline which took ages, and then ran the channel scan which
> >worked fine. Now the edge channel was on a different number, it did
> >work but only for 30 seconds, then showed the message as per above. So
> >I tried other channels and they all have the same problem.
> >
> >My guess is that the backend is crashing but I need to look at the
> >logs to know why, and that does not seem to be documented.
> >https://www.mythtv.org/wiki/Logging seems very complicated and doesn't
> >actually tell you how to see the logs assuming a default config.
>
> On Ubuntu, the log files are in /var/log/mythtv. The backend log is
> "mythbackend.log". You may or may not have enough information in the
> log file to work out what the problem is. What version of Ubuntu and
> MythTV are you using? In recent versions, you can add extra logging
> options to the mythbackend command line by creating a file like this:
>
> root@mypvr:/etc/mythtv# cat additional.args
> #ADDITIONAL_ARGS=-v all --loglevel debug
> ADDITIONAL_ARGS=-v record,dvbcam
>
> You create a file "additional.args" in the /etc/mythtv directory, and
> put in a line which is a Bash variable assignment statement assigning
> your extra command line arguments to the variable "ADDITIONAL_ARGS".
> The first line in my file (commented out with a # at the start) would
> turn on all possible logging. That is enough to slow down the
> operation of mythbackend unless you have a fast PC and the log file is
> going to a fast SSD. But it will make sure that every possible
> message is logged. The second line is the one I run with normally.
> The option you probably want is what I use there: "-v record", which
> tells mythbackend to log extra messages about how it makes recordings,
> including its interaction with the tuners.
>
> When you change the additional.args file, you need to restart
> mythbackend to get it to see the new command line arguments:
>
> systemctl restart mythtv-backend
>
> There is also an ability to change the logging at run time. To do
> that, you run a second copy of mythbackend with the special command
> line options that change the logging. The second copy of mythbackend
> finds the first copy and sends the new commands to it, then shuts
> down. There are two options you use for this:
>
> --setverbose
> --setloglevel
>
> The --setverbose option allows you change the options set for verbose
> output, so you would do:
>
> mythbackend --setverbose record
>
> to do the same as the -v record option in the additional.args file. To
> turn off the record option, you would do:
>
> mythbackend --setverbose norecord
>
> To change the overall log level, you use:
>
> mythbackend --setloglevel debug
>
> which would set the logging level to "debug". To reduce the logging
> again, you would do:
>
> mythbackend --setloglevel info
>
> which turns off the debug level messages, setting the logging level to
> "info".
>
> These commands give you the mythbackend command line help:
>
> mythbackend --help
> mythbackend -v help
>
> Warning: If you mistype the mythbackend command and it does not have a
> valid --setloglevel or --setverbose option, you will get a second copy
> of mythbackend trying to run alongside the normal one. That is not
> good. So if that happens, do this:
>
> ps -ef | grep mythbackend
>
> to see which is the wrong one, and then kill the wrong one:
>
> kill <PID of wrong mythbackend>
>
> and if that does not work within a few seconds:
>
> kill -9 <PID of wrong mythbackend>
>
> You may need to run some of these commands as root or using sudo
> ("systemctl" and "kill" will need that).
>
> If you have a log that shows the problems, you can post a copy on
> http://pastebin.com for us to look at.
>
> What sort of setup do you have? Is it a combined backend/frontend
> box? Is it set up to allow external frontends, or not? What sort of
> tuners are you using?
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>

Hey guys, thanks for the replies.

I was to Ubuntu 14.04 Mythtv 0.27. I had left it on that version
because once I had it working I didn't want to risk breaking it.
However seeing as it was already broken, I upgraded the box to 16.04
and Mythtv 0.28, this helped a little (I can now watch live TV) but
can't record. Also there is a delay of 30 seconds to a minute when
trying to watch live TV during which time there is a blank screen.
This also occurs when changing channels. My scheduled recordings list
is now blank. and trying to record results in nothing happening, no
recording, nothing appears in Upcoming recordings etc

I have a turner card from hauppauge with two tuners, I'm not sure the
model but can look it up if someone can tell me the commandline magic
to do so. (this has worked fine the last 3-4 years).

I have a media PC box under my TV which has a backend and front end
mythtv on it. And I also watch over the network from my ubuntu PC
using Kodi media center. Kodi says no response from Mythtv backend if
I try to use it. I checked the IP Address and it's still correct and I
can ping the backend no problem.

I looked at the logs and it seems to be having connection issues
opening the master server socket, the 30 second timeout on
ReadStringList, occured about the same time as I tried to watch a live
TV channel, and might be responsible for the big delay I'm seeing. I
havn't tried changing the logging level yet.

May 27 21:20:53 MediaPC mythbackend: mythbackend[1816]: N CoreContext
mainserver.cpp:7978 (reconnectTimeout) MainServer: Connected
successfully
May 27 21:20:54 MediaPC mythbackend: mythbackend[1816]: N TVRecEvent
recordinginfo.cpp:687 (ApplyRecordRecGroupChange)
ApplyRecordRecGroupChange: LiveTV to LiveTV (2)
May 27 21:20:54 MediaPC mythbackend: mythbackend[1816]: I TVRecEvent
tv_rec.cpp:4247 (TuningNewRecorder) TVRec[3]: TuningNewRecorder -
CreateRecorder()
May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: E
MythSocketThread(-1) mythsocket.cpp:858 (ReadStringListReal)
MythSocket(1252db0:98): ReadStringList: Error, timed out after 30000
ms.
May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: W
MythSocketThread(-1) mainserver.cpp:7680 (connectionClosed)
MainServer: Unknown socket closing MythSocket(0x1252db0)
May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: E CoreContext
mythsocket.cpp:358 (SendReceiveStringList) MythSocket(1252db0:-1): No
response.
May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: E CoreContext
mainserver.cpp:8016 (reconnectTimeout) MainServer: Failed to open
master server socket, timeout
May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: I
MythSocketThread(97) mainserver.cpp:7669 (connectionClosed) Control
sock(1252db0) disconnected
May 27 21:21:24 MediaPC mythbackend: mythbackend[1816]: N CoreContext
mainserver.cpp:7967 (reconnectTimeout) MainServer: Connecting to
master server: 192.168.1.2:6543
May 27 21:21:24 MediaPC mythbackend: mythbackend[1816]: N CoreContext
mainserver.cpp:7978 (reconnectTimeout) MainServer: Connected
successfully


On Sun, May 27, 2018 at 10:53 AM, Karl <skooobie@gmail.com> wrote:
> In case you are not using any *buntu distro, then you can find the log file
> by using the find in the terminal with the below command:
>
> find / -iname '*mythbackend.log*' 2> /dev/null
>
> The 2> /dev/null points stderr to a null file so that it does not clutter
> any error output to the terminal.
>
> Stephen has covered a lot of detail to help pinpoint the issue. But pasting
> the output for us to check is a good suggestion.
>
> On 26 May 2018 at 23:08, Stephen Worthington <stephen_agent@jsw.gen.nz>
> wrote:
>>
>> On Sat, 26 May 2018 18:36:16 +1200, you wrote:
>>
>> >My mythtv system is having issues. If I try to use it it will play for
>> >about 30 seconds to a minute then says:
>> >"Could not connect to master backend MythContext Could not connect to
>> >the master backend server. Is it running? is the IP Address set for it
>> >in myth-setup correct?"
>> >
>> >Obviously the IP Address is correct or how else does it play 30-60
>> >seconds of live TV before breaking.
>> >
>> >I seem to be able to do this twice before it says all tuners are
>> >currently busy, and I also can't see any of my recordings.
>> >
>> >I'm hoping that if I can see the backend logs it might give me a clue
>> >as to what is going on. However I can't seem to find out how to view
>> >them.
>> >
>> >A little background:
>> >This system has been working for years, however around the time of the
>> >royal wedding we noticed that new recording showed red spinners on
>> >them and they never stopped (they still have them) Usually they have
>> >green spinners while recording and then red for a short period after.
>> >Then this morning my wife noticed edge tv wasn't working (a blank
>> >screen if you tried to watch it) so she closed mythtv did the ubuntu
>> >updates (hadn't been done for ages) and restarted the machine. That
>> >didn't fix the problem so she came to ask me for help. I ran the
>> >backend setup and tried to do a rescan on the channels but the scan
>> >didn't work. So I googled it and found out this can happen if the
>> >backend is still running (the back end setup program should stop it
>> >but obviously had failed to do so. I stopped the backend from the
>> >commandline which took ages, and then ran the channel scan which
>> >worked fine. Now the edge channel was on a different number, it did
>> >work but only for 30 seconds, then showed the message as per above. So
>> >I tried other channels and they all have the same problem.
>> >
>> >My guess is that the backend is crashing but I need to look at the
>> >logs to know why, and that does not seem to be documented.
>> >https://www.mythtv.org/wiki/Logging seems very complicated and doesn't
>> >actually tell you how to see the logs assuming a default config.
>>
>> On Ubuntu, the log files are in /var/log/mythtv. The backend log is
>> "mythbackend.log". You may or may not have enough information in the
>> log file to work out what the problem is. What version of Ubuntu and
>> MythTV are you using? In recent versions, you can add extra logging
>> options to the mythbackend command line by creating a file like this:
>>
>> root@mypvr:/etc/mythtv# cat additional.args
>> #ADDITIONAL_ARGS=-v all --loglevel debug
>> ADDITIONAL_ARGS=-v record,dvbcam
>>
>> You create a file "additional.args" in the /etc/mythtv directory, and
>> put in a line which is a Bash variable assignment statement assigning
>> your extra command line arguments to the variable "ADDITIONAL_ARGS".
>> The first line in my file (commented out with a # at the start) would
>> turn on all possible logging. That is enough to slow down the
>> operation of mythbackend unless you have a fast PC and the log file is
>> going to a fast SSD. But it will make sure that every possible
>> message is logged. The second line is the one I run with normally.
>> The option you probably want is what I use there: "-v record", which
>> tells mythbackend to log extra messages about how it makes recordings,
>> including its interaction with the tuners.
>>
>> When you change the additional.args file, you need to restart
>> mythbackend to get it to see the new command line arguments:
>>
>> systemctl restart mythtv-backend
>>
>> There is also an ability to change the logging at run time. To do
>> that, you run a second copy of mythbackend with the special command
>> line options that change the logging. The second copy of mythbackend
>> finds the first copy and sends the new commands to it, then shuts
>> down. There are two options you use for this:
>>
>> --setverbose
>> --setloglevel
>>
>> The --setverbose option allows you change the options set for verbose
>> output, so you would do:
>>
>> mythbackend --setverbose record
>>
>> to do the same as the -v record option in the additional.args file. To
>> turn off the record option, you would do:
>>
>> mythbackend --setverbose norecord
>>
>> To change the overall log level, you use:
>>
>> mythbackend --setloglevel debug
>>
>> which would set the logging level to "debug". To reduce the logging
>> again, you would do:
>>
>> mythbackend --setloglevel info
>>
>> which turns off the debug level messages, setting the logging level to
>> "info".
>>
>> These commands give you the mythbackend command line help:
>>
>> mythbackend --help
>> mythbackend -v help
>>
>> Warning: If you mistype the mythbackend command and it does not have a
>> valid --setloglevel or --setverbose option, you will get a second copy
>> of mythbackend trying to run alongside the normal one. That is not
>> good. So if that happens, do this:
>>
>> ps -ef | grep mythbackend
>>
>> to see which is the wrong one, and then kill the wrong one:
>>
>> kill <PID of wrong mythbackend>
>>
>> and if that does not work within a few seconds:
>>
>> kill -9 <PID of wrong mythbackend>
>>
>> You may need to run some of these commands as root or using sudo
>> ("systemctl" and "kill" will need that).
>>
>> If you have a log that shows the problems, you can post a copy on
>> http://pastebin.com for us to look at.
>>
>> What sort of setup do you have? Is it a combined backend/frontend
>> box? Is it set up to allow external frontends, or not? What sort of
>> tuners are you using?
>>
>> _______________________________________________
>> mythtvnz mailing list
>> mythtvnz@lists.ourshack.com
>> https://lists.ourshack.com/mailman/listinfo/mythtvnz
>> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>
>
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

All the recordings with the red spinners still have the red spinners.
I at the system status page and it is show these recordings (there are
9 of them) in the Job Queue. But it's obviously not making any
progress. What Job would it be trying to do on them? And is there
anyway to clear the queue?

On Sun, May 27, 2018 at 9:38 PM, Daniel Hughes <trampster@gmail.com> wrote:
> Hey guys, thanks for the replies.
>
> I was to Ubuntu 14.04 Mythtv 0.27. I had left it on that version
> because once I had it working I didn't want to risk breaking it.
> However seeing as it was already broken, I upgraded the box to 16.04
> and Mythtv 0.28, this helped a little (I can now watch live TV) but
> can't record. Also there is a delay of 30 seconds to a minute when
> trying to watch live TV during which time there is a blank screen.
> This also occurs when changing channels. My scheduled recordings list
> is now blank. and trying to record results in nothing happening, no
> recording, nothing appears in Upcoming recordings etc
>
> I have a turner card from hauppauge with two tuners, I'm not sure the
> model but can look it up if someone can tell me the commandline magic
> to do so. (this has worked fine the last 3-4 years).
>
> I have a media PC box under my TV which has a backend and front end
> mythtv on it. And I also watch over the network from my ubuntu PC
> using Kodi media center. Kodi says no response from Mythtv backend if
> I try to use it. I checked the IP Address and it's still correct and I
> can ping the backend no problem.
>
> I looked at the logs and it seems to be having connection issues
> opening the master server socket, the 30 second timeout on
> ReadStringList, occured about the same time as I tried to watch a live
> TV channel, and might be responsible for the big delay I'm seeing. I
> havn't tried changing the logging level yet.
>
> May 27 21:20:53 MediaPC mythbackend: mythbackend[1816]: N CoreContext
> mainserver.cpp:7978 (reconnectTimeout) MainServer: Connected
> successfully
> May 27 21:20:54 MediaPC mythbackend: mythbackend[1816]: N TVRecEvent
> recordinginfo.cpp:687 (ApplyRecordRecGroupChange)
> ApplyRecordRecGroupChange: LiveTV to LiveTV (2)
> May 27 21:20:54 MediaPC mythbackend: mythbackend[1816]: I TVRecEvent
> tv_rec.cpp:4247 (TuningNewRecorder) TVRec[3]: TuningNewRecorder -
> CreateRecorder()
> May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: E
> MythSocketThread(-1) mythsocket.cpp:858 (ReadStringListReal)
> MythSocket(1252db0:98): ReadStringList: Error, timed out after 30000
> ms.
> May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: W
> MythSocketThread(-1) mainserver.cpp:7680 (connectionClosed)
> MainServer: Unknown socket closing MythSocket(0x1252db0)
> May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: E CoreContext
> mythsocket.cpp:358 (SendReceiveStringList) MythSocket(1252db0:-1): No
> response.
> May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: E CoreContext
> mainserver.cpp:8016 (reconnectTimeout) MainServer: Failed to open
> master server socket, timeout
> May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: I
> MythSocketThread(97) mainserver.cpp:7669 (connectionClosed) Control
> sock(1252db0) disconnected
> May 27 21:21:24 MediaPC mythbackend: mythbackend[1816]: N CoreContext
> mainserver.cpp:7967 (reconnectTimeout) MainServer: Connecting to
> master server: 192.168.1.2:6543
> May 27 21:21:24 MediaPC mythbackend: mythbackend[1816]: N CoreContext
> mainserver.cpp:7978 (reconnectTimeout) MainServer: Connected
> successfully
>
>
> On Sun, May 27, 2018 at 10:53 AM, Karl <skooobie@gmail.com> wrote:
>> In case you are not using any *buntu distro, then you can find the log file
>> by using the find in the terminal with the below command:
>>
>> find / -iname '*mythbackend.log*' 2> /dev/null
>>
>> The 2> /dev/null points stderr to a null file so that it does not clutter
>> any error output to the terminal.
>>
>> Stephen has covered a lot of detail to help pinpoint the issue. But pasting
>> the output for us to check is a good suggestion.
>>
>> On 26 May 2018 at 23:08, Stephen Worthington <stephen_agent@jsw.gen.nz>
>> wrote:
>>>
>>> On Sat, 26 May 2018 18:36:16 +1200, you wrote:
>>>
>>> >My mythtv system is having issues. If I try to use it it will play for
>>> >about 30 seconds to a minute then says:
>>> >"Could not connect to master backend MythContext Could not connect to
>>> >the master backend server. Is it running? is the IP Address set for it
>>> >in myth-setup correct?"
>>> >
>>> >Obviously the IP Address is correct or how else does it play 30-60
>>> >seconds of live TV before breaking.
>>> >
>>> >I seem to be able to do this twice before it says all tuners are
>>> >currently busy, and I also can't see any of my recordings.
>>> >
>>> >I'm hoping that if I can see the backend logs it might give me a clue
>>> >as to what is going on. However I can't seem to find out how to view
>>> >them.
>>> >
>>> >A little background:
>>> >This system has been working for years, however around the time of the
>>> >royal wedding we noticed that new recording showed red spinners on
>>> >them and they never stopped (they still have them) Usually they have
>>> >green spinners while recording and then red for a short period after.
>>> >Then this morning my wife noticed edge tv wasn't working (a blank
>>> >screen if you tried to watch it) so she closed mythtv did the ubuntu
>>> >updates (hadn't been done for ages) and restarted the machine. That
>>> >didn't fix the problem so she came to ask me for help. I ran the
>>> >backend setup and tried to do a rescan on the channels but the scan
>>> >didn't work. So I googled it and found out this can happen if the
>>> >backend is still running (the back end setup program should stop it
>>> >but obviously had failed to do so. I stopped the backend from the
>>> >commandline which took ages, and then ran the channel scan which
>>> >worked fine. Now the edge channel was on a different number, it did
>>> >work but only for 30 seconds, then showed the message as per above. So
>>> >I tried other channels and they all have the same problem.
>>> >
>>> >My guess is that the backend is crashing but I need to look at the
>>> >logs to know why, and that does not seem to be documented.
>>> >https://www.mythtv.org/wiki/Logging seems very complicated and doesn't
>>> >actually tell you how to see the logs assuming a default config.
>>>
>>> On Ubuntu, the log files are in /var/log/mythtv. The backend log is
>>> "mythbackend.log". You may or may not have enough information in the
>>> log file to work out what the problem is. What version of Ubuntu and
>>> MythTV are you using? In recent versions, you can add extra logging
>>> options to the mythbackend command line by creating a file like this:
>>>
>>> root@mypvr:/etc/mythtv# cat additional.args
>>> #ADDITIONAL_ARGS=-v all --loglevel debug
>>> ADDITIONAL_ARGS=-v record,dvbcam
>>>
>>> You create a file "additional.args" in the /etc/mythtv directory, and
>>> put in a line which is a Bash variable assignment statement assigning
>>> your extra command line arguments to the variable "ADDITIONAL_ARGS".
>>> The first line in my file (commented out with a # at the start) would
>>> turn on all possible logging. That is enough to slow down the
>>> operation of mythbackend unless you have a fast PC and the log file is
>>> going to a fast SSD. But it will make sure that every possible
>>> message is logged. The second line is the one I run with normally.
>>> The option you probably want is what I use there: "-v record", which
>>> tells mythbackend to log extra messages about how it makes recordings,
>>> including its interaction with the tuners.
>>>
>>> When you change the additional.args file, you need to restart
>>> mythbackend to get it to see the new command line arguments:
>>>
>>> systemctl restart mythtv-backend
>>>
>>> There is also an ability to change the logging at run time. To do
>>> that, you run a second copy of mythbackend with the special command
>>> line options that change the logging. The second copy of mythbackend
>>> finds the first copy and sends the new commands to it, then shuts
>>> down. There are two options you use for this:
>>>
>>> --setverbose
>>> --setloglevel
>>>
>>> The --setverbose option allows you change the options set for verbose
>>> output, so you would do:
>>>
>>> mythbackend --setverbose record
>>>
>>> to do the same as the -v record option in the additional.args file. To
>>> turn off the record option, you would do:
>>>
>>> mythbackend --setverbose norecord
>>>
>>> To change the overall log level, you use:
>>>
>>> mythbackend --setloglevel debug
>>>
>>> which would set the logging level to "debug". To reduce the logging
>>> again, you would do:
>>>
>>> mythbackend --setloglevel info
>>>
>>> which turns off the debug level messages, setting the logging level to
>>> "info".
>>>
>>> These commands give you the mythbackend command line help:
>>>
>>> mythbackend --help
>>> mythbackend -v help
>>>
>>> Warning: If you mistype the mythbackend command and it does not have a
>>> valid --setloglevel or --setverbose option, you will get a second copy
>>> of mythbackend trying to run alongside the normal one. That is not
>>> good. So if that happens, do this:
>>>
>>> ps -ef | grep mythbackend
>>>
>>> to see which is the wrong one, and then kill the wrong one:
>>>
>>> kill <PID of wrong mythbackend>
>>>
>>> and if that does not work within a few seconds:
>>>
>>> kill -9 <PID of wrong mythbackend>
>>>
>>> You may need to run some of these commands as root or using sudo
>>> ("systemctl" and "kill" will need that).
>>>
>>> If you have a log that shows the problems, you can post a copy on
>>> http://pastebin.com for us to look at.
>>>
>>> What sort of setup do you have? Is it a combined backend/frontend
>>> box? Is it set up to allow external frontends, or not? What sort of
>>> tuners are you using?
>>>
>>> _______________________________________________
>>> mythtvnz mailing list
>>> mythtvnz@lists.ourshack.com
>>> https://lists.ourshack.com/mailman/listinfo/mythtvnz
>>> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>>
>>
>>
>> _______________________________________________
>> mythtvnz mailing list
>> mythtvnz@lists.ourshack.com
>> https://lists.ourshack.com/mailman/listinfo/mythtvnz
>> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>>

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

Fixed, at least it seems to be working at the moment.

I noticed that /etc/mythtv had a config file in it that still had a
very old IP Address in it (one I have not used for 6 months at least).

MythTv Backend Setup, didn't have any mention of this old address,
does MythTv Backend Setup not change this config file?

Anyway changing the config file to match the current IP Address of the
machine seems to have fixed things. I'm still not sure how it worked
all this time with the wrong IP Address, and why it suddenly stopped
worked maybe someone on this list has some idea.

On Sun, May 27, 2018 at 9:52 PM, Daniel Hughes <trampster@gmail.com> wrote:
> All the recordings with the red spinners still have the red spinners.
> I at the system status page and it is show these recordings (there are
> 9 of them) in the Job Queue. But it's obviously not making any
> progress. What Job would it be trying to do on them? And is there
> anyway to clear the queue?
>
> On Sun, May 27, 2018 at 9:38 PM, Daniel Hughes <trampster@gmail.com> wrote:
>> Hey guys, thanks for the replies.
>>
>> I was to Ubuntu 14.04 Mythtv 0.27. I had left it on that version
>> because once I had it working I didn't want to risk breaking it.
>> However seeing as it was already broken, I upgraded the box to 16.04
>> and Mythtv 0.28, this helped a little (I can now watch live TV) but
>> can't record. Also there is a delay of 30 seconds to a minute when
>> trying to watch live TV during which time there is a blank screen.
>> This also occurs when changing channels. My scheduled recordings list
>> is now blank. and trying to record results in nothing happening, no
>> recording, nothing appears in Upcoming recordings etc
>>
>> I have a turner card from hauppauge with two tuners, I'm not sure the
>> model but can look it up if someone can tell me the commandline magic
>> to do so. (this has worked fine the last 3-4 years).
>>
>> I have a media PC box under my TV which has a backend and front end
>> mythtv on it. And I also watch over the network from my ubuntu PC
>> using Kodi media center. Kodi says no response from Mythtv backend if
>> I try to use it. I checked the IP Address and it's still correct and I
>> can ping the backend no problem.
>>
>> I looked at the logs and it seems to be having connection issues
>> opening the master server socket, the 30 second timeout on
>> ReadStringList, occured about the same time as I tried to watch a live
>> TV channel, and might be responsible for the big delay I'm seeing. I
>> havn't tried changing the logging level yet.
>>
>> May 27 21:20:53 MediaPC mythbackend: mythbackend[1816]: N CoreContext
>> mainserver.cpp:7978 (reconnectTimeout) MainServer: Connected
>> successfully
>> May 27 21:20:54 MediaPC mythbackend: mythbackend[1816]: N TVRecEvent
>> recordinginfo.cpp:687 (ApplyRecordRecGroupChange)
>> ApplyRecordRecGroupChange: LiveTV to LiveTV (2)
>> May 27 21:20:54 MediaPC mythbackend: mythbackend[1816]: I TVRecEvent
>> tv_rec.cpp:4247 (TuningNewRecorder) TVRec[3]: TuningNewRecorder -
>> CreateRecorder()
>> May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: E
>> MythSocketThread(-1) mythsocket.cpp:858 (ReadStringListReal)
>> MythSocket(1252db0:98): ReadStringList: Error, timed out after 30000
>> ms.
>> May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: W
>> MythSocketThread(-1) mainserver.cpp:7680 (connectionClosed)
>> MainServer: Unknown socket closing MythSocket(0x1252db0)
>> May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: E CoreContext
>> mythsocket.cpp:358 (SendReceiveStringList) MythSocket(1252db0:-1): No
>> response.
>> May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: E CoreContext
>> mainserver.cpp:8016 (reconnectTimeout) MainServer: Failed to open
>> master server socket, timeout
>> May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: I
>> MythSocketThread(97) mainserver.cpp:7669 (connectionClosed) Control
>> sock(1252db0) disconnected
>> May 27 21:21:24 MediaPC mythbackend: mythbackend[1816]: N CoreContext
>> mainserver.cpp:7967 (reconnectTimeout) MainServer: Connecting to
>> master server: 192.168.1.2:6543
>> May 27 21:21:24 MediaPC mythbackend: mythbackend[1816]: N CoreContext
>> mainserver.cpp:7978 (reconnectTimeout) MainServer: Connected
>> successfully
>>
>>
>> On Sun, May 27, 2018 at 10:53 AM, Karl <skooobie@gmail.com> wrote:
>>> In case you are not using any *buntu distro, then you can find the log file
>>> by using the find in the terminal with the below command:
>>>
>>> find / -iname '*mythbackend.log*' 2> /dev/null
>>>
>>> The 2> /dev/null points stderr to a null file so that it does not clutter
>>> any error output to the terminal.
>>>
>>> Stephen has covered a lot of detail to help pinpoint the issue. But pasting
>>> the output for us to check is a good suggestion.
>>>
>>> On 26 May 2018 at 23:08, Stephen Worthington <stephen_agent@jsw.gen.nz>
>>> wrote:
>>>>
>>>> On Sat, 26 May 2018 18:36:16 +1200, you wrote:
>>>>
>>>> >My mythtv system is having issues. If I try to use it it will play for
>>>> >about 30 seconds to a minute then says:
>>>> >"Could not connect to master backend MythContext Could not connect to
>>>> >the master backend server. Is it running? is the IP Address set for it
>>>> >in myth-setup correct?"
>>>> >
>>>> >Obviously the IP Address is correct or how else does it play 30-60
>>>> >seconds of live TV before breaking.
>>>> >
>>>> >I seem to be able to do this twice before it says all tuners are
>>>> >currently busy, and I also can't see any of my recordings.
>>>> >
>>>> >I'm hoping that if I can see the backend logs it might give me a clue
>>>> >as to what is going on. However I can't seem to find out how to view
>>>> >them.
>>>> >
>>>> >A little background:
>>>> >This system has been working for years, however around the time of the
>>>> >royal wedding we noticed that new recording showed red spinners on
>>>> >them and they never stopped (they still have them) Usually they have
>>>> >green spinners while recording and then red for a short period after.
>>>> >Then this morning my wife noticed edge tv wasn't working (a blank
>>>> >screen if you tried to watch it) so she closed mythtv did the ubuntu
>>>> >updates (hadn't been done for ages) and restarted the machine. That
>>>> >didn't fix the problem so she came to ask me for help. I ran the
>>>> >backend setup and tried to do a rescan on the channels but the scan
>>>> >didn't work. So I googled it and found out this can happen if the
>>>> >backend is still running (the back end setup program should stop it
>>>> >but obviously had failed to do so. I stopped the backend from the
>>>> >commandline which took ages, and then ran the channel scan which
>>>> >worked fine. Now the edge channel was on a different number, it did
>>>> >work but only for 30 seconds, then showed the message as per above. So
>>>> >I tried other channels and they all have the same problem.
>>>> >
>>>> >My guess is that the backend is crashing but I need to look at the
>>>> >logs to know why, and that does not seem to be documented.
>>>> >https://www.mythtv.org/wiki/Logging seems very complicated and doesn't
>>>> >actually tell you how to see the logs assuming a default config.
>>>>
>>>> On Ubuntu, the log files are in /var/log/mythtv. The backend log is
>>>> "mythbackend.log". You may or may not have enough information in the
>>>> log file to work out what the problem is. What version of Ubuntu and
>>>> MythTV are you using? In recent versions, you can add extra logging
>>>> options to the mythbackend command line by creating a file like this:
>>>>
>>>> root@mypvr:/etc/mythtv# cat additional.args
>>>> #ADDITIONAL_ARGS=-v all --loglevel debug
>>>> ADDITIONAL_ARGS=-v record,dvbcam
>>>>
>>>> You create a file "additional.args" in the /etc/mythtv directory, and
>>>> put in a line which is a Bash variable assignment statement assigning
>>>> your extra command line arguments to the variable "ADDITIONAL_ARGS".
>>>> The first line in my file (commented out with a # at the start) would
>>>> turn on all possible logging. That is enough to slow down the
>>>> operation of mythbackend unless you have a fast PC and the log file is
>>>> going to a fast SSD. But it will make sure that every possible
>>>> message is logged. The second line is the one I run with normally.
>>>> The option you probably want is what I use there: "-v record", which
>>>> tells mythbackend to log extra messages about how it makes recordings,
>>>> including its interaction with the tuners.
>>>>
>>>> When you change the additional.args file, you need to restart
>>>> mythbackend to get it to see the new command line arguments:
>>>>
>>>> systemctl restart mythtv-backend
>>>>
>>>> There is also an ability to change the logging at run time. To do
>>>> that, you run a second copy of mythbackend with the special command
>>>> line options that change the logging. The second copy of mythbackend
>>>> finds the first copy and sends the new commands to it, then shuts
>>>> down. There are two options you use for this:
>>>>
>>>> --setverbose
>>>> --setloglevel
>>>>
>>>> The --setverbose option allows you change the options set for verbose
>>>> output, so you would do:
>>>>
>>>> mythbackend --setverbose record
>>>>
>>>> to do the same as the -v record option in the additional.args file. To
>>>> turn off the record option, you would do:
>>>>
>>>> mythbackend --setverbose norecord
>>>>
>>>> To change the overall log level, you use:
>>>>
>>>> mythbackend --setloglevel debug
>>>>
>>>> which would set the logging level to "debug". To reduce the logging
>>>> again, you would do:
>>>>
>>>> mythbackend --setloglevel info
>>>>
>>>> which turns off the debug level messages, setting the logging level to
>>>> "info".
>>>>
>>>> These commands give you the mythbackend command line help:
>>>>
>>>> mythbackend --help
>>>> mythbackend -v help
>>>>
>>>> Warning: If you mistype the mythbackend command and it does not have a
>>>> valid --setloglevel or --setverbose option, you will get a second copy
>>>> of mythbackend trying to run alongside the normal one. That is not
>>>> good. So if that happens, do this:
>>>>
>>>> ps -ef | grep mythbackend
>>>>
>>>> to see which is the wrong one, and then kill the wrong one:
>>>>
>>>> kill <PID of wrong mythbackend>
>>>>
>>>> and if that does not work within a few seconds:
>>>>
>>>> kill -9 <PID of wrong mythbackend>
>>>>
>>>> You may need to run some of these commands as root or using sudo
>>>> ("systemctl" and "kill" will need that).
>>>>
>>>> If you have a log that shows the problems, you can post a copy on
>>>> http://pastebin.com for us to look at.
>>>>
>>>> What sort of setup do you have? Is it a combined backend/frontend
>>>> box? Is it set up to allow external frontends, or not? What sort of
>>>> tuners are you using?
>>>>
>>>> _______________________________________________
>>>> mythtvnz mailing list
>>>> mythtvnz@lists.ourshack.com
>>>> https://lists.ourshack.com/mailman/listinfo/mythtvnz
>>>> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>>>
>>>
>>>
>>> _______________________________________________
>>> mythtvnz mailing list
>>> mythtvnz@lists.ourshack.com
>>> https://lists.ourshack.com/mailman/listinfo/mythtvnz
>>> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>>>

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Sun, 27 May 2018 21:38:21 +1200, you wrote:

>Hey guys, thanks for the replies.
>
>I was to Ubuntu 14.04 Mythtv 0.27. I had left it on that version
>because once I had it working I didn't want to risk breaking it.
>However seeing as it was already broken, I upgraded the box to 16.04
>and Mythtv 0.28, this helped a little (I can now watch live TV) but
>can't record. Also there is a delay of 30 seconds to a minute when
>trying to watch live TV during which time there is a blank screen.
>This also occurs when changing channels. My scheduled recordings list
>is now blank. and trying to record results in nothing happening, no
>recording, nothing appears in Upcoming recordings etc
>
>I have a turner card from hauppauge with two tuners, I'm not sure the
>model but can look it up if someone can tell me the commandline magic
>to do so. (this has worked fine the last 3-4 years).
>
>I have a media PC box under my TV which has a backend and front end
>mythtv on it. And I also watch over the network from my ubuntu PC
>using Kodi media center. Kodi says no response from Mythtv backend if
>I try to use it. I checked the IP Address and it's still correct and I
>can ping the backend no problem.
>
>I looked at the logs and it seems to be having connection issues
>opening the master server socket, the 30 second timeout on
>ReadStringList, occured about the same time as I tried to watch a live
>TV channel, and might be responsible for the big delay I'm seeing. I
>havn't tried changing the logging level yet.
>
>May 27 21:20:53 MediaPC mythbackend: mythbackend[1816]: N CoreContext
>mainserver.cpp:7978 (reconnectTimeout) MainServer: Connected
>successfully
>May 27 21:20:54 MediaPC mythbackend: mythbackend[1816]: N TVRecEvent
>recordinginfo.cpp:687 (ApplyRecordRecGroupChange)
>ApplyRecordRecGroupChange: LiveTV to LiveTV (2)
>May 27 21:20:54 MediaPC mythbackend: mythbackend[1816]: I TVRecEvent
>tv_rec.cpp:4247 (TuningNewRecorder) TVRec[3]: TuningNewRecorder -
>CreateRecorder()
>May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: E
>MythSocketThread(-1) mythsocket.cpp:858 (ReadStringListReal)
>MythSocket(1252db0:98): ReadStringList: Error, timed out after 30000
>ms.
>May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: W
>MythSocketThread(-1) mainserver.cpp:7680 (connectionClosed)
>MainServer: Unknown socket closing MythSocket(0x1252db0)
>May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: E CoreContext
>mythsocket.cpp:358 (SendReceiveStringList) MythSocket(1252db0:-1): No
>response.
>May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: E CoreContext
>mainserver.cpp:8016 (reconnectTimeout) MainServer: Failed to open
>master server socket, timeout
>May 27 21:21:23 MediaPC mythbackend: mythbackend[1816]: I
>MythSocketThread(97) mainserver.cpp:7669 (connectionClosed) Control
>sock(1252db0) disconnected
>May 27 21:21:24 MediaPC mythbackend: mythbackend[1816]: N CoreContext
>mainserver.cpp:7967 (reconnectTimeout) MainServer: Connecting to
>master server: 192.168.1.2:6543
>May 27 21:21:24 MediaPC mythbackend: mythbackend[1816]: N CoreContext
>mainserver.cpp:7978 (reconnectTimeout) MainServer: Connected
>successfully

Command line magic for seeing what tuners you have:

lspci
lsusb

Some tuners are USB tuners on a PCI or PCIe card, and only show up in
lsusb (eg Hauppauge WinTV Nova-T-500). The rest should show up in
lspci.

Some things to try:

1) Power the PC down and turn it off at the wall. Leave it that way
for at least 30 seconds. This is to make sure all the capacitors have
discharged and all the hardware will be cold booting when you power it
on again. Doing this can clear some very strange conditions, and
usually they do not come back again for a long time. Various bits of
electronics can be subject to "lockup" conditions caused by voltage
spikes or cosmic ray hits or other strange things. So one or more
bits of a buffer or register or RAM location stop working and get
stuck as a 1 or a 0 until the condition can be cleared. PCs that are
on 24/7 like MythTV are often never turned off completely - any time
they are rebooted, it is done with the power never going off. So
something like this can persist across many reboots. I recommend
doing this at least once a year - and that is also a good time to be
thinking about cleaning the PC and oiling the fans at the same time.

2) Does the problem go away if you restart mythbackend?

systemctl restart mythtv-backend

There are various problems that happen due to race conditions at boot
time, and mostly they go away if you restart mythbackend later after
everything else has finished starting up.

Please also post a full log from mythbackend from startup until the
problem appears in the log. There can be things earlier in the log
that you will not be recognising as a problem, but other people will
notice.

When the problem is happening, what do these commands show:

netstat -pan | grep myth
netstat -pan | grep mysql

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Sun, 27 May 2018 23:07:03 +1200, you wrote:

>Fixed, at least it seems to be working at the moment.
>
>I noticed that /etc/mythtv had a config file in it that still had a
>very old IP Address in it (one I have not used for 6 months at least).
>
>MythTv Backend Setup, didn't have any mention of this old address,
>does MythTv Backend Setup not change this config file?
>
>Anyway changing the config file to match the current IP Address of the
>machine seems to have fixed things. I'm still not sure how it worked
>all this time with the wrong IP Address, and why it suddenly stopped
>worked maybe someone on this list has some idea.

I am not sure why that would have cause intermittent problems. I
would have expected it to just not work at all. But remember that
there are other config.xml files, one in each MythTV user home
directory under .mythtv/config.xml. The one in
/home/mythtv/.mythtv/config.xml is the one used by mythbackend when
run in the normal way on Ubuntu. The one in /home/<your user
name>/.mythtv/config.xml is the one used by mythfrontend when run by
that user. Depending on how you have things set up, they may or may
not be links to /etc/mythtv/config.xml. On a combined
frontend/backend box, I normally link them, rather than have separate
files, as that means there is only one copy to edit when you change
things. The IP address in config.xml is the address used to connect
to the database. The IP address for the backend is read from the
database.

If the /home/<user name>/.mythtv/config.xml file is missing, I think
that MythTV programs may try to use /etc/mythtv/config.xml file, but I
am not sure about that.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/