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@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of Jose Alberto Reguero Sent: 21. helmikuuta 2006 17:30 To: VDR Mailing List Subject: Re: [vdr] 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@exomi.com 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@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
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@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of Jose Alberto Reguero Sent: 21. helmikuuta 2006 17:30 To: VDR Mailing List Subject: Re: [vdr] 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@exomi.com 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@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 mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr