[linux-dvb] experimental version of HVR-4000 DVB-S2 DEMOD driver
Hi you can inroduce with the experimental version of HVR-4000 DVB-S2 DEMOD driver on Darron Broad's home page http://dev.kewl.org/hauppauge/experimental/ Igor ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] make errors multiproto
> Manu, I do not understand your response other words - you can forget about this warnings (not errors) > I am using the TT3200 and so the stb0899 module will be required > > I cannot see how make menuconfig can disable the stb0899 module as it is not > a recognised module in 2.6.23.137 > > Although if I ignore the errors, the modules appear to compile and then load fine. > But then the best I can get with with zapping using your modified szap is > > status 00 | signal | snr 0004 | ber | unc fffe | status 1e > | signal 0136 | snr 005f | ber | unc fffe | FE_HAS_LOCK status > 1e | signal 0136 | snr 005f | ber | unc fffe | FE_HAS_LOCK > status 1e | signal 0136 | snr 0060 | ber | unc fffe | > FE_HAS_LOCK status 1e | signal 0136 | snr 005e | ber | unc fffe > | FE_HAS_LOCK status 1e | signal 0136 | snr 005e | ber | unc > fffe | FE_HAS_LOCK > > I need to know if I am on the right track or those compile errors are having > an influence on the performance of the TT3200 frontend yes, you on the right track and you can continue your tests wit TT3200 > The signal strength should be >50-60% and quality >80% please mean - szap2 shows the dB in hex. Igor ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] My new Divco Dual4 don't work Need new pci card advice?
my brand new Dvico dual 4 dvb-t is a new revision in the windows driver the new hw id of card its called a dual5 has a dib7070pb chip i can get the card to load but comes up with no frontend under dmesg (by changeing the usb id file form db78 to db98) anyway to get the wife to talk to me again (spent up on a new mythbox and she is asking wheres the picture for the money you have spent) i need a pci card, dvb-t twin tuners, no analog, and must work out of the box for linux any sugestions cheers PS. anybody who worked on a dvico dual 4 let us know, the new card has the diversity dib7070pb chip looks the same as the pinnical card see here http://mandmservices.com.au/dvico___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Help with demux, dvr and ringbuffers
Hi, I've understood a bit more how demux, dvr and rigbuffers work, but I still have a couple of issues. I've been studying tzap, which seems much easier than gnutv. tzap opens the demux twice (audio and video) and then opens the dvr to read the multiplexed data. There are 3 ringbuffers involved: When a demux is opened, a ringbuffer of 8192 is created (so there are 2 of them). I can change its size using DMX_SET_BUFFER_SIZE on the demux. Then when the dvr is opened an other ringbuffer is created of size 1925120 = 18 * 100 * 1024. I don't know how to change its size. My question is the following: When I setup the demux to output to the dvr with DMX_OUT_TS_TAP, what happens afterwards? Is the following correct or wrong? 1) The "kernel" will write data into the 2 buffers 2) The "kernel" will read from the 2 demuxes and write to the dvr. This has very low latency so a small ringbuffer for the 2 demuxes is ok. 3) A userspace application has to read from the dvr. If it is not fast enough the dvr's ringbuffer gets filled and we are in troubles. If this happens I think the best solution would be to overwrite the oldest data. This ringbuffer needs to take into account all sort of bottleneck one might have. If it is true I have to find how to change the size of the dvr's ringbuffer. Anybody knows why the callback (in dmxdev.c) static int dvb_dvr_do_ioctl(struct inode *inode, struct file *file, unsigned int cmd, void *parg) does not handle DMX_SET_BUFFER_SIZE? Is there an intrinsic issue or is it just to be done? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Tuning fails with Twinhan DVB-C AD-CP300 (Mantis 2033)
Changed the tuner to TDA10023 and it worked like a charm! Thanks alot! Best regards, Rikard Wissing > Date: Sat, 1 Mar 2008 14:44:12 +0100 > To: linux-dvb@linuxtv.org > From: [EMAIL PROTECTED] > Subject: Re: [linux-dvb] Tuning fails with Twinhan DVB-C AD-CP300 (Mantis > 2033) > > Rikard Wissing schrieb: > >> [ 4022.656841] mantis_frontend_init (0): Probing for CU1216 (DVB-C) >> [ 4022.658236] TDA10021: i2c-addr = 0x0c, id = 0x7d >> [ 4022.658238] mantis_frontend_init (0): found Philips CU1216 DVB-C frontend >> (TDA10021) @ 0x0c >> [ 4022.658240] mantis_frontend_init (0): Mantis DVB-C Philips CU1216 >> frontend attach success >> [ 4022.658243] DVB: registering frontend 0 (Philips TDA10021 DVB-C)... > > The chip ID is 0x7d. Probably, your card uses a CU1216-3 with a TDA10023. > There are > differences between the TDA10021 and the TDA10023. > > -Hartmut > > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb _ Mörkt och kallt? Kanske Barcelona? http://search.live.com/results.aspx?q=Barcelona+reseguide&form=QBRE ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] STB0899 users, please verify results was Re: TechniSat SkyStar HD: Problems scaning and zaping
Manu Abraham wrote:
> Seppo Ingalsuo wrote:
>> Simeon Simeonov wrote:
>>> Did you try changing line 250 in mantis_dvb.c to:
>>> if (!lnbp21_attach(mantis->fe, &mantis->adapter,
>>> LNBP21_PCL, LNBP21_ISEL)) {
>>>
>> I tried mantis-a9ecd19a37c9. Without the change success in
>> positioning was about 0% similarly as with multiproto-0448e5a6d8a6.
>> After this change the success in zapping between different satellite
>> positions increased to about 40% so it looks now promising and vdr
>> satellite channels are usable with some patience :^)
>
>
> You mean the LNBP21 attach line improved things for you by 40% ?
Yes, the LNBP21_PCL and LNBP21_ISEL additions did the improvement. By
40% I mean that about 4/10 zappings between channels in different
satellite positions are succesfull. Without this change it was very rare
to get the dish to move, the success rate was < 1/10.
> If you can really identify what is "really" unreliable, that itself
> will be a help
> to fix the issue, in most cases.
Compared to my old DVB-S card this DVB-S2 card is too unreliable for my
family to use it. There is one possible issue with vdr rotor plugin. It
would help in my case if it would set always high LNB voltage before
sending gotox command and keep it for estimated time of movent (based on
about 0.9 seconds/degree speed) before setting the voltage for the tuned
channel. The motor movement with low LNB voltage is very slow especially
in winter and I'm not absolutely sure that the failure is due to
corrupted diseqc gotox command or just too low voltage to get the motor
running. The old DVB-S card was also driving the dish at slow speed with
low LNB voltage but I need to hack the rotor code to rule out this
theory. I need to check also the LNB cable that connects to the PC that
it is still OK.
>
>> Which DVB-S2 multiproto driver tree should I follow for latest
>> development for TT S2-3200 (/Skystar HD)?
>
> For the SAA7146 based cards, use the multiproto tree, for the Mantis
> based
> cards, use the mantis tree.
OK, thanks. It seems there is now 10min fresh new code to try!
BR,
Seppo
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?
Hi,
i was wondering why i have a problem in my application that i need to
run scan once after loading the module, otherwise my DVBFE_SET_PARAMS
fails - I couldnt explain it until i looked into the kernel code - In
the dvb_frontend.c i see this code:
1738 case DVBFE_SET_PARAMS: {
1739 struct dvb_frontend_tune_settings fetunesettings;
1740 enum dvbfe_delsys delsys = fepriv->fe_info.delivery;
...
1783 } else {
1784 /* default values */
1785 switch (fepriv->fe_info.delivery) {
...
1817 default:
1818 up(&fepriv->sem);
1819 return -EINVAL;
1820 }
Should the code use fepriv->feparam.delivery instead of
fepriv->fe_info.delivery to sense the right delivery system ?
Flo
--
Florian Lohoff [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
signature.asc
Description: Digital signature
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Tuning fails with Twinhan DVB-C AD-CP300 (Mantis 2033)
Rikard Wissing schrieb: > [ 4022.656841] mantis_frontend_init (0): Probing for CU1216 (DVB-C) > [ 4022.658236] TDA10021: i2c-addr = 0x0c, id = 0x7d > [ 4022.658238] mantis_frontend_init (0): found Philips CU1216 DVB-C frontend > (TDA10021) @ 0x0c > [ 4022.658240] mantis_frontend_init (0): Mantis DVB-C Philips CU1216 frontend > attach success > [ 4022.658243] DVB: registering frontend 0 (Philips TDA10021 DVB-C)... The chip ID is 0x7d. Probably, your card uses a CU1216-3 with a TDA10023. There are differences between the TDA10021 and the TDA10023. -Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] make errors multiproto
Manu, I do not understand your response I am using the TT3200 and so the stb0899 module will be required I cannot see how make menuconfig can disable the stb0899 module as it is not a recognised module in 2.6.23.137 Although if I ignore the errors, the modules appear to compile and then load Output from lsmod Module Size Used by nls_utf8 10305 1 vfat 19009 1 fat54513 1 vfat rfcomm 50537 0 l2cap 36289 9 rfcomm bluetooth 64453 4 rfcomm,l2cap sunrpc168009 1 cpufreq_ondemand 15569 1 loop 23493 0 dm_multipath 24401 0 ipv6 307273 18 osst 57193 0 st 43109 0 lnbp21 10240 1 stb610015748 1 stb089941728 1 saa7134_dvb24076 0 videobuf_dvb 13316 1 saa7134_dvb tda1004x 23300 2 saa7134_dvb sr_mod 23397 1 cdrom 40553 1 sr_mod snd_hda_intel 361577 3 snd_seq_dummy 11461 0 snd_seq_oss37313 0 snd_seq_midi_event 15041 1 snd_seq_oss snd_seq56673 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event snd_seq_device 15061 3 snd_seq_dummy,snd_seq_oss,snd_seq snd_pcm_oss45889 0 snd_mixer_oss 22721 1 snd_pcm_oss snd_pcm80201 2 snd_hda_intel,snd_pcm_oss snd_timer 27721 2 snd_seq,snd_pcm snd_page_alloc 16465 2 snd_hda_intel,snd_pcm budget_ci 30980 0 budget_core17668 1 budget_ci saa7134 148572 1 saa7134_dvb videodev 33664 1 saa7134 v4l1_compat19460 1 videodev compat_ioctl32 16128 1 saa7134 v4l2_common26240 3 saa7134,videodev,compat_ioctl32 videobuf_dma_sg19716 3 saa7134_dvb,videobuf_dvb,saa7134 videobuf_core 24196 3 videobuf_dvb,saa7134,videobuf_dma_sg ir_kbd_i2c 16912 1 saa7134 snd_hwdep 16073 1 snd_hda_intel dvb_core 89684 3 videobuf_dvb,budget_ci,budget_core saa714623688 2 budget_ci,budget_core ttpci_eeprom 10496 1 budget_core firewire_ohci 25281 0 ir_common 41732 3 budget_ci,saa7134,ir_kbd_i2c snd60137 15 snd_hda_intel,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_o ss,snd_pcm,snd_timer,snd_hwdep nvidia 8895940 24 firewire_core 46337 1 firewire_ohci crc_itu_t 10433 1 firewire_core aic7xxx 133501 0 scsi_transport_spi 32577 1 aic7xxx parport_pc 35177 0 tveeprom 24848 1 saa7134 soundcore 15073 1 snd sg 40297 0 forcedeth 53321 0 parport42317 1 parport_pc pcspkr 11329 0 button 15969 0 pata_amd 20293 0 k8temp 13377 0 hwmon 11081 1 k8temp i2c_nforce214017 0 usblp 20801 0 i2c_core 28865 14 lnbp21,stb6100,stb0899,saa7134_dvb,tda1004x,budget_ci,budget_core,saa713 4,v4l2_common,ir_kbd_i2c,ttpci_eeprom,nvidia,tveeprom,i2c_nforce2 usb_storage87681 2 dm_snapshot23049 0 dm_zero10433 0 dm_mirror 27200 0 dm_mod 57905 9 dm_multipath,dm_snapshot,dm_zero,dm_mirror ata_generic14533 0 sata_nv25285 2 libata114288 3 pata_amd,ata_generic,sata_nv sd_mod 33345 5 scsi_mod 146553 9 osst,st,sr_mod,aic7xxx,scsi_transport_spi,sg,usb_storage,libata,sd_mod ext3 127569 2 jbd64945 1 ext3 mbcache15937 1 ext3 uhci_hcd 30689 0 ohci_hcd 27973 0 ehci_hcd 39245 0 But then the best I can get with with zapping using your modified szap is status 00 | signal | snr 0004 | ber | unc fffe | status 1e | signal 0136 | snr 005f | ber | unc fffe | FE_HAS_LOCK status 1e | signal 0136 | snr 005f | ber | unc fffe | FE_HAS_LOCK status 1e | signal 0136 | snr 0060 | ber | unc fffe | FE_HAS_LOCK status 1e | signal 0136 | snr 005e | ber | unc fffe | FE_HAS_LOCK status 1e | signal 0136 | snr 005e | ber | unc fffe | FE_HAS_LOCK I need to know if I am on the right track or those compile errors are having an influence on the performance of the TT3200 frontend The signal strength should be >50-60% and quality >80% Best Regards Michael Curtis wrote: > Can anyone help with this please? > Disable that relevant module by using a custom config, such as using make menuconfig, or make xconfig or whatever. Regards, Manu > -Or
[linux-dvb] Tuning fails with Twinhan DVB-C AD-CP300 (Mantis 2033)
Hi there, I've got the following card: http://www.twinhan.com/product_cable_2033.asp I am running Ubunu 7.10 with kernel 2.6.22-14-generic I have compiled and installed the latest drivers from http://jusst.de/hg/mantis and it seems to detect the card correctly but when scanning for channels it fails. The card works correctly in windows. This is what dmesg gives me: ... [ 4022.137802] found a VP-2033 PCI DVB-C device on (05:05.0), [ 4022.137803] Mantis Rev 1 [1822:0008], irq: 23, latency: 64 [ 4022.137805] memory: 0xfdaff000, mmio: 0xf8abc000 [ 4022.140491] MAC Address=[00:08:ca:1c:2e:4b] [ 4022.140502] mantis_alloc_buffers (0): DMA=0x2e83 cpu=0xee83 size=65536 [ 4022.140506] mantis_alloc_buffers (0): RISC=0x2e819000 cpu=0xee819000 size=1000 [ 4022.140508] DVB: registering new adapter (Mantis dvb adapter) [ 4022.656841] mantis_frontend_init (0): Probing for CU1216 (DVB-C) [ 4022.658236] TDA10021: i2c-addr = 0x0c, id = 0x7d [ 4022.658238] mantis_frontend_init (0): found Philips CU1216 DVB-C frontend (TDA10021) @ 0x0c [ 4022.658240] mantis_frontend_init (0): Mantis DVB-C Philips CU1216 frontend attach success [ 4022.658243] DVB: registering frontend 0 (Philips TDA10021 DVB-C)... ... When trying to scan it simply gives me the following result: using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 37000 6875000 0 3 >>> tune to: 37000:INVERSION_AUTO:6875000:FEC_NONE:QAM_64 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 WARNING:>>> tuning failed!!! >>> tune to: 37000:INVERSION_AUTO:6875000:FEC_NONE:QAM_64 (tuning failed) >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 >>> tuning status == 0x00 WARNING:>>> tuning failed!!! Is there any way i can debug the driver to see where it goes wrong? If there is anything i can do, I would be glad to help out. Any help would be greatly appreciated. Best regards, Rikard Wissing _ Mörkt och kallt? Kanske Barcelona? http://search.live.com/results.aspx?q=Barcelona+reseguide&form=QBRE ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [PATCH] Support for TT connect S2-3600
Hi,
I have reviewed my last week's quick shot patch and here is a new version.
The firmware I mentioned in the first patch is not needed, since it is
stored on the device itself.
I also got the black TT remote working with it. I had to set rc_interval
to 500, because the key repeats came in too fast.
The image distortions I mentioned in an earlier post are still visible.
Dominik said that he also had packet losses on a TS record. So I hope he
can fix it.
Before applying the attached patch you need to apply Dominik's patch for
the Pinnacle PCTV 452e.
Please test the attached patch and let me know if you ran into any problems.
Note:
Manu's code in changeset 7207 seems to have broken tuning for this
device. Changesets 7202 to 7205 are still working.
Have a nice weekend.
André
diff -Nrubw multiproto-452/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h multiproto_S2-3600/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- multiproto-452/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2008-03-01 10:48:28.674288316 +0100
+++ multiproto_S2-3600/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2008-03-01 10:48:48.715408833 +0100
@@ -40,6 +40,7 @@
#define USB_VID_MSI0x0db0
#define USB_VID_OPERA10x695c
#define USB_VID_PINNACLE 0x2304
+#define USB_VID_TECHNOTREND 0x0b48
#define USB_VID_TERRATEC 0x0ccd
#define USB_VID_VISIONPLUS 0x13d3
#define USB_VID_TWINHAN0x1822
@@ -142,6 +143,7 @@
#define USB_PID_PCTV_400E0x020f
#define USB_PID_PCTV_450E0x0222
#define USB_PID_PCTV_452E 0x021f
+#define USB_PID_TECHNOTREND_CONNECT_S2_3600 0x3007
#define USB_PID_NEBULA_DIGITV0x0201
#define USB_PID_DVICO_BLUEBIRD_LGDT 0xd820
#define USB_PID_DVICO_BLUEBIRD_LG064F_COLD 0xd500
diff -Nrubw multiproto-452/linux/drivers/media/dvb/dvb-usb/Kconfig multiproto_S2-3600/linux/drivers/media/dvb/dvb-usb/Kconfig
--- multiproto-452/linux/drivers/media/dvb/dvb-usb/Kconfig 2008-03-01 10:48:28.674288316 +0100
+++ multiproto_S2-3600/linux/drivers/media/dvb/dvb-usb/Kconfig 2008-03-01 10:48:48.715408833 +0100
@@ -240,14 +240,15 @@
Afatech AF9005 based receiver.
config DVB_USB_PCTV452E
- tristate "Pinnacle PCTV HDTV Pro USB device"
+ tristate "Pinnacle PCTV HDTV Pro USB device / TT connect S2-3600 (NEW)"
depends on DVB_USB
select DVB_LNBP22
select DVB_STB0899
select DVB_STB6100
help
- Support for external USB adapter designed by Pinnacle,
- shipped under the brand name 'PCTV HDTV Pro USB'.
+ Support for external USB adapter designed by TechnoTrend and,
+ shipped under the brand name 'Pinnacle PCTV HDTV Pro USB' and
+ 'TechnoTrend TT connect S2-3600'.
These devices don't have a MPEG decoder built in, so you need
an external software decoder to watch TV.
diff -Nrubw multiproto-452/linux/drivers/media/dvb/dvb-usb/pctv452e.c multiproto_S2-3600/linux/drivers/media/dvb/dvb-usb/pctv452e.c
--- multiproto-452/linux/drivers/media/dvb/dvb-usb/pctv452e.c 2008-03-01 10:48:28.678288540 +0100
+++ multiproto_S2-3600/linux/drivers/media/dvb/dvb-usb/pctv452e.c 2008-03-01 10:48:48.719409057 +0100
@@ -320,6 +320,53 @@
{0x07, 0x3f, KEY_HELP}
};
+
+/* Remote Control Stuff fo S2-3600 (copied from TT-S1500): */
+static struct dvb_usb_rc_key tt_connect_s2_3600_rc_key[] = {
+{0x15, 0x01, KEY_POWER},
+{0x15, 0x02, KEY_SHUFFLE}, /* ? double-arrow key */
+{0x15, 0x03, KEY_1},
+{0x15, 0x04, KEY_2},
+{0x15, 0x05, KEY_3},
+{0x15, 0x06, KEY_4},
+{0x15, 0x07, KEY_5},
+{0x15, 0x08, KEY_6},
+{0x15, 0x09, KEY_7},
+{0x15, 0x0a, KEY_8},
+{0x15, 0x0b, KEY_9},
+{0x15, 0x0c, KEY_0},
+{0x15, 0x0d, KEY_UP},
+{0x15, 0x0e, KEY_LEFT},
+{0x15, 0x0f, KEY_OK},
+{0x15, 0x10, KEY_RIGHT},
+{0x15, 0x11, KEY_DOWN},
+{0x15, 0x12, KEY_INFO},
+{0x15, 0x13, KEY_EXIT},
+{0x15, 0x14, KEY_RED},
+{0x15, 0x15, KEY_GREEN},
+{0x15, 0x16, KEY_YELLOW},
+{0x15, 0x17, KEY_BLUE},
+{0x15, 0x18, KEY_MUTE},
+{0x15, 0x19, KEY_TEXT},
+{0x15, 0x1a, KEY_MODE}, /* ? TV/Radio */
+{0x15, 0x21, KEY_OPTION},
+{0x15, 0x22, KEY_EPG},
+{0x15, 0x23, KEY_CHANNELUP},
+{0x15, 0x24, KEY_CHANNELDOWN},
+{0x15, 0x25, KEY_VOLUMEUP},
+{0x15, 0x26, KEY_VOLUMEDOWN},
+{0x15, 0x27, KEY_SETUP},
+{0x15, 0x3a, KEY_RECORD},/* these keys are only in the black remote */
+{0x15, 0x3b, KEY_PLAY},
+{0x15, 0x3c, KEY_STOP},
+{0x15, 0x3d, KEY_REWIND},
+{0x15, 0x3e, KEY_PAUSE},
+{0x15, 0x3f, KEY_FORWARD}
+};
+
+
+
+
static int pctv452e_rc_query(struct dvb_usb_device *d, u32 *keyevent, int *keystate) {
struct pctv452e_state *state = (struct pctv452e_state *)d->priv;
u8 b[CMD_BUFFER_SIZE];
@@ -370,6 +417,7 @@
static struct stb0899_config stb0899_config;
static struct stb6100_config stb6100_config;
stati
Re: [linux-dvb] RE : Length of /dev/dvb/adapter0/dvr0's buffer.
Thierry Lelegard wrote:
>> I'm trying to read from /dev/dvb/adapter0/dvr0.
>> The problem is that the process reading sometimes is not fast enough and
>> after a while I get errno
>> 75 when I try to read from it.
>>
>> On average the speed is ok, so it should work.
>> There must be a buffer behind dvr0 that goes in error onece it is full.
>>
>> 1) how can I make it bigger?
>> 2) how can I check how full it is?
>
> You can set the *demux* buffer size, upstream from dvr, using ioctl
> DMX_SET_BUFFER_SIZE.
> The default value is 8 kB. Using 1 MB, I can do full TS capture without any
> loss.
>
>
I've noticed that there are 2 ioctl DMX_SET_BUFFER_SIZE, one for the demux, one
for the dvr.
The second is not implemented.
switch (cmd) {
case DMX_SET_BUFFER_SIZE:
// FIXME: implement
ret = 0;
break;
Could you please help me:
1) how many ringbuffers are there?
2) I'm reading from dvr, which one do I need to set?
3) I can try to implement the above code if needed.
Cheers
Andrea
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Help using DMX_SET_BUFFER_SIZE
Florian Lohoff wrote:
> On Sat, Mar 01, 2008 at 12:20:05AM +, Andrea wrote:
>> on the dvr (I think), but it does not make much of a change. The ioctl call
>> returns success.
>> I've printed a lot of debug output (adding a few dprintk) and this is what I
>> see when I run gnutv.
>> Now, I set the buffer to 1024 * 1024 which is nowhere in the log.
>> I cannot see in the log the 2 functions (demux and dvr) handling this ioctl
>> call:
>> dvb_demux_do_ioctl and dvb_dvr_do_ioctl (I've added some printk as well).
>
> In 2.6.25-rc3 the dvr kernel side looks like this:
>
> 1015 switch (cmd) {
> 1016 case DMX_SET_BUFFER_SIZE:
> 1017 // FIXME: implement
> 1018 ret = 0;
> 1019 break;
>
> i guess its clear why it doesnt make a difference ;)
>
> Flo
Yes I had noticed that and I was trying to see what I can do.
My problem is that I replace the // FIXME with a printk() and it does not get
called
How is it supposed to work?
I open /dev/dvb/adapter0/dvr0, I get back a file descriptor and the I call the
ioctl with that file
descriptor.
This code comes from gnutv_data.c plus my additional code
// open dvr device
dvrfd = dvbdemux_open_dvr(adapter_id, 0, 1, 0);
if (dvrfd < 0) {
fprintf(stderr, "Failed to open DVR device\n");
exit(1);
}
if (buffer_size > 0)
{
int res = dvbdemux_set_buffer(dvrfd, buffer_size);
if (res < 0) {
fprintf(stderr, "Failed to set ring buffer size\n");
exit(1);
}
}
Regardless of what is implemented or not, would that be correct?
Andrea
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Help using DMX_SET_BUFFER_SIZE
On Sat, Mar 01, 2008 at 12:20:05AM +, Andrea wrote:
> Hi,
>
> I've tried to add an extra argument to gnutv to set the size of the
> dvb_ringbuffer via
> DMX_SET_BUFFER_SIZE.
>
> I have not really understood the difference between dvr and demux.
> It seems that gnutv uses the dvr to read from the DVB card and then copies
> the content to a file.
>
> I call
>
> int dvbdemux_set_buffer(int fd, int bufsize)
> {
> return ioctl(fd, DMX_SET_BUFFER_SIZE, bufsize);
> }
>
> on the dvr (I think), but it does not make much of a change. The ioctl call
> returns success.
> I've printed a lot of debug output (adding a few dprintk) and this is what I
> see when I run gnutv.
> Now, I set the buffer to 1024 * 1024 which is nowhere in the log.
> I cannot see in the log the 2 functions (demux and dvr) handling this ioctl
> call:
> dvb_demux_do_ioctl and dvb_dvr_do_ioctl (I've added some printk as well).
In 2.6.25-rc3 the dvr kernel side looks like this:
1015 switch (cmd) {
1016 case DMX_SET_BUFFER_SIZE:
1017 // FIXME: implement
1018 ret = 0;
1019 break;
i guess its clear why it doesnt make a difference ;)
Flo
--
Florian Lohoff [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
signature.asc
Description: Digital signature
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [v4l-dvb-maintainer] [PATCH] DMX_OUT_TSDEMUX_TAP: record two streams from same mux, resend
Peter Hartley wrote: > [Resending patch with proper signed-off-by and updated description, but > otherwise unchanged] Dear Mauro, please apply Peters patch, which allows to utilize the kernel demux while recording TS. Regards, Andreas ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
