Re: DVB Simulcrypt
On 23-02-15 08:44, Honza Petrouš wrote: Hi Rudy. 2015-02-22 16:28 GMT+01:00 Rudy Zijlstra r...@grumpydevil.homelinux.org mailto:r...@grumpydevil.homelinux.org: Some more info On 21-02-15 22:30, Rudy Zijlstra wrote: Dears (Hans?) My setup, where the cable operator was using only irdeto, was working good. Then the cable operator merged with another, and now the networks are being merged. As a result, the encryption has moved from irdeto only to simulcyrpt with Irdeto and Nagra. Current status: - when i put the CA card in a STB, it works - when trying to record an encrypted channel from PC, it no longer works. Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. Does it mean that descrambling is not working for you? If so, how do you manage descrambling? By CI-CAM module or by some softcam like oscam? Or do you record ENCRYPTED stream and decrypt the recordings later on? Each tuner has its own legal CI-CAM module. And yes, except for the second tuner descrambling no longer works Cheers Rudy /Honza -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB Simulcrypt
On 23-02-15 12:21, Honza Petrouš wrote: 2015-02-23 11:31 GMT+01:00 Rudy Zijlstra r...@grumpydevil.homelinux.org: On 23-02-15 08:44, Honza Petrouš wrote: Hi Rudy. 2015-02-22 16:28 GMT+01:00 Rudy Zijlstra r...@grumpydevil.homelinux.org: Some more info On 21-02-15 22:30, Rudy Zijlstra wrote: Dears (Hans?) My setup, where the cable operator was using only irdeto, was working good. Then the cable operator merged with another, and now the networks are being merged. As a result, the encryption has moved from irdeto only to simulcyrpt with Irdeto and Nagra. Current status: - when i put the CA card in a STB, it works - when trying to record an encrypted channel from PC, it no longer works. Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. Does it mean that descrambling is not working for you? If so, how do you manage descrambling? By CI-CAM module or by some softcam like oscam? Or do you record ENCRYPTED stream and decrypt the recordings later on? Each tuner has its own legal CI-CAM module. And yes, except for the second tuner descrambling no longer works I'm not much familiar with MythTV, so I'm guessing from the mux setup changes, but did you check to descramble the same channel on different tuners? To eliminate the particular change inside one service only. Of course there can be also software issue in CI-CAM module itself (fail in parsing PMT CA descriptors etc). TBH, I think it must be application layer issue, not kernel one. See above: Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. additional finfo: i tested the same channel(s) on all 3 tuners. For now i have re-configured mythtv to use only the second tuner for encrypted channels. This does reduce scheduling flexibility though. Would to understand what makes the difference, so i can ask the right questions to MythTV developers. As the decryption does work with 1 tuner, i see 2 options: - depending on tuner id the default CA descriptor used is different, and this selection is not expoerted on API level (kernel issue) - application needs to select which CA to use (and currently does not do this) Cheers Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB Simulcrypt
On 23-02-15 15:21, Tycho Lürsen wrote: Op 23-02-15 om 13:44 schreef Rudy Zijlstra: On 23-02-15 12:21, Honza Petrouš wrote: 2015-02-23 11:31 GMT+01:00 Rudy Zijlstra r...@grumpydevil.homelinux.org: On 23-02-15 08:44, Honza Petrouš wrote: Hi Rudy. 2015-02-22 16:28 GMT+01:00 Rudy Zijlstra r...@grumpydevil.homelinux.org: Some more info On 21-02-15 22:30, Rudy Zijlstra wrote: Dears (Hans?) My setup, where the cable operator was using only irdeto, was working good. Then the cable operator merged with another, and now the networks are being merged. As a result, the encryption has moved from irdeto only to simulcyrpt with Irdeto and Nagra. Current status: - when i put the CA card in a STB, it works - when trying to record an encrypted channel from PC, it no longer works. Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. Does it mean that descrambling is not working for you? If so, how do you manage descrambling? By CI-CAM module or by some softcam like oscam? Or do you record ENCRYPTED stream and decrypt the recordings later on? Each tuner has its own legal CI-CAM module. And yes, except for the second tuner descrambling no longer works I'm not much familiar with MythTV, so I'm guessing from the mux setup changes, but did you check to descramble the same channel on different tuners? To eliminate the particular change inside one service only. Of course there can be also software issue in CI-CAM module itself (fail in parsing PMT CA descriptors etc). TBH, I think it must be application layer issue, not kernel one. See above: Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. additional finfo: i tested the same channel(s) on all 3 tuners. For now i have re-configured mythtv to use only the second tuner for encrypted channels. This does reduce scheduling flexibility though. Would to understand what makes the difference, so i can ask the right questions to MythTV developers. As the decryption does work with 1 tuner, i see 2 options: - depending on tuner id the default CA descriptor used is different, and this selection is not expoerted on API level (kernel issue) - application needs to select which CA to use (and currently does not do this) It should be the latter one. I'm also having Ziggo for provider, but always used FFdecsawrapper/Oscam for decryption (also legal in The Netherlands, providing you have a paid subscription) ECM CA system id's 0x604 or 0x602 (depending on your region) gets you Irdeto, while ECM CA system id's 0x1850 or 0x1801 get you Nagra. Correctly configured FFdecsa/Oscam can deal with it, MythTV probably cannot. Check it out at: http://www.dtvmonitor.com/nl/?guid=0BE90D25-BA46-7B93-FDCD-20EFC79691E0 That's a snapshot from today, monitored from Groningen. Tycho, thanks. looking at http://www.dtvmonitor.com/nl/ziggo-limburg the CA id for Iredeto are same in Limburg as in Groningen. And yes, my CAM's are for Irdeto and do not support Nagra. To my knowledge no valid Nagra CAM do exist for DVB-C Can FFdecsawrapper/Oscam be used in combination with MythTV? Cheers Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB Simulcrypt
On 23-02-15 20:56, Honza Petrouš wrote: 2015-02-23 16:51 GMT+01:00 Rudy Zijlstra r...@grumpydevil.homelinux.org: And yes, my CAM's are for Irdeto and do not support Nagra. To my knowledge no valid Nagra CAM do exist for DVB-C I'm a bit fossil regarding current status of CA in DVB but anyway I can say I know that some years ago existed CI-CAM modules for Nagra, it was in time of so-called Nagra2 introduction on Hispasat ;) Dunno how is the current situation. An second - it has no difference if it is for sattelite or cable variant of DVB. The CI-CAM standard is the same. The only problem can be if support for particular provider is baked inside (meaning only particular auth data are inserted). The point is that although from standard point of view you are right, no cable operator has ever wanted to support Nagra CAM. As a result the needed CAM authorization is not present. CI+ is a different story. Would need to check if CI+ is available in PC card form now. Kind of doubt that though. Do not expect Nagra wil support such development (refuse to validate). Cheers Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB Simulcrypt
Some more info On 21-02-15 22:30, Rudy Zijlstra wrote: Dears (Hans?) My setup, where the cable operator was using only irdeto, was working good. Then the cable operator merged with another, and now the networks are being merged. As a result, the encryption has moved from irdeto only to simulcyrpt with Irdeto and Nagra. Current status: - when i put the CA card in a STB, it works - when trying to record an encrypted channel from PC, it no longer works. Recording system has 3 tuners. All equal, all with same permissions on the smartcard. On cards 0 and 2 does not work, but card 1 does work, on all channels tested. I suspect the problem is that the wrong keys are used: Nagra keys in stead of Irdeto keys. I do not know whether: - kernel issue (is simulcrypt supported?) - API issue (is all support in place to select the right key stream?) - application issue (does the application allow to set the right CA?) If this is an application issue, could it be solved by setting the API outside the application, to direct it to the right (Irdeto in my case) encryption? The application i am using is MythTV. Cheers Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DVB Simulcrypt
Dears (Hans?) My setup, where the cable operator was using only irdeto, was working good. Then the cable operator merged with another, and now the networks are being merged. As a result, the encryption has moved from irdeto only to simulcyrpt with Irdeto and Nagra. Current status: - when i put the CA card in a STB, it works - when trying to record an encrypted channel from PC, it no longer works. I suspect the problem is that the wrong keys are used: Nagra keys in stead of Irdeto keys. I do not know whether: - kernel issue (is simulcrypt supported?) - API issue (is all support in place to select the right key stream?) - application issue (does the application allow to set the right CA?) If this is an application issue, could it be solved by setting the API outside the application, to direct it to the right (Irdeto in my case) encryption? The application i am using is MythTV. Cheers Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ddbridge -- kernel 3.15.6
On 19-07-14 19:49, Thomas Kaiser wrote: Hello Rudy I use a similar card from Digital Devices with Ubuntu 14.04 and kernel 3.13.0-32-generic. Support for this card was not build into the kernel and I had to compile it myself. I had to use media_build_experimental from Mr. Endriss. http://linuxtv.org/hg/~endriss/media_build_experimental Your card should be supported with this version. Regards, Thomas Hi Thomas, thank you for the information. Is there a preferred kernel for the experimental? Cheers Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ddbridge -- kernel 3.15.6
On 30-07-14 22:52, Antti Palosaari wrote: On 07/30/2014 04:00 PM, Antti Palosaari wrote: On 07/30/2014 08:13 AM, Bjoern wrote: Hello Rudy I use a similar card from Digital Devices with Ubuntu 14.04 and kernel 3.13.0-32-generic. Support for this card was not build into the kernel and I had to compile it myself. I had to use media_build_experimental from Mr. Endriss. http://linuxtv.org/hg/~endriss/media_build_experimental Your card should be supported with this version. Regards, Thomas Hi Rudy, What Thomas writes is absolutely correct... This is unfortunately the worst situation I've ever run across in Linux... There was a kernel driver that worked and was supported by Digital Devices. Then, from what I read, changes to how the V4L drivers have to be written was changed - Digital Devices doesn't like that and they force users to use experimental builds which are the old style. This is total rubbish imo - if this is how it was decided that the drivers have to be nowadays then adjust them. Why am I paying such a lot of money others right, these DD cards are really not cheap? Some attempts have been made by people active here to adapt the drivers and make them work in newer kernels, but so far no one has succeeded. Last attempt was in Jan 2014 iirc, since then - silence. I wish I could help out, I can code but Linux is well just a bit more difficult I guess ;-) I have one of such device too, but I have been too busy all the time with other drivers... Basically these DTV drivers should be developed in a order, bridge driver first, then demod and tuner - for one single device. After it is committed in tree, you could start adding new devices and drivers. If you try implement too big bunch of things as a once, you will likely fail endless reviews and so. I don't know what is change in development process which causes these problems. What I remember there has been only few big changes in recent years, change from Mercurial to Git and reorganization of directories/files. Device I have seems to be: DD Cine S2 V6.5 - Twin Tuner Card DVB-S/S2 (PCI Express Card) DD DuoFlex C/C2/T/T2 Expansion (V3) - Twin Tuner Expansion-modul DVB-C/T/T2 I will start looking DVB-S/S2 support at the very first as it is the bridge needed in any case. I have no experience from PCIe devices... regards Antti When you have patches that can be tested, willing to help test Cannot promise to test immediate though Cheers Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ddbridge -- kernel 3.15.6
Dears, I have a ddbridge device: 03:00.0 Multimedia controller: Device dd01:0003 Subsystem: Device dd01:0021 Flags: fast devsel, IRQ 17 Memory at f090 (64-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 3 Capabilities: [90] Express Endpoint, MSI 00 Capabilities: [100] Vendor Specific Information: ID= Rev=0 Len=00c ? Kernel driver in use: DDBridge The kernel recognises as seen in dmesg: [1.811626] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH [1.813996] pci :01:19.0: enabling device ( - 0002) [1.816033] DDBridge driver detected: Digital Devices PCIe bridge [1.816273] HW 0001000d FW 00010004 But /dev/dvb remains empty, only /dev/ddbridge exists. Any pointers are much appreciated Cheers Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ddbridge -- kernel 3.15.6
Hi Rene, DVB-S2 I would have expected the relevant modules to be loaded after detecting the bridge, and after ddbridge detecting the relevant HW behind. This is apparently not happening, so how to trigger? Cheers Rudy On 18-07-14 16:27, René wrote: Hi Rudy, ddbridge is a ... bridge. So it is an interface between PCIe and a DVB device. So missing info is what frontend and demux (at least) devices type. Is it DVB-C(2)/T(2)/S(2) ? René -- From: Rudy Zijlstra r...@grumpydevil.homelinux.org Sent: Friday, July 18, 2014 3:28 PM To: Linux Media Mailing List linux-media@vger.kernel.org Subject: ddbridge -- kernel 3.15.6 Dears, I have a ddbridge device: 03:00.0 Multimedia controller: Device dd01:0003 Subsystem: Device dd01:0021 Flags: fast devsel, IRQ 17 Memory at f090 (64-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 3 Capabilities: [90] Express Endpoint, MSI 00 Capabilities: [100] Vendor Specific Information: ID= Rev=0 Len=00c ? Kernel driver in use: DDBridge The kernel recognises as seen in dmesg: [1.811626] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH [1.813996] pci :01:19.0: enabling device ( - 0002) [1.816033] DDBridge driver detected: Digital Devices PCIe bridge [1.816273] HW 0001000d FW 00010004 But /dev/dvb remains empty, only /dev/ddbridge exists. Any pointers are much appreciated Cheers Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ddbridge -- kernel 3.15.6
On 18-07-14 17:01, René wrote: To know which modules shall be detected, we need at least the make and model of the device. If you can read the references on the chips on the board, it would be great ... I see. What would happen if I build a monolithic kernel with all DVB modules included? I'll check if i can read the chip references... -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ddbridge -- kernel 3.15.6
On 18-07-14 17:39, Rudy Zijlstra wrote: On 18-07-14 17:01, René wrote: To know which modules shall be detected, we need at least the make and model of the device. If you can read the references on the chips on the board, it would be great ... I see. What would happen if I build a monolithic kernel with all DVB modules included? I'll check if i can read the chip references... It's a Digital Devices Cine S2 If i made no reading mistakes: STV0900B Lattice LFE3 - 17EA The tuners are below soldered shielding with the text Digital Devices Tuner 1 and Digitial Devices Tuner 2. As i am not good in soldering, i prefer not to remove the shielding -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ddbridge -- kernel 3.15.6
On 18-07-14 19:13, René wrote: Had you a look to the linuxtv.org wiki page ? If not read http://linuxtv.org/wiki/index.php/Linux4Media_cineS2_DVB-S2_Twin_Tuner if this correspond to your device you are may be missing the firmware file (bottom of the page) The ngene and the ddbridge are both bridge drivers. Checking the driver source, the ngene driver needs the ngene fw, the ddbridge does not need any firmware. I did find something to check, but i need daylight to do so, as i am checking to get extermal power to the cards. Cheers Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Digital Devices Cine S2 V6.5, PCIe, Dual
Dear List, I have a DVB card as mentioned in the subject 03:00.0 Multimedia controller [0480]: Device [dd01:0003] Subsystem: Device [dd01:0021] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 17 Region 0: Memory at f090 (64-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported+ RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range A, TimeoutDis+ DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+ LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB Capabilities: [100 v1] Vendor Specific Information: ID= Rev=0 Len=00c ? Kernel driver in use: DDBridge Kernel modules: ddbridge Kernel 3.12.3 sees the device, but does not enable it. Only the ddbridge driver is loaded, none of the tuner/demod drivers: root@mythtest:~# lsmod Module Size Used by ddbridge 17766 0 Nor, judging from dmesg output, is the firmware loaded: [1.624996] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH [1.652565] pci :01:19.0: enabling device ( - 0002) [1.677601] DDBridge driver detected: Digital Devices PCIe bridge [1.683598] HW FW [2.160410] Adding 2097148k swap on /dev/sda3. Priority:-1 extents:1 across:2097148k [2.190386] Switched to clocksource tsc What is the best kernel to have this dvb-card working? Or, alternatively, the best combination of kernel version and out-of-kernel stack? Thanks, Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-1600 QAM recordings with slight glitches in them
On 29-04-12 00:21, Brian J. Murrell wrote: On 12-04-28 04:39 PM, Brian J. Murrell wrote: I typically have one more splitter downstream from that 3 way splitter which is a 4 way splitter to feed all of the tuners on my Mythtv box and introducing that splitter reduces the SNR at the HVR-1600 to between 13c and 13e (31.6 - 31.8 dB). Interestingly enough, I moved the Myth backend to it's usual home, in the basement, right next to the incoming cable signal and replaced that 25' run that I had going to where it was temporarily with a smaller, say 10' run (of RG-59 so still room for improvement) and my SNR at the HVR-1600, even after all of the splitters is now 015c or 34.8 dB. I'm still going to go replacing all of that RG-59 with shorter, custom made lengths of RG6 cables. I can't go too short when making those can I or would even a 6-12 inch cable be perfectly fine? I'm thinking of the runs between that last 4 way splitter and the tuners in the Myth backend. b. Brian, There is no minimum cable length for RF. Although for practical reasons i rarely go below 30 cm (1 '). It should be possible for you to buy drop cables which have a length of 1m5 (about 5') and are commonly used in HE to connect equipment. screw-on F-connectors are another source of problems. Crimping F-connectors are best, but those need a fitting crimp tool. Cheers, Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb-core: fix initialization of feeds list in demux filter (Was: Videotext application crashes the kernel due to DVB-demux patch)
Chicken Shack wrote: ok anonymous chicken you've managed a distinct first: i've installed a block filter on your email address. Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: POLL: for/against dropping support for kernels 2.6.22
On Sun, 2009-02-22 at 11:15 +0100, Hans Verkuil wrote: Hi all, There are lot's of discussions, but it can be hard sometimes to actually determine someone's opinion. So here is a quick poll, please reply either to the list or directly to me with your yes/no answer and (optional but welcome) a short explanation to your standpoint. It doesn't matter if you are a user or developer, I'd like to see your opinion regardless. Please DO NOT reply to the replies, I'll summarize the results in a week's time and then we can discuss it further. Should we drop support for kernels 2.6.22 in our v4l-dvb repository? _: Yes YES _: No Optional question: Why: From what i see, i2c is causing trouble, also still in in 2.6.28. I prefer attention on that in stead of trying to get the old i2c working. I've seen a remark seemed to imply that the Mythtv community is using CentOS a lot. In my experience that is a minority in the mythtv group. -- Cheers, Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
recording problems with CAM
Hello, I'm having some issues. Bad recordings, and always accompanied with the following: [10968.525453] saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [10975.963186] saa7146 (2) vpeirq: used 55 times 80% of buffer (163372 bytes now) [10977.657955] saa7146 (1) vpeirq: used 50 times 80% of buffer (65612 bytes now) [11007.664262] saa7146 (1) vpeirq: used 53 times 80% of buffer (61476 bytes now) [11027.255507] mythbackend used greatest stack depth: 4632 bytes left [11031.825410] saa7146 (2) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [11031.856008] saa7146 (2) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [11046.460153] saa7146 (2) vpeirq: used 15 times 80% of buffer (65424 bytes now) [11062.372011] saa7146 (2) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [11062.404008] saa7146 (2) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [11069.971794] saa7146 (2) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [11076.466498] saa7146 (2) vpeirq: used 13 times 80% of buffer (61476 bytes now) [11088.314244] saa7146 (1) vpeirq: used 37 times 80% of buffer (65424 bytes now) [11106.473733] saa7146 (2) vpeirq: used 6 times 80% of buffer (65612 bytes now) [8.320611] saa7146 (1) vpeirq: used 4 times 80% of buffer (61476 bytes now) [11136.480108] saa7146 (2) vpeirq: used 2 times 80% of buffer (65424 bytes now) [11148.327846] saa7146 (1) vpeirq: used 1 times 80% of buffer (65612 bytes now) [11166.486493] saa7146 (2) vpeirq: used 3 times 80% of buffer (61476 bytes now) System info: C2D system, with lspci output as follows: r...@repeater:~# lspci 00:00.0 Host bridge: Intel Corporation E7230/3000/3010 Memory Controller Hub (rev c0) 00:01.0 PCI bridge: Intel Corporation E7230/3000/3010 PCI Express Root Port (rev c0) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 (rev 01) 00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) SATA AHCI Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 PCI bridge: Intel Corporation 80333 Segment-A PCI Express-to-PCI Express Bridge 01:00.2 PCI bridge: Intel Corporation 80333 Segment-B PCI Express-to-PCI Express Bridge 02:0e.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 09:00.0 PCI bridge: Intel Corporation 6702PXH PCI Express-to-PCI Bridge A (rev 09) 09:00.1 PIC: Intel Corporation 6700/6702PXH I/OxAPIC Interrupt Controller A (rev 09) 0a:01.0 SCSI storage controller: Marvell Technology Group Ltd. MV88SX6081 8-port SATA II PCI-X Controller (rev 09) 0d:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) 0e:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 0f:00.0 VGA compatible controller: XGI Technology Inc. (eXtreme Graphics Innovation) Volari Z7/Z9/Z9s 0f:02.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 0f:04.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 0f:06.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Currently thinking to disable USB and see whether that helps (based on assumption i have interupt problems). Any ideas are welcome. Cheers, Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PVR x50 corrupts ATSC 115 streams
It then dawned on my why the 115-only results were so bad. I had left the 4-way splitter output used for the x50s unterminated. Sure enough, if I disconnected the x50s, I reproduced the severe errors. I didn't tear everything back apart to verify it, but I believe the 115s would work fine by themselves if I terminated the cables properly. Have you ever checked signal levels? May sound strange, but too high signal levels also cause this type of problems. So what does all of this indicate? My original hunch was that it's a problem with the x50 hardware or driver (at least in combination with my motherboard). I think I'm back to that conclusion. BTW, in my testing last night, I tried changing the PCI latency timer on the x50 cards. I thought maybe it was holding off access to the 115 cards. Changing that had no effect. David -- Cheers, Rudy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
