R: R: [PATCH] R: R: [vdr] VDR Multiple frontends
So what do you think should be the right way? Best Regards Edddi -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Klaus Schmidinger Inviato: venerdì 9 febbraio 2007 8.27 A: vdr@linuxtv.org Oggetto: Re: R: [PATCH] R: R: [vdr] VDR Multiple frontends Eddi wrote: I need help This is why sometimes hangs after my patch... On ProvidesChannel I delete the cDvbDevice and i make it again. Deleting the cDvbDevice is definitely the wrong way to do this. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
R: [PATCH] R: R: [vdr] VDR Multiple frontends
I need help This is why sometimes hangs after my patch... On ProvidesChannel I delete the cDvbDevice and i make it again. In that few nanoseconds someone try to access the structure deleted without waiting for proper allocation of new one. How to wait ultil all needed thread are ready? Best regards, Eddi ==4215== Thread 1: ==4215== Syscall param ioctl(arg) contains uninitialised byte(s) ==4215==at 0x4000792: (within /lib/ld-2.3.6.so) ==4215==by 0x8094782: cDevice::DelPid(int, cDevice::ePidType) (device.c:491) ==4215==by 0x8094888: cDevice::Detach(cReceiver*) (device.c:1297) ==4215==by 0x80CEC7B: cReceiver::Detach() (receiver.c:58) ==4215==by 0x80FAE0B: cTransfer::~cTransfer() (transfer.c:27) ==4215==by 0x80FACBA: cTransferControl::~cTransferControl() (transfer.c:123) ==4215==by 0x80CC349: cControl::Shutdown() (player.c:94) ==4215==by 0x8094B9F: cDevice::SetChannel(cChannel const*, bool) (device.c:621) ==4215==by 0x8094E1A: cDevice::SwitchChannel(cChannel const*, bool) (device.c:576) ==4215==by 0x8085E0D: cChannels::SwitchTo(int) (channels.c:1024) ==4215==by 0x80AE950: cDisplayChannel::ProcessKey(eKeys) (menu.c:3343) ==4215==by 0x80FD167: main (vdr.c:1052) ==4215== Warning: noted but unhandled ioctl 0x6F2A with no size/direction hints ==4215==This could cause spurious value errors to appear. ==4215==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==4215== Warning: noted but unhandled ioctl 0x6F2A with no size/direction hints ==4215==This could cause spurious value errors to appear. ==4215==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==4215== Warning: invalid file descriptor -1 in syscall close() ==4215== Warning: invalid file descriptor -1 in syscall close() ==4215== Warning: invalid file descriptor -1 in syscall close() ==4215== Warning: noted but unhandled ioctl 0x6F43 with no size/direction hints ==4215==This could cause spurious value errors to appear. ==4215==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==4215== ==4215== Invalid read of size 1 ==4215==at 0x401D248: strlen (mc_replace_strmem.c:246) ==4215==by 0x41B9FD4: vfprintf (in /lib/tls/i686/cmov/libc-2.3.6.so) ==4215==by 0x424256D: vsyslog (in /lib/tls/i686/cmov/libc-2.3.6.so) ==4215==by 0x80F9082: syslog_with_tid(int, char const*, ...) (tools.c:41) ==4215==by 0x809ADA7: cDvbDevice::ProvidesChannel(cChannel const*, int, bool*) const (dvbdevice.c:828) ==4215==by 0x8093330: cDevice::GetDevice(cChannel const*, int, bool*) (device.c:300) ==4215==by 0x8094BEC: cDevice::SetChannel(cChannel const*, bool) (device.c:638) ==4215==by 0x8094E1A: cDevice::SwitchChannel(cChannel const*, bool) (device.c:576) ==4215==by 0x8085E0D: cChannels::SwitchTo(int) (channels.c:1024) ==4215==by 0x80AE950: cDisplayChannel::ProcessKey(eKeys) (menu.c:3343) ==4215==by 0x80FD167: main (vdr.c:1052) ==4215== Address 0x1 is not stack'd, malloc'd or (recently) free'd ==4215== ==4215== Process terminating with default action of signal 11 (SIGSEGV) ==4215== Access not within mapped region at address 0x1 ==4215==at 0x401D248: strlen (mc_replace_strmem.c:246) ==4215==by 0x41B9FD4: vfprintf (in /lib/tls/i686/cmov/libc-2.3.6.so) ==4215==by 0x424256D: vsyslog (in /lib/tls/i686/cmov/libc-2.3.6.so) ==4215==by 0x80F9082: syslog_with_tid(int, char const*, ...) (tools.c:41) ==4215==by 0x809ADA7: cDvbDevice::ProvidesChannel(cChannel const*, int, bool*) const (dvbdevice.c:828) ==4215==by 0x8093330: cDevice::GetDevice(cChannel const*, int, bool*) (device.c:300) ==4215==by 0x8094BEC: cDevice::SetChannel(cChannel const*, bool) (device.c:638) ==4215==by 0x8094E1A: cDevice::SwitchChannel(cChannel const*, bool) (device.c:576) ==4215==by 0x8085E0D: cChannels::SwitchTo(int) (channels.c:1024) ==4215==by 0x80AE950: cDisplayChannel::ProcessKey(eKeys) (menu.c:3343) ==4215==by 0x80FD167: main (vdr.c:1052) ==4215== -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Eddi Inviato: giovedì 8 febbraio 2007 1.22 A: 'VDR Mailing List' Oggetto: [PATCH] R: R: [vdr] VDR Multiple frontends The patch is ready and available as attachment to this mail and at http://tux.dpeddi.com/lr319sta/downloads/vdr_1.4.5_eddi-multiple- frontend.pa tch Card detection should work in all environment, and the patch should be transparent in environment with adapters that have a single tuner or adapter that provide a bus for each tuner. In this case the frontend appear as a VDR device. At the moment, sometime channel change works and sometime fails, I suppose is due to the time thread needs to close. Can someone do a regression test with my patch applied? I need help to solve this? I have to use valgring? Best Regards, Eddi -Messaggio originale- Da: [EMAIL PROTECTED] [mailto
[PATCH] R: R: [vdr] VDR Multiple frontends
The patch is ready and available as attachment to this mail and at http://tux.dpeddi.com/lr319sta/downloads/vdr_1.4.5_eddi-multiple-frontend.pa tch Card detection should work in all environment, and the patch should be transparent in environment with adapters that have a single tuner or adapter that provide a bus for each tuner. In this case the frontend appear as a VDR device. At the moment, sometime channel change works and sometime fails, I suppose is due to the time thread needs to close. Can someone do a regression test with my patch applied? I need help to solve this? I have to use valgring? Best Regards, Eddi -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Eddi Inviato: giovedì 8 febbraio 2007 0.34 A: 'VDR Mailing List' Oggetto: R: R: [vdr] VDR Multiple frontends Since I don't get any news you, I'm working on implementing this. I had to modify these files: device.c device.h dvbdevice.c dvbdevice.h At the moment I don't get any image yet from second frontend yet, but changing channel I get EPG from second tuner. I hope in the next day sto submit a patch Best Regards, Eddi -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Klaus Schmidinger Inviato: domenica 10 dicembre 2006 11.14 A: vdr@linuxtv.org Oggetto: Re: R: [vdr] VDR Multiple frontends Eddi wrote: Eddi wrote: Hi, I wrote a patch to Steve Toth hvr3000 repository, so my FlyDVB Trio can use multiple frontend. The bus of the two frontend is shared, isn't possible to get access to both frontend simultaneously, so I get an -EBUSY error by trying accessing frontend1 if frontend0 is in use. VDR doesn't support yet the second frontend, and it try to get exclusive access on both frontend on start, so the second frontend is inusabile. Vdr should probe for multiple frontend at start, and access frontend only on channel change. Wouldn't it be better to hide this deficiency in the driver? Klaus Actually it seems that on Hybrid card is and will be quite common that multiple frontend share a single bus. Linuxtv API tell that a driver may offer frontendN nodes www.linuxtv.org/download/linux-dvb-api-1.0.0.pdf that vdr don't support I think is impossibile, to solve by driver, since switching between frontend happened by opening the frontend/demux device. VDR try access to frontend on start (actually it doesn't start multiple fe on same adapter, so I solved with symlink), and open all the frontend. If open fails it refuse to use the frontend. If open with success, it start N thread as many as the number of adapter/frontend. I don't understand what you mean for deficiency, if you mean the EBUSY, yes I could remove it, but it doesn't solve since with two tread open I should get a ping-pong between the two frontend so I can't get any image. If you mean for deficiency the two frontend on the same adapter, is logically correct, and is a deficiency that vdr doesn't supporti t. Since I like VDR, I'd like it support this. I've gone through the LinuxDVB API description regarding the frontend again and apparently it is documented that multiple frontends on the same adapter can't be open in read/write mode at the same time (so the deficiency is actually on VDR's side ;-). Well, so VDR could open them in read-only mode first and switch one of them to read/write mode shortly whenever it does a tuning operation, and go back to read-only after that. It would also have to switch to read/write shortly whenever it reads a frontend event with ioctl(FE_GET_EVENT). With such modifications it should be possible to make VDR support a multiple frontend adapter. In order to set up the necessary VDR devices, cDvbDevice::Initialize() would also have to be enhanced to probe for multiple frontends on the same adapter. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr vdr_1.4.5_eddi-multiple-frontend.patch Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
