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
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
