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
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.
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
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
On Mon, 20 Feb 2006 23:03:27 +0200 "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.
I recall something like this when I first tried streamdev with a VDR client. I "fixed" the problem by forcing each DVB card to a specific mux in channels.conf. Somehow I thought this wasn't a problem with HTTP streaming, but that doesn't make sense, so I probably remember it wrong. I've also kept the forced settings for other reasons, which keeps me from experiencing these annoying switches.
--Niko
Niko Mikkila wrote:
On Mon, 20 Feb 2006 23:03:27 +0200 "Jukka Vaisanen" Jukka.Vaisanen@exomi.com wrote:
- 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.
I recall something like this when I first tried streamdev with a VDR client. I "fixed" the problem by forcing each DVB card to a specific mux in channels.conf. Somehow I thought this wasn't a problem with HTTP streaming, but that doesn't make sense, so I probably remember it wrong. I've also kept the forced settings for other reasons, which keeps me from experiencing these annoying switches.
And I worked-around this bug by changing the transfer-mode primary limit. This however has the side effect that *any* channel change to a non-tuned channel (i.e. the mux is not already tuned in any of the cards) will require an additional DVB card as the tuner of the current channel is not regarded as free when selecting the card to tune to the new channel. I have no problem with that, as I have 3 cards and 3 muxes.