El Martes, 21 de Febrero de 2006 20:35, Jukka Vaisanen escribi?:
> 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..?
If a card is used for a recording, cDevice::GetDevice don't take it.
Jose Alberto
>
> 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
>
> _______________________________________________
> vdr mailing list
> vdr@xxxxxxxxxxx
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
