[mythtv] Unknown command: UNKNOWN_COMMAND

[Brian Foddy]

On Mon, 4 Apr 2005, Mark wrote:

> Brian Foddy wrote:
> > I've struggled with this fatal error for almost 2 weeks now, with CVS 
> > snapshots from 3/19, 3/26, and now 4/2.  As far as I can tell, its 
> > caused when the slave backend moves from Recordonly to None, 
> > and its more common when the
> > slave is finishing multiple recordings at the same time.  It appears to send
> > the master a blank command, which the master responds with a UNKNOWN_COMMAND,
> > which the slave doesn't understand so the infinite loop has started.
> > Requiring both backends to be restarted.
> > 
> Since no-one else replied to this I'll share what little I know about it...
> 
> If you look in programs/mythbackend/mainserver.cpp you can uncomment a 
> debug line that will show you all the received commands.
> (Search for the first "cerr" in that file, thats the one)
> You can also use -v network for info.
> I've been looking at mine - I have three backends and when all three are 
> connected the problem appears much more likely to happen.
> I've just started looking at this so the following may be all wrong!
> 
> I altered mine so on receiving an UNKNOWN_COMMAND it does nothing, just 
> returns. Theres no code I could find to deal with it, so theres no point 
> sending it! It helps a little, in that the loop no longer happens, but 
> it still appears to be in a unhappy state (the master backend)
> I usually check this by refreshing the HTML from the 6544 page, if it 
> hangs the backend is in this state.
> 
> I appear to get a QUERY_FREESPACE command being sent from the master and 
> the reply not being liked/accepted, but the reply is 0:0: which I think 
> should be normal?
> 
> But it appears that eventually one of the replies gets intepreted as a 
> command and the backend goes "UNKNOWN_COMMAND: 0" and the fun begins...
> 
> I notice I'm getting loads of these query freespaces on changing channel 
> and I suspect they might be triggered by the reshedule called when the 
> EIT parser gets some new events?
> 
> Are you using DVB?
> 
> In summary, dunno, the rabbithole goes much deeper, but maybe this info 
> will be some help and if I get any further I'll let u know
> 

Thanks, its nice to see others are having the same problems...
I have looked through the code myself and know the cerr you refer to.
>From what I have seen, the first offending bad command is actually a
blank or null message.  The UNKNOWN_COMMAND message starts appearing 
after a few cycles.  I've tried to find a common point in the sending
command logic to trace all sent commands, but it seems like they can
originate from serveral locations in code.  But I'm almost wondering
if the original message is actually a phantom or left-over fragment
that is being taken as a new message.

If someone knows of a central stop to log sending commands, that would
help greatly...

Last night I re-worked my system and switched the slave and master 
roles; changing no tuner cards.  Now my master has 4 cards the slave
only 2.  After a hour of recordings, I only saw a single error
msg in the logs, and it didn't become an infinite loop.  Tonight
will tell more.

I have some DVB air2pc cards and some pvr250's.
Machine A (now master, previous slave):  3 - pvr250's and 1 air2pc.
Runs main frontend, writes to nfs mounted fs on machine B.
Single P3-1400 cpu; 768MB ram.

Machine B (now slave, old master):  2 air2pc cards.  NFS server,
mysql server.
Dual 2.4Ghz Xeons, 1GB ram.

All machines have a gigabit network and cards between them.

Its noteworthy  I think that in my old config, the master had no
tuner cards for source 1 (ntsc).  This may be significant for this
issue and the scheduling bug I also reported.

Thanks,
Brian