Hi,
I wrote a patch to Steve Toth hvr3000 repository, so my FlyDVB Trio can use multiple frontend.
So I get:
/dev/dvb/adapter0/demux0
/dev/dvb/adapter0/demux1
/dev/dvb/adapter0/dvr0
/dev/dvb/adapter0/dvr1
/dev/dvb/adapter0/frontend0
/dev/dvb/adapter0/frontend1
/dev/dvb/adapter0/net0
/dev/dvb/adapter0/net1
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.
Please can someone give me an help to wrote a patch for this issue?
Best Regards,
Eddi
Eddi wrote:
Hi,
I wrote a patch to Steve Toth hvr3000 repository, so my FlyDVB Trio can use multiple frontend.
So I get:
/dev/dvb/adapter0/demux0
/dev/dvb/adapter0/demux1
/dev/dvb/adapter0/dvr0
/dev/dvb/adapter0/dvr1
/dev/dvb/adapter0/frontend0
/dev/dvb/adapter0/frontend1
/dev/dvb/adapter0/net0
/dev/dvb/adapter0/net1
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
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.
Best regards
Eddi
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
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.
I'm very happy if you could try to make such patch.
I can test that patch, and make few adjustment, since I think you can't really test it.
Thank you for your support
Best Regards,
Eddi
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
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
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
So what do you think should be the right way?
Best Regards
Edddi
-----Messaggio originale----- Da: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] 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
Eddi wrote:
So what do you think should be the right way?
I haven't decided yet how to do that.
I just wanted to let you know that deleting the cDvbDevice is not the way to go - especially if you delete it from within one of its own member functions ;-) It's no wonder your patched version fails it you saw off the branch you're sitting on.
Klaus
-----Messaggio originale----- Da: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] 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
Ok, I hope that what I have done, may describe the algorithm that I think may be necessary to get multiple frontend working. I know that the solution I choose are not the best and right, I'm not a c++ programmer!
The only solution I found to close all file descriptors and /dev/dvb/adapter0/frontend0 was to add the close fd_frontend to the dvb device destructor.
Eddi
-----Messaggio originale----- Da: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Per conto di Klaus Schmidinger Inviato: venerdì 9 febbraio 2007 13.43 A: vdr@linuxtv.org Oggetto: Re: [PATCH]: [vdr] VDR & Multiple frontends
Eddi wrote:
So what do you think should be the right way?
I haven't decided yet how to do that.
I just wanted to let you know that deleting the cDvbDevice is not the way to go - especially if you delete it from within one of its own member functions ;-) It's no wonder your patched version fails it you saw off the branch you're sitting on.
Klaus
-----Messaggio originale----- Da: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] 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
Hi, I've made another patch to vdr 1.4.5.
Now I have used your suggestion, and the patch seems to be stable.
http://tux.dpeddi.com/lr319sta/downloads/vdr_1.4.5_eddi-multiple-frontend_v2 .patch
At the moment I've tested it only with live view.
Klaus, please look at this patch again and tell me what do you think.
However I'm sure that what I'm done can be optimized.
Best regards
Eddi
-----Messaggio originale----- Da: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Per conto di Eddi Inviato: venerdì 9 febbraio 2007 14.28 A: 'VDR Mailing List' Oggetto: R: [PATCH]: [vdr] VDR & Multiple frontends
Ok, I hope that what I have done, may describe the algorithm that I think may be necessary to get multiple frontend working. I know that the solution I choose are not the best and right, I'm not a c++ programmer!
The only solution I found to close all file descriptors and /dev/dvb/adapter0/frontend0 was to add the close fd_frontend to the dvb device destructor.
Eddi
-----Messaggio originale----- Da: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Per conto
di
Klaus Schmidinger Inviato: venerdì 9 febbraio 2007 13.43 A: vdr@linuxtv.org Oggetto: Re: [PATCH]: [vdr] VDR & Multiple frontends
Eddi wrote:
So what do you think should be the right way?
I haven't decided yet how to do that.
I just wanted to let you know that deleting the cDvbDevice is not the way to go - especially if you delete it from within one of its own member functions ;-) It's no wonder your patched version fails it you saw off the branch you're sitting on.
Klaus
-----Messaggio originale----- Da: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] 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
Hi,
To finishing adding multiple frontend support, I need a function to know inside dvbdevice.c if recording is in progress.
Is there a function ready?
Best Regards,
Eddi
Eddi wrote:
Hi,
To finishing adding multiple frontend support, I need a function to know inside dvbdevice.c if recording is in progress.
Is there a function ready?
That would be cDevice::Receiving().
Klaus
The patch that enable multiple frontend with shared bus, should be finished and on my pc it seems to be stable enough.
http://tux.dpeddi.com/lr319sta/downloads/vdr_1.4.5_eddi-multiple-frontend_v5 .patch
Now the patch don't switch frontend, is recording in progress.
Best Regards,
Eddi
-----Messaggio originale----- Da: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Per conto di Eddi Inviato: sabato 10 febbraio 2007 11.17 A: 'VDR Mailing List' Oggetto: R: [PATCH]: [vdr] VDR & Multiple frontends, another try
Hi, I've made another patch to vdr 1.4.5.
Now I have used your suggestion, and the patch seems to be stable.
http://tux.dpeddi.com/lr319sta/downloads/vdr_1.4.5_eddi-multiple- frontend_v2 .patch
At the moment I've tested it only with live view.
Klaus, please look at this patch again and tell me what do you think.
However I'm sure that what I'm done can be optimized.
Best regards
Eddi
-----Messaggio originale----- Da: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Per conto
di
Eddi Inviato: venerdì 9 febbraio 2007 14.28 A: 'VDR Mailing List' Oggetto: R: [PATCH]: [vdr] VDR & Multiple frontends
Ok, I hope that what I have done, may describe the algorithm that I
think
may be necessary to get multiple frontend working. I know that the solution I choose are not the best and right, I'm not a c++ programmer!
The only solution I found to close all file descriptors and /dev/dvb/adapter0/frontend0 was to add the close fd_frontend to the dvb device destructor.
Eddi
-----Messaggio originale----- Da: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Per conto
di
Klaus Schmidinger Inviato: venerdì 9 febbraio 2007 13.43 A: vdr@linuxtv.org Oggetto: Re: [PATCH]: [vdr] VDR & Multiple frontends
Eddi wrote:
So what do you think should be the right way?
I haven't decided yet how to do that.
I just wanted to let you know that deleting the cDvbDevice is not the way to go - especially if you delete it from within one of its own member functions ;-) It's no wonder your patched version fails it you saw off the branch you're sitting on.
Klaus
-----Messaggio originale----- Da: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] 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
Hi,
Klaus, any news about support for multiple frontends?
What about integrating my patch in 1.5.x?
Regards,
Eddi
-----Messaggio originale----- Da: eddi at depieri.net (Eddi) [mailto:eddi at depieri.net (Eddi)] Inviato: 24 February 2007 12:48 Oggetto: [PATCH]: [vdr] VDR & Multiple frontends (finished)
The patch that enable multiple frontend with shared bus, should be finished and on my pc it seems to be stable enough.
http://tux.dpeddi.com/lr319sta/downloads/vdr_1.4.5_eddi-multiple- frontend_v5 .patch
Now the patch don't switch frontend, is recording in progress.
Best Regards,
Eddi
-----Messaggio originale----- Da: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Per conto
di
Eddi Inviato: sabato 10 febbraio 2007 11.17 A: 'VDR Mailing List' Oggetto: R: [PATCH]: [vdr] VDR & Multiple frontends, another try
Hi, I've made another patch to vdr 1.4.5.
Now I have used your suggestion, and the patch seems to be stable.
http://tux.dpeddi.com/lr319sta/downloads/vdr_1.4.5_eddi-multiple- frontend_v2 .patch
At the moment I've tested it only with live view.
Klaus, please look at this patch again and tell me what do you think.
However I'm sure that what I'm done can be optimized.
Best regards
Eddi
-----Messaggio originale----- Da: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Per conto
di
Eddi Inviato: venerd? 9 febbraio 2007 14.28 A: 'VDR Mailing List' Oggetto: R: [PATCH]: [vdr] VDR & Multiple frontends
Ok, I hope that what I have done, may describe the algorithm that I
think
may be necessary to get multiple frontend working. I know that the solution I choose are not the best and right, I'm not
a
c++ programmer!
The only solution I found to close all file descriptors and /dev/dvb/adapter0/frontend0 was to add the close fd_frontend to the
dvb
device destructor.
Eddi
-----Messaggio originale----- Da: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Per
conto
di
Klaus Schmidinger Inviato: venerd? 9 febbraio 2007 13.43 A: vdr@linuxtv.org Oggetto: Re: [PATCH]: [vdr] VDR & Multiple frontends
Eddi wrote:
So what do you think should be the right way?
I haven't decided yet how to do that.
I just wanted to let you know that deleting the cDvbDevice is not the way to go - especially if you delete it from within one of its own member functions ;-) It's no wonder your patched version fails it you saw off the branch you're sitting on.
Klaus
-----Messaggio originale----- Da: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] 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
On 08/19/07 22:02, Eddi wrote:
Hi,
Klaus, any news about support for multiple frontends?
What about integrating my patch in 1.5.x?
Well, to be absolutely honest, this is still dangling in my inbox and I have so many other things to do that I just can't seem to find the time right now.
Klaus
Hi,
I can't figure out if finally you integrated MFE support.
Regards
Eddi
On Fri, Aug 24, 2007 at 4:20 PM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 08/19/07 22:02, Eddi wrote:
Hi,
Klaus, any news about support for multiple frontends?
What about integrating my patch in 1.5.x?
Well, to be absolutely honest, this is still dangling in my inbox and I have so many other things to do that I just can't seem to find the time right now.
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 25.07.2015 18:12, Eddi De Pieri wrote:
Hi,
I can't figure out if finally you integrated MFE support.
VDR can handle adapters with multiple frontends (in which case each adapter/frontend combo is set up as a separate device, which all can be used in parallel), as well as frontends that can provide different delivery systems (in which case this is one single device that can support one delivery system at a time).
Klaus
On Fri, Aug 24, 2007 at 4:20 PM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 08/19/07 22:02, Eddi wrote:
Hi,
Klaus, any news about support for multiple frontends?
What about integrating my patch in 1.5.x?
Well, to be absolutely honest, this is still dangling in my inbox and I have so many other things to do that I just can't seem to find the time right now.
Klaus
So, still not support with device with multiple frontend on a shared bus (like hvr3000/4000 life view trio and so on) Which expose /dev/dvb/adapter0/frontend0 and frontend1 that can't be use at the same time.
Regards, Eddi Il 25/lug/2015 18:31, "Klaus Schmidinger" Klaus.Schmidinger@tvdr.de ha scritto:
On 25.07.2015 18:12, Eddi De Pieri wrote:
Hi,
I can't figure out if finally you integrated MFE support.
VDR can handle adapters with multiple frontends (in which case each adapter/frontend combo is set up as a separate device, which all can be used in parallel), as well as frontends that can provide different delivery systems (in which case this is one single device that can support one delivery system at a time).
Klaus
On Fri, Aug 24, 2007 at 4:20 PM, Klaus Schmidinger
Klaus.Schmidinger@cadsoft.de wrote:
On 08/19/07 22:02, Eddi wrote:
Hi,
Klaus, any news about support for multiple frontends?
What about integrating my patch in 1.5.x?
Well, to be absolutely honest, this is still dangling in my inbox and I have so many other things to do that I just can't seem to find the time right now.
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 25.07.2015 22:05, Eddi De Pieri wrote:
So, still not support with device with multiple frontend on a shared bus (like hvr3000/4000 life view trio and so on) Which expose /dev/dvb/adapter0/frontend0 and frontend1 that can't be use at the same time.
AFAIK there is no API that would allow an application to determine whether two frontends can be used at the same time or not. There was some discussion back when this was implemented, and the bottom line was that if multiple frontends of the same adapter can be used simultaneously, they shall be separate files (frontend0, frontend1, ...), and if they can only be used one at a time, they shall be a single frontend0 which shall be queried with DTV_ENUM_DELSYS.
I suggest you contact the author of the driver for this device and ask him/her to implement this according to DVB API 5.5 or higher.
Klaus
Il 25/lug/2015 18:31, "Klaus Schmidinger" <Klaus.Schmidinger@tvdr.de mailto:Klaus.Schmidinger@tvdr.de> ha scritto:
On 25.07.2015 18 <tel:25.07.2015%2018>:12, Eddi De Pieri wrote: Hi, I can't figure out if finally you integrated MFE support. VDR can handle adapters with multiple frontends (in which case each adapter/frontend combo is set up as a separate device, which all can be used in parallel), as well as frontends that can provide different delivery systems (in which case this is one single device that can support one delivery system at a time). Klaus On Fri, Aug 24, 2007 at 4:20 PM, Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de <mailto:Klaus.Schmidinger@cadsoft.de>> wrote: On 08/19/07 22:02, Eddi wrote: Hi, Klaus, any news about support for multiple frontends? What about integrating my patch in 1.5.x? Well, to be absolutely honest, this is still dangling in my inbox and I have so many other things to do that I just can't seem to find the time right now. Klaus
-
Eddi -
Eddi De Pieri
-
Klaus Schmidinger -
Klaus Schmidinger