[mythtv] PARTLY SOLVED Re: length mismatch between programinfo

Brad Templeton brad+mydev at templetons.com
Tue Jan 20 22:16:49 UTC 2009


On Tue, Jan 20, 2009 at 08:23:13AM -0600, Kevin Kuphal wrote:
> On Mon, Jan 19, 2009 at 11:20 PM, Brad Templeton
> <brad+mydev at templetons.com<brad%2Bmydev at templetons.com>
> > wrote:
> 
> > On Mon, Jan 19, 2009 at 08:50:34PM -0800, Brad Templeton wrote:
> > > On Mon, Jan 19, 2009 at 07:18:13PM -0800, Brad DerManouelian wrote:
> > > > On Jan 19, 2009, at 7:14 PM, Brad Templeton wrote:
> > > >
> > > >> On Mon, Jan 19, 2009 at 05:11:10PM -0800, Brad Templeton wrote:
> > > >>> Just compiled to lastest trunk 19741M, but noticing a few issues.
> > > >>> The most serious
> > > >>> is that when the frontend (same machine or different) attempts to
> > > >>> load the recorded
> > > >>> list, it gets an error as follows:
> > > >>>
> > > >>> 2009-01-19 17:02:52.229 Loading window theme from /usr/local/share/
> > > >>> mythtv/themes/default/recordings-ui.xml
> > > >>> length mismatch between programinfo
> > > >>> 2009-01-19 17:02:52.332 SortedList is Empty
> > > >>>
> > > >>
> > > >> I should add that when this diagnostic is printed, numrecordings is
> > > >> 150 (which is correct),
> > > >> NUMPROGRAMLINES is 47, but strList.size() is only 189, not nearly
> > > >> large enough to
> > > >> match the test in remoteutil.cpp that is failing.
> > > >
> > > > I can't reproduce this using 19710. Everything is working as expected.
> > > > My memory limit is also 128M. I've got 924 programs. I start getting
> > > > programs back immediately but it takes a long time for the entire page
> > > > to completely build.
> > >
> > > Well, the numbers indicate that while the query in the backend is
> > returning
> > > all 150 programs, only 4 rows (4*47+1 = 189) are being sent in the
> > protocol.
> > >
> > > I am trying to figure out how to blame this on my own mods to the
> > database,
> > > which add a "suggested" column to the various recording tables, could be
> > causing
> > > this.  I have removed my patches for this test compile, so it must be the
> > extra
> > > column in the database itself.  I thought myth was robust over there
> > being extra
> > > columns in some of the tables to allow code to be tested like this...
> > > (I am loathe to remove my columns quite yet)
> > >
> > > I notice that recordedprogram has only 146 entries while recorded has
> > 150, but
> > > the query is returning the 150 results, it's the converting them to
> > programinfos
> > > and spitting those out that is somehow aborting.
> > > _______________________________________________
> > > mythtv-dev mailing list
> > > mythtv-dev at mythtv.org
> > > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> >
> >
> > Ok, I found that 3 of the programs in my "recorded" database had values of
> > 127 in either
> > the "bookmark" field or the "cutlist" field.   As I recall in earlier
> > versions of
> > the program these fields were global and contained other values.  Possibly
> > something didn't handle that transition right?
> 
> 
> I'm sorry I didn't see these posts earlier.   If you search the archives I
> had the same problem.  Removing the bookmark fixed this issue for me as
> well.

Is there a bug report?  Otherwise others will see this when they upgrade,
and I'll see it again (but know what to do) as there are too many bugs
in trunk right now for me to use it in production and I'm going to
revert.   (At least I hope they are bugs, or did they really mean to
change the UI that much?)  But the killer bug is that instead of being
better at recording from the 1394 streams, it seems worse.  A new kernel
would possibly help, but that's a more one-way change and the new 1394
drivers demand a very recent version, I understand.


More information about the mythtv-dev mailing list