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

R. G. Newbury newbury at mandamus.org
Mon Apr 9 16:16:36 UTC 2012

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 

These can sometimes be difficult to diagnose.
There is a longish thread here:


(And a different 'gotcha' error here: note the last post of the thread 
too for a third way to frix things)


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 

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).

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.



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.

More information about the mythtv-users mailing list