2008/7/28 Jelle de Jong <[EMAIL PROTECTED]>: > Markus Rechberger wrote: >> >> Hi, >> >> On Sun, Jul 27, 2008 at 10:24 PM, Jelle de Jong >> <[EMAIL PROTECTED]> wrote: >>> >>> Markus Rechberger wrote: >>>> >>>> Hi Jelle, >>>> >>>> On Sun, Jul 27, 2008 at 8:36 PM, Jelle de Jong >>>> <[EMAIL PROTECTED]> wrote: >>>>> >>>>> Hi Markus, >>>>> >>>>> My dvb-t is not picking up any signals anymore, I am standing outside >>>>> at >>>>> a >>>>> place with normally full receptions. It does not work sins the last >>>>> checkout >>>>> that I did last week? >>>>> >>>>> em28xx #0: Found Hauppauge WinTV HVR (B2C0) >>>>> usb 5-3: New USB device found, idVendor=2040, idProduct=6502 >>>>> usb 5-3: New USB device strings: Mfr=0, Product=1, SerialNumber=2 >>>>> usb 5-3: Product: WinTV HVR-900 >>>>> usb 5-3: SerialNumber: 4030600678 >>>>> >>>>> ps my other Terratec Cinergy Hybrid T USB XS is not working with analog >>>>> there is only video without audio and dvb-t is not tested. >>>>> >>>>> Any idea's? >>>>> >>>> how old is the driver which you installed? >>>> Try to upgrade to the latest one! >>>> >>>> Markus >>> >>> point 1: >>> build and install was successful, thanks for the fast fix in the >>> repository! >>> >>> point 2: >>> i always get a non standard LSB Linux kernel module message, when udev >>> is loading all the device kernel modules during boot: >>> em28xx new video device (2040:6502): interface 0, class 255 >>> Is it possible to put this message in the dmesg buffer only, and not >>> include it in the main tty output? This would make my boot process a bit >>> cleaner. >> >> this already comes through "dmesg" the kernel debug output. >> >>> point 3: >>> the Hauppauge WinTV HVR is finding it's dvb-t channels again, this may >>> have been a pebkac, i am not sure, sorry in advance :-p >>> free to air dvb-t audio and video are working sufficient with >>> totem-xine: totem-xine --no-existing-session dvb: >>> >> >> fine. >> >>> point 4: >>> Hauppauge WinTV HVR >>> with your patched tvtime the audio and video are working also sufficient. >>> >>> - rebooting with new device >>> >>> point 5: >>> same messages with point 2 with the new device >>> em28xx new video device (0ccd:0042): interface 0, class 255 >>> >>> em28xx #0: Found Terratec Hybrid XS >>> em28xx audio device (0ccd:0042): interface 1, class 1 >>> em28xx audio device (0ccd:0042): interface 2, class 1 >>> em2880-dvb.c: DVB Init >>> em2880-dvb.c: failed initializing zl10353DVB-T demodulator >>> em2880-dvb.c: retrying with mt352 DVB-Tdemodulator >>> em2880-dvb.c: no luck with mt352demodulator, not attaching em2880-dvb >>> >> >> the device initialization needs to be redone in order to fix that >> correctly. This is something difficult since all devices need to be >> tested again. >> >>> no fronted is created dvb-t not functional yet >>> >>> point 6: >>> Terratec Hybrid XS >>> tvp5150 1-005c: tvp5150am1 detected. >>> with the patched tvtime video is working, but there is no audio >>> >> yes, tvtime is very likely not patched to support that device yet, >> I'll add a patch later for this, unless someone else submits a patch >> for it first. >> >> http://mcentral.de/cgi-bin/mailman/listinfo/em28xx-commits >> >> em28xx-commits is available if you want to get mails when something got >> updated. >> >> thanks for pointing out to those issues, >> Markus > > I created a patch for the output messages that came in my main tty during > boot-up, i tested them with two devices and the boot process is now cleaner, > the messages are now only appearing in the dmesg buffers. I hope you want to > apply the patch?
almost, if you use em28xx_info() I'll apply it :-) actually nothing should directly use printk and only those em28xx_* derived macros. > Is your tvtime patched for all new devices? Isn't there a way to create a > better system? Automatically let tvtime attach to the digital audio socked? > Or a general request for the location of the digital audio stream for the > used device? > this tvtime version was more or less only patched for 1 device, bigger and better detection is planned but I haven't had time to dig on it yet. > How much devices are not working because the initialization needs to be > redone in order to fix the device? If it is a large base then there is not > really an option not to redo the order? > it's not about how many devices aren't working, it's about there's no need to hardcode the setup and definitely not with reverse engineered values. There's one other issue when disconnecting the device with 2.6.21, the remote control deinitialization might hang the PC for some reasons, seems like the linux "work" code is not stable with that version but with later kernel versions. cheers, Markus > Best regards, > > Jelle > > (with sign for the patch) > > _______________________________________________ > Em28xx mailing list > [email protected] > http://mcentral.de/mailman/listinfo/em28xx > > _______________________________________________ Em28xx mailing list [email protected] http://mcentral.de/mailman/listinfo/em28xx
