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: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] 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: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] 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: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] 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