[mythtv-users] length mismatch between programinfo

Michael T. Dean mtdean at thirdcontact.com
Mon Jul 5 04:54:35 UTC 2010

  On 07/04/2010 11:01 AM, Curtis Porter wrote:
> On 07/04/2010 06:36 AM, Michael T. Dean wrote:
>>>   I built a debug 0.23-fixes frontend and can see that the message 
>>> is coming from mythtv/libs/libmyth/remoteutil.cpp line 205:
>>>     if (numrecordings * NUMPROGRAMLINES + 1 > (int)strList.size())
>>>     {
>>>         cerr << "length mismatch between programinfo\n";
>>>         return 0;
>>>     }
>>> numrecordings is 51, NUMPROGRAMLINES is 47, and strList.size() is 
>>> 56, so obviously the backend isn't sending over a complete recording 
>>> list.
>> That also means that the frontend is receiving 1 complete record and 
>> one partial record.  The bug in Qt will result in sending some number 
>> of complete records less than the total number of records--but all 
>> records are complete.  Therefore, it seems something else is 
>> happening here.  It sounds more like an issue with socket handling 
>> that causes the connection between the frontend and backend to fail.  
>> I would also guess that the bookmark changes are a placebo, and 
>> that--in fact--just restarting the frontend (and letting it reconnect 
>> to the backend) is what's making a difference.
> This is what's got me so perplexed -- if I take that wrapper script 
> out of place, he consistently can never see recordings.  Additionally, 
> when I debug it from my own frontend, I'm not using the wrapper script 
> and I get the error every time.  If I use mysql to look at the actual 
> data, all the bookmark values are always set to 0, so I don't 
> understand why the wrapper script does anything.
> Aside from the voodoo caused by the database script, a socket handling 
> issue would make sense, although on his combined frontend/backend 
> there are not as many things that can go wrong with socket 
> connections, since they're both on the same machine.  It sounds like 
> my next step should be running a packet sniffer to see what's actually 
> passing between them.

Maybe one or both of your systems is losing its connection to the 
database and "priming" the DB for connections/usage helps it to stay 
alive/active a little longer?


More information about the mythtv-users mailing list