"Brian J. Murrell" <brian@xxxxxxxxxxxxxxx> wrote: >Hi, > >As I wrote about a number (3-4) of weeks ago, I am still having a >problem with my HVR-1600 failing on multiple digital recordings. At >the >time I reported this previously, there was a question of whether my >current version of MythTV was to blame. > >To that end, I updated my MythTV to the latest (at the time) on the >0.25-fixes branch. I also, at the same time, switched my primary >digital tuner to my HVR-950Q. I ran in that configuration for a couple >of weeks without a single failed recording. > >A week ago, I switched back to having my HVR-1600 as the primary device >to determine if it was the HVR-950Q switch or the MythTV update that >gave me such success and sure enough, on a particularly busy evening of >recording (but no busier than the same evening the prior two weeks >where >the HVR-950Q worked flawlessly) one recording on a given multiplex >failed while another on the same multiplex, at the same time, was >successful. > >Unsurprisingly "femon" reported "FE_HAS_LOCK" for the entire time >period >of the failed recording. I say unsurprisingly because as I mentioned >prior, another recording on the HVR-1600 at the same time was >successful. > >Additionally, many, many times during the last week more than one >recording on a given multiplex on this HVR-1600 worked so this problem >is most definitely intermittent, but my experience for the last 3-4 >weeks I think proves that it's a problem with the HVR-1600 and not >MythTV given that it's something that happens only with the HVR-1600 >and >not with the HVR-950Q. > >Unfortunately, there was nothing on the kernel log at the time of the >failed recording. > >How can I gather further information on what might be going on which is >causing this failure? > >b. # /sbin/modinfo cx18 Look at the flags for the debug module option. You probably want to log info, warning, mailbox/api, and i2c at first. If that doesn't show you anything, log dma, irq, and high volume. You'll get very heavy log activity, but you'll be able to see if buffers are going back and forth. Really I'm not sure why you could record one channel from mux (e.g. 7.1) and not another (e.g. 7.2). The ATSC or QAM data is just that: a mux of all the programs on that frequency. The cx18 driver just passes the data over to the DVB subsystem for processing/demuxing. Maybe the cx18 driver initializes something wrong initializing dvb in cx18-dvb. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
