[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