Sure enough, I found 3 entries in the 'recorded' table of my mythconverg database with chanid='4294967295'. They were generated by LiveTV on the new card. The title and program information were empty because I probably did not yet have program listings for the new tuner. So I blew away those three entries from my database and 3 corresponding empty mpeg files and now mvpmc shows my listings again.
Although now I have a new problem. Recordings made on the new digital tuner do not play with sound on the mvpmc (either through MythTV or the filesystem). If I play the recordings on the native myth frontend or my Windows machine, they're fine. So I guess I'll be doing more troubleshooting tonight. On 1/10/07, G C <[EMAIL PROTECTED]> wrote: > I just spent a few minutes comparing the capture log I took against > the source code and the Myth protocol. It looks like it may not be > entirely a mvpmc problem. The Myth backend server appears to be > returning empty fields in this case. The MVPMC issues a > 'QUERY_RECORDINGS' command to get all the programs and their details. > The response from the myth server is documented in the protocol at > http://www.mythtv.org/wiki/index.php/Myth_Protocol_Command_QUERY_RECORDINGS > . In this case, all the fields are empty or some kind of NULL or > garbage value. It chokes on the 'chanid' (Channel ID) which is > returned from the myth server as 4294967295. > > So there are two problems here. > 1.) The myth server is returning no values for one of the entries. > Maybe I'll have to check my database for a corresponding garbage entry > and get rid of it. It may have been created when I was setting up the > new channels on tuner 2 for some reason. > 2.) MVPMC needs to handle situations like this better. Perhaps > ignore things like this? The regular Myth frontend seems to work and > it uses the same mechanism to get its data. So one would have to > assume that its ignoring this entry. > > > On 1/10/07, Ozzy Lash <[EMAIL PROTECTED]> wrote: > > It must not be the file size then, but according to Rick's log, it > > looks like the string "4294967295" is being received, and being passed > > to cmyth_rcv_long. Even though the comments in that function indicate > > that it can handle a 64bit number, the code only handles a 32bit > > signed int. I am wondering if something on the mythtv side is sending > > an unsigned long instead of a long and is trying to send -1. > > > > You could try the attached patch (I did it quick with no testing) and > > see what happens. > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mvpmc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mvpmc-users mvpmc wiki: http://mvpmc.wikispaces.com/
