Ok, first of all this patch Works For Me. Second, either I'm much too tired to be looking at code or I'm somehow missing the entire channel/device allocation mechanism. I interpret the following happens in the code:
- Find a device that could handle the requested channel to be streamed with:
device = cDevice::GetDevice(Channel, Priority);
- If we don't find a device or the found device is ActualDevice and we can't suspend it..
if (!device || (device == cDevice::ActualDevice()
&& !cSuspendCtl::IsActive()
&& StreamdevServerSetup.SuspendMode != smAlways)) {
... Then we go into the special section where we try to find a device by bumping the live tv to another card.
It seems to me that we should never be getting to that section AT ALL and cDevice::GetDevice(Channel, Priority) should not give us a device that == cDevice::ActualDevice() since there is an identical budget card free the live tv is on another mux. The fact that this patch works seems to rely on this section:
for (int i = 0; i < cDevice::NumDevices(); ++i) {
cDevice *dev = cDevice::GetDevice(i);
if (dev->ProvidesChannel(current, 0) && dev != device) {
newdev = dev;
break;
}
... where we are trying to find a new device to handle live TV. And in this case instead of relying on cDevice::GetDevice(Channel, Priority) we loop manually through all the devices to see if some other device provides the current live tv channel. If we find it, we either:
- (original code) switch live tv to it
- (Jose's patch) use that device for the channel to be streamed
In both cases I think if that card was already being used for a recording, that recording would get bumped off regardless of any priorities etc. Smells ugly..?
First, am I reading this wrong or is the culprit really inside cDevice::GetDevice(...) where it picks the wrong card right at the top of this function?
I guess my easiest way out would be to get a third DVB-T card and hard-code each card to a specific MUX but that would cost me 78 euros PLUS this thing would nag me forever ;)
- Jukka Vaisanen
-----Original Message-----
From: vdr-bounces@xxxxxxxxxxx [mailto:vdr-bounces@xxxxxxxxxxx] On Behalf Of Jose Alberto Reguero
Sent: 21. helmikuuta 2006 17:30
To: VDR Mailing List
Subject: Re: Streamdev HTTP attach not grabbing a free DVB card?
El Martes, 21 de Febrero de 2006 06:15, BRUNETON B?ranger escribi?:
> Hi,
>
> I've the same issue on my setup and haven't fix it.
> First, you can try a various combinaison of streamdev option(offer
> suspend,always suspend...)
>
> Or try to recompile streamdev with DEBUG = 1 and check in the log file if
> you see this message "Found device for live tv"
> If you see it that means that your streamdev configuration is ok but
> streamdev is unable to reallocate live tv on a free dvb card.
> and the following method "connection.c:
> cServerConnection::GetDevice" is guilty.
I solved this changin in cServerConnection::GetDevice:
if (newdev == NULL || newdev == device)
// no suitable device to continue live TV,
giving up...
device = NULL;
else
newdev->SwitchChannel(current, true);
by:
if (newdev == NULL || newdev == device)
// no suitable device to continue live TV,
giving up...
device = NULL;
else
// newdev->SwitchChannel(current, true);
device = newdev;
Jose Alberto
>
> A dirty solution would to never allocate the primary card for streaming.
>
> I will check deeper in the source code and go back to you if I found
> interesting things.
>
> Regards
>
> On 2/20/06, Jukka Vaisanen <Jukka.Vaisanen@xxxxxxxxx> wrote:
> > I recently moved on to the wonderful world of multiple DVB-T cards in my
> > VDR and also set up streamdev-server for use with VLC for
> > HTTP/PES-streams to a remote PC. However I ran into a problem with how
> > streamdev and my primary output coexist.
> >
> > Software:
> > - vdr-1.3.43
> > - DVB drivers from 2.6.15-gentoo-r1 kernel
> > - dxr3-0.2.5 plugin
> > - Latest streamdev-cvs (Jan 20)
> >
> > Hardware:
> > - 2x Airstar2 budget DVB-T (FlexCopIIb)
> > - DXR3 (Hollywood+)
> > - P3/800 + 1.5GB RAM
> >
> > And how / what happens:
> >
> > - I restart VDR "fresh" with only dxr3 and streamdev plugin loaded
> > - I switch my primary output (dxr3) to the preferred channel, works fine
> > - I connect via the streamdev HTTP server to a channel which is on
> > another mux and my dxr3 output switches to the first channel in that
> > mux. Apparently the streamdev is somehow grabbing the same budget card
> > and forcing the mux switch.
> > - If I disconnect the streamdev client and reattach it to yet another
> > mux the dxr3 changes channels again. It "follows" my streamdev actions.
> > - After a few channel switches the dxr3 video freezes into a still frame
> > but I can still attach to streamdev via HTTP to any channel/mux without
> > any problems.
> > - If I now switch a channel on the dxr3 output to anything on the same
> > mux as the streamdev, it works fine but the picture freezes again every
> > time I switch to another mux from the streamdev.
> > - If I switch the dxr3 channel to another mux while the streamdev HTTP
> > is serving something, the entire problem goes away. After this I can
> > independently use dxr3 and the streamdev without any conflicts until the
> > next VDR restart.
> >
> > My not-so-educated guess is that the streamdev receiver device is using
> > GetDevice to find a tuner and it manages to magically grab the primary
> > device every time whether it's in use or not. If the dxr3 is using the
> > primary device, it gets thrown over to the other mux by virtue of using
> > that tuner. If I change the channel on the dxr3 while the streamdev is
> > connected, the dxr3 gets assigned to the other DVB card and from then on
> > they both coexist peacefully.
> >
> > This is a minor nuisance in the sense that I can live with my live tv
> > being knocked onto another channel now and then but what I'm worried
> > about is recordings.. If I have a recording on the primary device and
> > the HTTP streamdev client connects, the recording might get cut off or
> > switch to the wrong channel.
> >
> > I did a bit of source-code surfing to try and understand the mechanism
> > by which streamdev gets a tuner device but I couldn't really identify
> > any clearly faulty logic. I'd suppose that others would have run into
> > this issue already but mailing list search and Google turned up nothing
> > really relevant. Since this is easily reproducible here and I'm running
> > pretty much latest everything here, I could try and patch this up if
> > someone points me in the right direction.
> >
> > - Jukka Vaisanen
> >
> >
> > _______________________________________________
> > vdr mailing list
> > vdr@xxxxxxxxxxx
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
