[mythtv-users] length mismatch between programinfo

Curtis Porter curtis.porter at gmail.com
Sun Jul 4 15:01:37 UTC 2010


On 07/04/2010 06:36 AM, Michael T. Dean wrote:
> The problem for #7467 is that something (old development MythTV, 
> between the 0.19 and 0.20 releases of MythTV) was setting a value for 
> bookmark that was neither 0 nor 1.  The invalid value works fine with 
> all versions of MythTV, but Qt4 had a bug that causes a failure to 
> read the data from the database.
>
> I just updated the ticket to mention that the Qt bug is fixed in Qt 
> 4.6.3, so using MythTV 0.22+ with Qt 4.6.3 will prevent any issues 
> (caused by this Qt bug) from occurring.

This may well be a different issue, then.  I can see that the database 
has all 0 in the recorded.bookmark field, before and after the script 
runs.  It doesn't make any sense to me why that script has an impact.

>> Obviously that's a hack, but it works to get his recordings loaded.  
>> Unfortunately as soon as a recording ends, the problem recurs, and he 
>> has to exit mythfrontend and run the wrapper script before recordings 
>> show up again.
>
> That would that something is setting a value for bookmark that's not 0 
> and not 1.  No code at all in MythTV does this; therefore, I'm 
> guessing something else is changing your database.  The only code that 
> we know of that ever causes any illegal value to be put into the 
> bookmark field existed for only a 6-month period during development of 
> 0.20-fixes.
>
>> I can reproduce this on my own frontend by port forwarding mysql and 
>> the mythbackend network traffic through ssh.
>
> Are you saying that port forwarding is causing the problem or that 
> you're port forwarding simply to allow testing his frontend with a 
> different database/data?

I'm port forwarding so I can hit his backend with a different (my own) 
frontend.  His machine is a combined frontend/backend.

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

>> A similar issue was reported here:  
>> http://www.gossamer-threads.com/lists/mythtv/dev/366886
>
> That was the issue in #7467.
>
>> Any suggestions on how I can further troubleshoot this?
>
> I'm pretty sure we need to first find what's actually causing the 
> problem as the symptom isn't consistent with those of the bug reported 
> on #7467.  If you can upgrade to Qt 4.6.3, you can know for certain 
> that the problem isn't the Qt bug in #7467.

I'll look into doing that on my laptop.  Based on what you've mentioned 
here, it doesn't sound like the same issue.

> Note that if it is a socket issue, you'll likely see socket errors 
> reported in your frontend and/or backend log files.  Socket issues can 
> occur with a variety of kernel and system configurations (where system 
> includes both system software and hardware).  They are also very 
> difficult to remedy.  :(  (But if you're good at debugging, you may 
> just be able to help us improve our socket code to better handle these 
> currently-not-so-well-handled configurations.)
>
> Mike

I'm not seeing any socket errors in the logs, but I'll take a look at 
what a packet sniffer shows.

Thanks,
Curtis


More information about the mythtv-users mailing list