Patrick Boettcher wrote: >> Hi Andy, >> >> On Thu, 20 Oct 2005, Andy Clark wrote: >> > > >>>> I'm experiencing a problem with a newly-bought Nebula uDigiTV USB2 box. >> >> >> >> > > >>>> Oct 19 23:48:52 vim kernel: >>> 02 7f 01 00 00 00 00 >>>> Oct 19 23:48:52 vim kernel: <<< 02 7f 01 8a 00 00 00 >>>> Oct 19 23:48:52 vim kernel: >>> 02 73 01 00 00 00 00 >>>> Oct 19 23:48:52 vim kernel: <<< 02 73 01 8a 00 00 00 >> >> >> >> >> Here we have it: When trying to identify the mt352 (0x7f) it gets 0x8a >> (whereas 0x13 is expected). Same for nxt6000: 0x0b expected, 0x8a >> delivered. >> >> So either you have a new very new device with an unkown demod inside, >> or your box is broken :) . Does it work in windows? >> > > I've not yet tested it in Windows, but I will do so this evening. The box is actually a uDigiTV, rather than a master, and it occurs to me that this might be the cause of the problem. However, from what I read about the two types of decoder, it was my understanding that the main difference was that the master device comes with an IR interface and with Windows software for recording, whereas the slave doesn't. Officially, the slave box can only be used if there is a master unit also connected, but again I'm hoping that's only a restriction when using the Windows software. I believe the main reason for the restriction is to cover the cost of the Windows software development, by forcing people to buy at least one unit at a premium (to cover that cost). Selling "slave" units allows people to record from more than one mux at the same time without having to buy the Windows software twice. Is is possible that one USB device with frontend hardware could be used to tune another unit also connected over USB but without a frontend? Actually, it occurs to me that I may not be able to test the box in Windows this evening specifically because I don't have a master USB device. However, I do have a Nebula DigiTV PCI card, so I'll see if having that present will allow the Windows software to access the USB box. If I have to then I'll open up the casing on the box and see if there's any indication as to the frontend on the board (if any). :) >> Where is the "Unable to handle kernel paging request" from your subject? >> > > I was initially trying to get the module working with kernel 2.6.13.4, with the dvb-kernel CVS source applied, but loading dvb_usb_digitv was causing a kernel oops. However, I only started having kernel issues with 2.6.13.4 after I applied the code from CVS. With unmodified kernel source there were no errors, but the box didn't work (basically what I'm seeing now, IIRC). I started reporting the kernel oops, but ended up doing most of my testing with kernel 2.6.13 and dvb-kernel from CVS. When I finally sent the email it still had the subject for the old error. Apologies for the confusion. I've just noticed that I also misspelled "usb" in "dvb_udb_digitv" in the subject... In my defence I did send the message fairly late last night. :) Cheers, Andy.
