[mythtv-users] "There are no shows scheduled for recording." - .25

[Preston Crow]

I had the problem of the upcoming recordings being empty recently.  I'm 
quoting a thread on the topic below, but only for reference, so I'm 
top-posting.  Anyway, I had just upgraded, and had just reconfigured it 
to add a second frontend.  At least in my case, there were no mysql 
issues.  After fighting with it for a while, I finally figured out that 
the problem was that the IP address of the local and master backend 
weren't identical, so the backend didn't think it was the master.

This is a case where mythtv-setup could be improved.  When configuring 
the backends, for the local backend, there should be a choice of 
"master," "slave," or "none."  That choice would control which of the 
other options for the local backend showed up.  So unless you set it to 
"slave," there would be no settings for the local backend (and the 
security PIN would be listed under the master backend settings).

I might not have said all that exactly right, but I hope this helps 
anyone who encounters this problem to find the solution.  I also hope 
that mythtv-setup can be changed to make this mistake harder to make.

On 04/09/12 12:16, R. G. Newbury wrote:
> On 04/06/2012 05:53 PM, Phil Bridges wrote:
>> On Sat, Mar 24, 2012 at 2:16 AM, Phil Bridges<gravityhammer at gmail.com>
>> wrote:
>>>
>>>
>>> I checked the log after restarting mythbackend again (still no shows
>>> scheduled for recording) and I see this:
>>>
>>>
>>> 2012-03-24 02:14:06.132584 E [4502/4532] FreeSpaceUpdater
>>> mythsocket.cpp:534 (readStringList) - MythSocket(9f2f60:46):
>>> readStringList: Error, timed out after 30000 ms.
>>> 2012-03-24 02:14:06.132642 E [4502/4532] FreeSpaceUpdater
>>> mainserver.cpp:5700 (connectionClosed) - Slave backend: backend2 no
>>> longer connected
>>> 2012-03-24 02:14:06.136795 I [4502/4522] Scheduler scheduler.cpp:1997
>>> (HandleReschedule) - Reschedule requested for id 0.
>>> 2012-03-24 02:14:06.137056 E [4502/4538] HttpServer65
>>> mythsocket.cpp:311 (writeStringList) - MythSocket(9f2f60:-1):
>>> writeStringList: Error, called with unconnected socket.
>>> 2012-03-24 02:14:06.137072 E [4502/4538] HttpServer65
>>> mythsocket.cpp:520 (readStringList) - MythSocket(9f2f60:-1):
>>> readStringList: Error, called with unconnected socket.
>>> 2012-03-24 02:14:06.137085 E [4502/4538] HttpServer65
>>> playbacksock.cpp:132 (SendReceiveStringList) -
>>> PlaybackSock::SendReceiveStringList(): No response.
>>> 2012-03-24 02:14:06.137097 E [4502/4538] HttpServer65
>>> playbacksock.cpp:393 (GetEncoderState) - PlaybackSock:
>>> GetEncoderState: QUERY_REMOTEENCODER 8 gave us no response.
>>> 2012-03-24 02:14:06.137330 E [4502/4532] FreeSpaceUpdater
>>> playbacksock.cpp:132 (SendReceiveStringList) -
>>> PlaybackSock::SendReceiveStringList(): No response.
>
> These are not the 'usual' errors when the backend cannot talk to the
> mysqld server, the reference to 'Error, called with unconnected socket'
> sure looks like mysqld is not running, or the myth setup is not properly
> connecting.
>
> These can sometimes be difficult to diagnose.
> There is a longish thread here:
>
> http://www.gossamer-threads.com/lists/mythtv/users/496120?search_string=newbury%20mysql%20error;#496120
>
>
> (And a different 'gotcha' error here: note the last post of the thread
> too for a third way to frix things)
>
> http://www.gossamer-threads.com/lists/mythtv/users/494571
>
> where I set out a step by step diagnosis for correcting the myth <->
> mysql connection.
>
> A first guess however is that mysqld is not creating a mysql.sock socket
> on startup. So it is NOT actually starting. It may appear too, but it is
> not.
>
> You don't state what distro you are using, but in my experience, on
> Fedora 15 and 16, the systemd service files are *extremely* 'sensitive'
> or 'fragile'.
>
> If you are running a distro using systemd, open each of the three
> scripts in /lib/systemd/system/mysqld.service and check that EVERY file
> reference made in those scripts points to a real file. Create as
> necessary. I had trouble with the creation of /run/mysqld a couple of
> times, but then it magically started working (used the right incantation
> or curse, I guess).
>
> ExecStartPre=/usr/libexec/mysqld-prepare-db-dir
> ExecStart=/usr/bin/mysqld_safe --nowatch --basedir=/usr
> ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID
>
> Create as necessary using touch. Chown the ownership of /run/msyqld,
> /var/log/mysqld.log and /var/lib/mysql to mysql:mysql using the -R switch.
>
> Now run each of these three startup scripts from the command line to see
> if they throw any errors. I have found that a reported startup success
> may not actually be a success and I have found that the error is
> sometimes something else entirely.
>
> On my laptop (but not this desktop, nor the mythbox at home) I could
> NEVER get the mysqld-wait-ready script to run properly. It looked like
> that script never received the $MAINPID variable. I commented out that
> line in mysqld.service, and called added '/usr/libexec/mysqld-wait-ready
> $pid' as the last line of /usr/bin/mysqld_safe
> Problem solved. NO idea why that happened/didn't happen. Now the
> mysqld.service startup works correctly.
>
> Once you reliably have a mysql.sock in /var/lib/mysql (or whereever),
> you can go on to do the checklist in the thread noted above.
>
> HTH
>
> Geoff
>
>
>
>
>
> mysqld_safe should run and start mysqld. If you run a 'ps -ae | grep
> mysqld' in a loop with a 'sleep 1' you should see mysqld_safe pop up and
> then mysqld, followed by mysqld_sqafe going away. It sometimes takes a
> while for mysql to start too.