[linux-dvb] Re: V4 API proposal
This autodetection is technically impossible. a) Not all hardware has the ability to provide a raw transport stream b) If it had the capability, you would lose data between the time the kernel creates the device and the user scans for directory entries. Think of tables which are broadcasted at very low rates. Besides that, I think you proposal is weird and I don't like it. :-) If it is impossilble, how does this STB hardware scan channels to search for stations? Does the user need to supply all freqency/ polarization/symbolrate parameters and pids for each channel he wants to see? See above. Additionaly this would require the kernel to a) know what types of pids do exist (audio (how about ac3 - non-ac3), video, teletext, different kind of sections) b) identify them As above, I think it is weird and I don't like it. Yes either the userspace decoder daemon should know about all types of PIDs, or in case of hardware acceleration, kernel has to know about PIDs, cooperate with hardware and steer the hardware demux properly. Rarely broadcast tables have to be cached and channels added when the daemon first sees them. Then it will write configuration file so next time it can come up quickly. This approach can be wierd, but it's novel and up-to-date with latest kernel technology. we have computers to do all the boring hex data housekeeping and autodetection for us. It's also resource hungry but will provide the maximum user luxury. One will be able to simple tune and immediately see autodetected receptions, record many channels simultaneously, and have features yet unseen in single view STB's. Imagine having STB capable to display multiple PIDs from a tuned frequency in a mosaic all in one screen and then choose which one you want to view full screen. Make STB technically years ahead of competition, set a bit higher price and win all of the customers. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: V4 API proposal
[EMAIL PROTECTED] writes: This autodetection is technically impossible. a) Not all hardware has the ability to provide a raw transport stream b) If it had the capability, you would lose data between the time the kernel creates the device and the user scans for directory entries. Think of tables which are broadcasted at very low rates. Besides that, I think you proposal is weird and I don't like it. :-) I can only support this statement. If it is impossilble, how does this STB hardware scan channels to search for stations? Does the user need to supply all freqency/ polarization/symbolrate parameters and pids for each channel he wants to see? No the OEM provides the tables. Have you ever used a digital receiver. Most of them come with preprogrammed transponder and channel lists. Which are sometimes updated by a channel search by the user or a firmware update by the OEM. See above. Additionaly this would require the kernel to a) know what types of pids do exist (audio (how about ac3 - non-ac3), video, teletext, different kind of sections) b) identify them As above, I think it is weird and I don't like it. It may also cause security and stability problems. Yes either the userspace decoder daemon should know about all types of PIDs, or in case of hardware acceleration, kernel has to know about PIDs, cooperate with hardware and steer the hardware demux properly. The kernel should not care about the pids. The user space program sets the demux filters and scans for new channels if needed. It's not the job of the kernel to do that. Rarely broadcast tables have to be cached and channels added when the daemon first sees them. Then it will write configuration file so next time it can come up quickly. You don't write configuration files from kernel space. Otherwise exactly this is done by user space programs. This approach can be wierd, but it's novel and up-to-date with latest kernel technology. What kernel have you been looking at? A PID is not a device like a USB device or a PCMCIA card. we have computers to do all the boring hex data housekeeping and autodetection for us. The user uses user space programs that are written by people who know what they are doing and not the kernel directly. It's also resource hungry but will provide the maximum user luxury. One will be able to simple tune and immediately see autodetected receptions, record many channels simultaneously, and have features yet unseen in single view STB's. Imagine having STB capable to display multiple PIDs from a tuned frequency in a mosaic all in one screen and then choose which one you want to view full screen. Make STB technically years ahead of competition, set a bit higher price and win all of the customers. For a mosaic you need several MPEG decoders. You either need special hardware for that or very fast/ several CPUs. I don't know what you are dreaming about. STBs are usually just normal CPUs (arm, mips, i386, ppc) with some receiver hardware and maybe an MPEG decoder. The only thing that is different from a PC is the box size, they can't use extra PCI cards, the amount of memory, hard disk space and they may not have quite the fastest CPU possible for a desktop (between 10% and 100%). The latter is compensated by special hardware which makes them even faster for their specialized task than a PC. Marcus -- /\ | Dr. Marcus O.C. Metzler| | ||---| | [EMAIL PROTECTED]| http://www.metzlerbros.de/| \/ -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Pipe?
Hi list,
I need use pipe to analyze consecutive pid of ts. With this code:
if(pid=fork()0) perror(\nfork error\n);
else if (pid0)
{//parent
close(fd[0]);
//tuning operation and get fd_dvr handle
close(fd[1]);
if (waitpid(pid,NULL,0)0) perror(waitpid error);
exit(0);
}
else if (pid==0)
{//child
close(fd[1]);
close(fd[0]);
exit(0);
}
_
Vinci la nuova Nissan Micra con MSN Messenger! http://www.msn.it/messenger/
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as
subject.
[linux-dvb] REPIPE
ReHI list, excuse for mistake!! So, I use a fork (such as you seen previously) to get ts from a pipe. But there is something wrong because that code run twice !!! Someone could help me? Code or something else? Tks. _ Vinci la nuova Nissan Micra con MSN Messenger! http://www.msn.it/messenger/ -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] A/V sync problems with new drivers
Hi DVB driver developers, this is a repost of a message that I send a week ago, but got no answers. I send it yesterday to the VDR list and received a couple of answers. Seems I'm not the only one with the following problem and it is not limited to DVB-T cards - also -C and -S are affected. With the new drivers 1.0.0-rc1 and -rc2 I experience desync of a/v in VDR after viewing a recording (also on other occasions; viewing a recording is just an easy way to reproduce. Sometimes it needs just a short disturbance in the receiption to get out of sync.). This does not happen with a driver from CVS as of 13. January. This is very reproducable. It affects all programs on the same frequency (I use DVB-T) but vanishes, if I switch to a channel on another frequency. This happens also, if I use the old firmware (from the 13-01 driver) with the new driver, so it seems to be not a problem of the new firmware. Cheers, Juri -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: A/V sync problems with new drivers
Juri Haberland wrote: Hi DVB driver developers, this is a repost of a message that I send a week ago, but got no answers. I send it yesterday to the VDR list and received a couple of answers. Seems I'm not the only one with the following problem and it is not limited to DVB-T cards - also -C and -S are affected. With the new drivers 1.0.0-rc1 and -rc2 I experience desync of a/v in VDR after viewing a recording (also on other occasions; viewing a recording is just an easy way to reproduce. Sometimes it needs just a short disturbance in the receiption to get out of sync.). This does not happen with a driver from CVS as of 13. January. This is very reproducable. It affects all programs on the same frequency (I use DVB-T) but vanishes, if I switch to a channel on another frequency. This happens also, if I use the old firmware (from the 13-01 driver) with the new driver, so it seems to be not a problem of the new firmware. I also noticed a/v sync problems once or twice but I cannot reproduce it. On http://www.linuxdvb.tv/download/ there are daily snapshots of the driver. Could you please try to find out the *precise* date when this bug was introduced? If you could report this date I will check what has been changed... Oliver -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: V4 API proposal
a) Not all hardware has the ability to provide a raw transport stream If it is impossilble, how does this STB hardware scan channels to search for stations? You only need to look at the info PIDs (PAT SDT NIT, starts with well known fixed PIDs) to get all the channels and other transponders, so no need to ever look at the whole TS. -- [EMAIL PROTECTED] -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: V4 API proposal
No the OEM provides the tables. Have you ever used a digital receiver. Most of them come with preprogrammed transponder and channel I Never got any STB receiver really. lists. Which are sometimes updated by a channel search by the user or a firmware update by the OEM. I see. It may also cause security and stability problems. Security maybe. Stability stands on a clean design and using already debugged building blocks instead of reimplemetation of the whell ... The kernel should not care about the pids. The user space program sets the demux filters and scans for new channels if needed. It's not the job of the kernel to do that. Yes and no. For software only demux no. For hardware accelerated chips yes, kernel must do it. Take your av7110 for example. Channel scan has to be supported by the firmware, am I right? You don't write configuration files from kernel space. Otherwise exactly this is done by user space programs. Configuration file is written by userspace daemon. For hardware acclerated bypass, it has to provide vendor specific ioctl that can allow dumping something to file from kernel space... sorry if I was rushing and not elaborating every signle detail. I know what I want as final functionality and try to map it in some simple way. What kernel have you been looking at? A PID is not a device like a USB device or a PCMCIA card. Why not let it be like a USB video camera device with sound, Recordable with streamer, instead of using some cumbersome hardware specific applications like VDR. The user uses user space programs that are written by people who know what they are doing and not the kernel directly. Right. But let the user choose among many simpler programs written by various people instead to force them to use only one program written by someone who knows all the knowledge. Unix philosophy is to use lots of simple elementary tools with data throughput overhead, and not to bundle everything in one efficent huge monolythic program full of bugs noone is willing to fix. For a mosaic you need several MPEG decoders. You either need special hardware for that or very fast/ several CPUs. I don't know what you are Very fast CPU will do. dreaming about. STBs are usually just normal CPUs (arm, mips, i386, ppc) It's the future. With current low performance cpus I don't expect anything better than they already do Emard -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: WinTV-Nova-CI and remote control
Holger Waechtler wrote:
michal wrote:
Sorry, my fault. Modules evdev and input were not loaded.
But another problems still remain:
1) Each key can be pressed only once. There is no reaction on further
keypress...
Here you have to play and improve either the msp430_ir_debounce() and
msp430_ir_interrupt() functions or (if the repeat events don't arrive
there) somebody has to write a new IR protocol parser for the msp430.
There was missing add_timer(dev-timer) at the end of
msp430_ir_interrupt() function. Now everything works fine.
static
void msp430_ir_interrupt (unsigned long data)
{
...
/* initialize debounce and repeat */
dev-repeat_key = code;
/* Zenith remote _always_ sends 2 sequences */
dev-rep[0] = ~0;
/* 350 milliseconds */
dev-timer.expires = jiffies + HZ * 350 / 1000;
/* MAKE */
input_event(dev, EV_KEY, key_map[code], !0);
-- add_timer(dev-timer); --
}
}
Michal
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as
subject.
[linux-dvb] Re: WinTV-Nova-CI and remote control
i'd already found that, see Re:
TT budget / NOVA IR support.
:{)}
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] CRC32 errors in sections
Hi, In a quest to determine why the ARM is crashing during a section filter activity, I discovered I am getting several CRC32 checksum errors on sections, and thus they aren't being used, creating the appearance of a XRUN. To combat this, I added DMX_CHECK_CRC to the section filter flags, but still continued to see the checksum errors. What might be the cause of data corruption? When the driver gives you a section, does it at least sanity check the seclen to determine if it will make a memory out of bounds problem so it won't happily overwrite other memory? _J -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: A/V sync problems with new drivers
Oliver Endriss wrote: I also noticed a/v sync problems once or twice but I cannot reproduce it. On http://www.linuxdvb.tv/download/ there are daily snapshots of the driver. Could you please try to find out the *precise* date when this bug was introduced? If you could report this date I will check what has been changed... Phew, this will take some time, especially as the weekend has come, which means that the machine is in production. Cheers, Juri -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: WinTV-Nova-CI and remote control
michal wrote:
Holger Waechtler wrote:
michal wrote:
Sorry, my fault. Modules evdev and input were not loaded.
But another problems still remain:
1) Each key can be pressed only once. There is no reaction on further
keypress...
Here you have to play and improve either the msp430_ir_debounce() and
msp430_ir_interrupt() functions or (if the repeat events don't arrive
there) somebody has to write a new IR protocol parser for the msp430.
There was missing add_timer(dev-timer) at the end of
msp430_ir_interrupt() function. Now everything works fine.
static
void msp430_ir_interrupt (unsigned long data)
{
...
/* initialize debounce and repeat */
dev-repeat_key = code;
/* Zenith remote _always_ sends 2 sequences */
dev-rep[0] = ~0;
/* 350 milliseconds */
dev-timer.expires = jiffies + HZ * 350 / 1000;
/* MAKE */
input_event(dev, EV_KEY, key_map[code], !0);
-- add_timer(dev-timer); --
}
}
applied to CVS.
Holger
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as
subject.
[linux-dvb] Re: CRC32 errors in sections
Jeremy Hall wrote: Hi, In a quest to determine why the ARM is crashing during a section filter activity, I discovered I am getting several CRC32 checksum errors on sections, and thus they aren't being used, creating the appearance of a XRUN. To combat this, I added DMX_CHECK_CRC to the section filter flags, but still continued to see the checksum errors. The DMX_CHECK_CRC flag is not implemented for av7110 based cards right now. If you want to implement this follow the Budget codepath for an example. What might be the cause of data corruption? Buffer overflows because the host did not fetched the data fast enough or uncorrectable block errrors in the MPEG stream. Maybe even a firmware bug under high load. When the driver gives you a section, does it at least sanity check the seclen to determine if it will make a memory out of bounds problem so it won't happily overwrite other memory? The read() function call will never read more bytes than you specified in the argument, so you'll never overwrite more memory than you passed as read()-buffer. Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: A/V sync problems with new drivers
Juri Haberland wrote: Oliver Endriss wrote: I also noticed a/v sync problems once or twice but I cannot reproduce it. On http://www.linuxdvb.tv/download/ there are daily snapshots of the driver. Could you please try to find out the *precise* date when this bug was introduced? If you could report this date I will check what has been changed... Phew, this will take some time, especially as the weekend has come, which means that the machine is in production. This is not as difficult as it looks. You reported that the driver 13jan03 is ok and 13feb03 (1.0.0-pre1) isn't. Take the date in the middle of the interval and download this driver, let's say 29jan03. Test it. If it's ok take the middle of the interval (29jan, 13feb), if it's not ok take the middle of (13jan, 29jan). And so on... This way you will have to try only 5 drivers to find the date. Good luck, Oliver -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: CRC32 errors in sections
In the new year, Holger Waechtler wrote: Jeremy Hall wrote: The DMX_CHECK_CRC flag is not implemented for av7110 based cards right now. If you want to implement this follow the Budget codepath for an example. Where does that codepath start? Why has it not been implemented? What might be the cause of data corruption? Buffer overflows because the host did not fetched the data fast enough or uncorrectable block errrors in the MPEG stream. Maybe even a firmware bug under high load. Would increasing the section buffer size help with this? How would I be able to find a firmware bug under high load? Both signal and SNR readings are good, so I doubt uncorrectable block errors would be a factor. When the driver gives you a section, does it at least sanity check the seclen to determine if it will make a memory out of bounds problem so it won't happily overwrite other memory? The read() function call will never read more bytes than you specified in the argument, so you'll never overwrite more memory than you passed as read()-buffer. Is it a mmap'd read and you're actually accessing the incoming buffer, or does the driver copy a section to you? This question relates to the driver copying that data to userspace--how does it know how much to copy. If the seclen is not correct, can the driver trash its memory structures? _J Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Driver problem with a Hauppauge Nova: Erroneous unsupported PLL synthesizer
I investigated a bit. I added some trace statements and additional i2c bus accesses. I discovered that every SECOND i2c bus access succeded. I traced this down to saa7146_i2c.c/saa7146_i2c_transfer(). When it writes the data to the bus, it checks for errors. There is a special check for an i2c address-error... if this occurs, the write is abandoned with no retries and returns with EREMOTEIO. As a test, I disabled this piece of code, and now the tuner is detected fine.. I can even tune and use the card as normal. However, this is not a solution. To transfer something on the i2c bus, you have to write it twice every time (first time fails with an address error, second time succeeds). I assume this means something is slightly different about this newer board revision. Does this only happen on transfers to the PLL? If yes, is it done in two transfer steps or in one (double) transfer in the driver you are using? Otherwise I cannot think of much else that can go wrong. For me the SU1278/SH works fine on different kinds of hardware (KNC DVB-S with SAA7146 and Flyvideo DVB-S with SAA7130). Its an SAA7146-based card, so its just using the standard i2c code in saa7146_i2c.c I'm getting really really suspicious of that card: a) It has this weird i2c problem b) That machine has suddenly starting crashing an awful lot since I put the card in. A moment ago, I didn't even DO anything with the card.. I just insmod/rmmodded the drivers twice... I know this does some initialisation, but I've never seen this with my SAA7146-based DVB-T cards. c) Apart from having the additional places for the CI stuff, that card is using the same chip revisions as everyone else's so there shouldn't *be* any problems. Oh, I tried adding the PCI device id to dvb-budget.c to check it wasn't something odd the dvb-budget-ci.c was doing it still had the same problems. Does anyone else have a Hauppauge Nova card working in parallel with a Hauppauge Nova-T card (or their equivalents)? I think this card is duff, and I just want to check that it IS supported (I _know_ it is, but I have to confirm it). -- adq -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: CRC32 errors in sections
Jeremy Hall wrote: In the new year, Holger Waechtler wrote: Jeremy Hall wrote: The DMX_CHECK_CRC flag is not implemented for av7110 based cards right now. If you want to implement this follow the Budget codepath for an example. Where does that codepath start? Why has it not been implemented? in the interrupt handlers. vpeirq() and fidbirq() for budget cards and debiirq() for av7110 based cards. When the driver gives you a section, does it at least sanity check the seclen to determine if it will make a memory out of bounds problem so it won't happily overwrite other memory? The read() function call will never read more bytes than you specified in the argument, so you'll never overwrite more memory than you passed as read()-buffer. Is it a mmap'd read and you're actually accessing the incoming buffer, or does the driver copy a section to you? This question relates to the driver copying that data to userspace--how does it know how much to copy. If the seclen is not correct, can the driver trash its memory structures? no. If this happens you definitely found a driver bug. Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: CRC32 errors in sections
In the new year, Holger Waechtler wrote: Jeremy Hall wrote: In the new year, Holger Waechtler wrote: Jeremy Hall wrote: When the driver gives you a section, does it at least sanity check the seclen to determine if it will make a memory out of bounds problem so it won't happily overwrite other memory? The read() function call will never read more bytes than you specified in the argument, so you'll never overwrite more memory than you passed as read()-buffer. Is it a mmap'd read and you're actually accessing the incoming buffer, or does the driver copy a section to you? This question relates to the driver copying that data to userspace--how does it know how much to copy. If the seclen is not correct, can the driver trash its memory structures? no. If this happens you definitely found a driver bug. Well, to put it another way, when the userspace program requests a section filter, and starts it, what exactly does the driver prepare for it? The user gets the section length from the second and third bytes of the section. If those are corrupt, and they are still less than the buffer size, the userspace application will read however much data it was told to read, we can't recover from that. Then when we've read part way into another section, how do we get resynched with section boundaries? If they are corrupt and larger than the userspace buffer size, how does the userspace program know how far to read ahead to find the next section? If CRC failure is detected, is it best to close and reopen the filter? _J Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: CRC32 errors in sections
On Fri, Mar 14, 2003 at 12:40:17PM -0500, Jeremy Hall wrote: Well, to put it another way, when the userspace program requests a section filter, and starts it, what exactly does the driver prepare for it? The user gets the section length from the second and third bytes of the section. If those are corrupt, and they are still less than the buffer size, the userspace application will read however much data it was told to read, we can't recover from that. Then when we've read part way into another section, how do we get resynched with section boundaries? If they are corrupt and larger than the userspace buffer size, how does the userspace program know how far to read ahead to find the next section? If CRC failure is detected, is it best to close and reopen the filter? The section length field has 12 bits, so if you use a buffer of 4096 bytes length for your read, you will alwas get one full section per read() call (the API guarantees that). If you find the section to be broken, throw it away and read the next one. OTOH the API also guarantees that you never get broken sections if you use DMX_CHECK_CRC (provided the section_syntax_indicator is 1). The av7110 implementation must be fixed. The reason that it's broken now is that the AV7110 has hardware for the CRC check, but no one got around implementing the check in the firmware. Or maybe the Metzlers tried and it didn't work. Anyway, it's simpler to implement it on the PC now. If someone sometime implements it in the firmware, the check on the PC can be eleminated... Regards, Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Erroneous unsupported PLL synthesizer: found it!!
Hi, I've found the problem. It seems to be the same one as mentioned in dvb-kernel and alps_bsru6 not tuning from Matt Davis on Mon, 03 Feb 2003. Basically, sending both i2c commands at the same time means the stv0299 bus repeater does not have enough time (the i2c device returns BUSY 'cos it hasn't finished with the first message). Adopting the same solution (breaking all the double-i2c PLL writes up into two single ones) makes the PLL work again. Patch coming up in a sec. Er, should I just make it always use two i2c commands when writing to the PLL in the i2c code? Two double ones seem to be causing lots of issues what do people think? -- adq -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: CRC32 errors in sections
Johannes Stezenbach writes: On Fri, Mar 14, 2003 at 12:40:17PM -0500, Jeremy Hall wrote: [...] The reason that it's broken now is that the AV7110 has hardware for the CRC check, but no one got around implementing the check in the firmware. Or maybe the Metzlers tried and it didn't work. Anyway, it's simpler to implement it on the PC now. If someone sometime implements it in the firmware, the check on the PC can be eleminated... As far as I can see you are all using the firmware in TS mode since last October or so. Thus, all problems with section filtering which you blame on the firmware are purely psychosomatic. The data path (including CRC checking) is exactly the same as in the case of the Nova cards. Ralph -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Erroneous unsupported PLL synthesizer: found it!!
Andrew de Quincey writes: Hi, I've found the problem. It seems to be the same one as mentioned in dvb-kernel and alps_bsru6 not tuning from Matt Davis on Mon, 03 Feb 2003. Basically, sending both i2c commands at the same time means the stv0299 bus repeater does not have enough time (the i2c device returns BUSY 'cos it hasn't finished with the first message). Adopting the same solution (breaking all the double-i2c PLL writes up into two single ones) makes the PLL work again. Well, I did ask you yesterday if PLL writes are done in one transfer or two in the driver you are using. Ralph -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: CRC32 errors in sections
In the new year, Johannes Stezenbach wrote: On Fri, Mar 14, 2003 at 12:40:17PM -0500, Jeremy Hall wrote: Well, to put it another way, when the userspace program requests a section filter, and starts it, what exactly does the driver prepare for it? The user gets the section length from the second and third bytes of the section. If those are corrupt, and they are still less than the buffer size, the userspace application will read however much data it was told to read, we can't recover from that. Then when we've read part way into another section, how do we get resynched with section boundaries? If they are corrupt and larger than the userspace buffer size, how does the userspace program know how far to read ahead to find the next section? If CRC failure is detected, is it best to close and reopen the filter? The section length field has 12 bits, so if you use a buffer of 4096 bytes length for your read, you will alwas get one full section per read() call (the API guarantees that). If you find the section to be broken, throw it away and read the next one. OTOH the API also guarantees that you never get broken sections if you use DMX_CHECK_CRC (provided the section_syntax_indicator is 1). The av7110 implementation must be fixed. The reason that it's broken now is that the AV7110 has hardware for the CRC check, but no one got around implementing the check in the firmware. Or maybe the Metzlers tried and it didn't work. Anyway, it's simpler to implement it on the PC now. If someone sometime implements it in the firmware, the check on the PC can be eleminated... I don't mind doing it in the PC, my goal right now is to figure out why the arm is crashing. One thing I am looking at now is line 1011 of av7110.c, if (av7110-handle2filter[handle]) Could this create a race condition with its counterpart 3 lines down? or could this be optimized to avoid the same call twice? _J Regards, Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: CRC32 errors in sections
Hi, all I know is that when I'm processing sections, the arm may crash. when I'm not, the arm will not crash. The arm seems only to crash under high volumes of data, or, because there are more datapoints, there is more chance for error. Using the DVB CVS tree, how do I determine whether the firmware is in TS mode or not? _J In the new year, Ralph Metzler wrote: Johannes Stezenbach writes: On Fri, Mar 14, 2003 at 12:40:17PM -0500, Jeremy Hall wrote: [...] The reason that it's broken now is that the AV7110 has hardware for the CRC check, but no one got around implementing the check in the firmware. Or maybe the Metzlers tried and it didn't work. Anyway, it's simpler to implement it on the PC now. If someone sometime implements it in the firmware, the check on the PC can be eleminated... As far as I can see you are all using the firmware in TS mode since last October or so. Thus, all problems with section filtering which you blame on the firmware are purely psychosomatic. The data path (including CRC checking) is exactly the same as in the case of the Nova cards. Ralph -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: CRC32 errors in sections
Jeremy Hall writes: all I know is that when I'm processing sections, the arm may crash. when I'm not, the arm will not crash. The arm seems only to crash under high volumes of data, or, because there are more datapoints, there is more chance for error. Sure, if the total data rate of the selected PIDs is too high, this can probably happen. But I guess it does not really crash but might only be too busy to react to any new commands. Using the DVB CVS tree, how do I determine whether the firmware is in TS mode or not? By checking what filter mode is used in StartHWFilter in av7110.c or however it is now called in CVS. If it only uses 0xb96a it is in TS mode. Ralph -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: CRC32 errors in sections
In the new year, Ralph Metzler wrote: Jeremy Hall writes: all I know is that when I'm processing sections, the arm may crash. when I'm not, the arm will not crash. The arm seems only to crash under high volumes of data, or, because there are more datapoints, there is more chance for error. Sure, if the total data rate of the selected PIDs is too high, this can probably happen. But I guess it does not really crash but might only be too busy to react to any new commands. It says arm crashed in the logs and all the filters stop feeding until they are created again, i.e. when vdr restarts. The start mode is set to 0x96a in my tree. The other one is commented. 0x0320 What is the bw limit that can cause the arm to crash? _J Using the DVB CVS tree, how do I determine whether the firmware is in TS mode or not? By checking what filter mode is used in StartHWFilter in av7110.c or however it is now called in CVS. If it only uses 0xb96a it is in TS mode. Ralph -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Erroneous unsupported PLL synthesizer: found it!!
On Friday 14 March 2003 18:35, Ralph Metzler wrote: Andrew de Quincey writes: Hi, I've found the problem. It seems to be the same one as mentioned in dvb-kernel and alps_bsru6 not tuning from Matt Davis on Mon, 03 Feb 2003. Basically, sending both i2c commands at the same time means the stv0299 bus repeater does not have enough time (the i2c device returns BUSY 'cos it hasn't finished with the first message). Adopting the same solution (breaking all the double-i2c PLL writes up into two single ones) makes the PLL work again. Well, I did ask you yesterday if PLL writes are done in one transfer or two in the driver you are using. Yeah, I wasn't quite sure what you meant. In hindsight, of course, it all makes sense now :) Anyway, shall I just patch it in for my PLL chip in particular, or just change all the PLL code to use seperate i2c transmissions? -- adq -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: DVB API registration info, please
Hi, I would like to start with getting the demux, dvr and frontend devices set up so that the mpeg stream can be recorded and the channel can be changed. A brief list of things I have to register with the dvb api in order to achieve this, and a short description of what each bit does, would be incredibly useful to me, and greatly appreciated :) http://cvs.berlios.de/cgi-bin/viewcvs.cgi/tuxbox/driver/dvb/drivers/media/dv b/dummy/dummyadap.c?rev=1.4content-type=text/vnd.viewcvs-markup This is a simple driver we've used to develop a full featured V3 driver. Maybe it helps you a bit. You need to fill start/stop_feed + i2c_xfer with the proper hw handling. Bye, Florian -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: V4 API proposal
Please discard my proposal. Everything could be done from user space with user space fs and a full TS dump card, no need for anything else in the API, I guess. Emard -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
