[mythtv-users] Mythfilldatabase fails to reschedule for id -1

[Chuck Filson]

	I am running Mythtv with Schedules Direct as a program source. Recently I 
noticed that even when the "Listing Status" showed that Mythfilldatabase had 
run successfully and I had 14 days of data available, "Upcoming Recordings" 
showed nothing scheduled for the last day or two of the listings. Also there 
were a few recordings made for programs that I had never selected.

	Since I was running the release version of 0.21, I pulled the latest version 
( 18188 at the time ) from svn fixes, compiled and installed.

chuck at skiffia ~]$ mythbackend --version
Please include all output in bug reports.
MythTV Version   : 18188
MythTV Branch    : branches/release-0-21-fixes
Library API      : 0.21.20080304-1
Network Protocol : 40
Options compiled in:
 linux release using_oss using_alsa using_arts using_jack using_backend 
using_frontend using_hdhomerun using_ivtv using_lirc using_v4l using_x11 
using_xrandr using_xv using_xvmc using_xvmcw using_xvmc_vld 
using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads

	This update has not changed the situation at all.

	I do run optimize_mythdb.pl in a daily cron and as well as 
mythconverg_backup.pl with both showing successful runs.

	To correct the problem temporarily I can run mythbackend -- resched as the 
user that normally runs the backend and the scheduling anomalies disappear 
until after the next automatic mythfilldatabase run. The problems then seem 
to start again with none of the new program data being scheduled.

	It seems tha mythfilldatabase is not able to call the backend to reschedule 
for id -1 and the new program data is never processed. The manual reched 
makes up for this failure.

	I have not been able to find any reference to this error on gossamer and do 
not recall seeing anything similar in the past here.

The error seems to be at the end of the mythfilldatabase run as it tries to 
contact the backend for rescheduling, but I have no idea why this is 
happening now when it was fine for several years before this.

	This id the end of a mythfilldatabase run:

===============================================================
| Attempting to contact the master backend for rescheduling.  |
| If the master is not running, rescheduling will happen when |
| the master backend is restarted.                            |
===============================================================
2008-09-01 09:59:25.821 Connecting to backend server: 192.168.0.5:6543 (try 1 
of 5)
2008-09-01 09:59:25.822 Using protocol version 40
2008-09-01 09:59:32.827 MythSocket(8184ec8:9): readStringList: Error, timeout 
(quick).
2008-09-01 09:59:56.472 MythSocket(8184ec8:-1): writeStringList: Error, called 
with unconnected socket.
2008-09-01 09:59:56.472 MythSocket(8184ec8:-1): readStringList: Error, called 
with unconnected socket.
2008-09-01 09:59:56.472 Connection to backend server lost
2008-09-01 09:59:56.472 Connecting to backend server: 192.168.0.5:6543 (try 1 
of 5)
2008-09-01 09:59:56.473 Using protocol version 40
2008-09-01 09:59:56.492 MythSocket(81e5688:11): writeStringList: Error, 
invalid string list.
2008-09-01 10:00:26.497 MythSocket(81e5688:11): readStringList: Error, 
timeout.
2008-09-01 10:00:26.497 Reconnection to backend server failed
2008-09-01 10:00:26.497 Error rescheduling id -1 in 
ScheduledRecording::signalChange
2008-09-01 10:00:26.497 Connecting to backend server: 192.168.0.5:6543 (try 1 
of 5)
2008-09-01 10:00:26.498 Using protocol version 40
2008-09-01 10:00:26.501 Received a remote 'Clear Cache' request
2008-09-01 10:00:26.547 mythfilldatabase run complete.
2008-09-01 10:00:26.547 DataDirect: Deleting temporary files

	 Both the manual mythfilldatabase runs and those run by the backend result in 
the same errors and the backend log never shows that a reschedule request for 
id -1 ever occurs except when the resched is manually called.

	Has anyone seen this type of behaviour before or have an idea of where the 
problem may be.

Chuck Filson