Re: [vdr] Set/Increase pause while playing live tv
Unfortunately neighter i have a second usb root hub on my mainboard nor a free pci slot for an usb card. I solved my problem by storing the recordings on a SATA hard disc. 2013/8/12 André Weidemann andre.weidem...@web.de Hi Rainer, On 12.08.2013 16:28, Rainer Blickle wrote: Hi Folks, i have the following setup: - vdr 1.7.36 - pvr350-device with pvrinput- and pvr350-plugin - a TechnoTrend (PCI) DVB-C device - a Sundtek DVB-C USB stick with this setup i have the following problem: While watching live tv (of course in transfer mode) everything is ok. When recording and watching with my pci dvb device everything is still ok. When watching and recording with the usb stick (video directory is on an usb hard disk), i am getting artifacts and hanging pictures (the picture hangs for less than 0.2...0.3 seconds). The recordings on the hard disks are ok. Now i want to increase the delay from receiving to displaying the dvb-stream = increase the pause while playing live tv. I havn't found a way neigher in vdr nor in pvr350 ? Any idea ? I'd assume your problem results from both devices being attached to the same USB Root HUB. If your mainboard has more then 2 USB ports try to switch devices to different ports. If possible try to record to an internal HDD or a NAS-Filer. See if this will cure the problem. André ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Set/Increase pause while playing live tv
Hi Folks, i have the following setup: - vdr 1.7.36 - pvr350-device with pvrinput- and pvr350-plugin - a TechnoTrend (PCI) DVB-C device - a Sundtek DVB-C USB stick with this setup i have the following problem: While watching live tv (of course in transfer mode) everything is ok. When recording and watching with my pci dvb device everything is still ok. When watching and recording with the usb stick (video directory is on an usb hard disk), i am getting artifacts and hanging pictures (the picture hangs for less than 0.2...0.3 seconds). The recordings on the hard disks are ok. Now i want to increase the delay from receiving to displaying the dvb-stream = increase the pause while playing live tv. I havn't found a way neigher in vdr nor in pvr350 ? Any idea ? Reagards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] inputlirc with devices referenced by /dev/input/by-id/...
i created a workaround with the following S19... startup script:
#!/bin/sh
cat /tmp/RecreateLircConfig.java DELIM
import java.nio.file.*;
public class RecreateLircConfig {
public static void main(String[] args) throws Exception {
Path path1 = Paths.get(/dev/input/by-id/usb-05a4_9881-event-kbd);
Path path2 =
Paths.get(/dev/input/by-id/usb-05a4_9881-if01-event-mouse);
System.out.println(# Options to be passed to inputlirc.);
System.out.printf(EVENTS=\%s %s\%n, path1.toRealPath(),
path2.toRealPath());
System.out.println(OPTIONS=\-g -m 0 -c\);
}
}
DELIM
javac -d /tmp /tmp/RecreateLircConfig.java
#java -cp /tmp RecreateLircConfig
java -cp /tmp RecreateLircConfig /etc/default/inputlirc
to execute the script, the deb openjdk-7-jdk is needed
2013/7/28 Peter Münster pmli...@free.fr
On Sat, Jul 27 2013, Rainer Blickle wrote:
inputlirc starts and works as expected. unfortunately the device
(event2/3)
changes from reboot to reboot.
Hi,
There is this function in my run-vdr script, perhaps it can help:
--8---cut here---start-8---
reload-dvb()
{
killall irxevent lircd
sleep 1
killall -9 irxevent lircd
modprobe -r $DVB_DRIVERS
sleep 1
for i in $DVB_DRIVERS; do modprobe $i; done
sleep 3
EV=`ir-keytable 21 | grep -B1 tevii | \
sed -nr 's,^.*/dev/input/(event.).*$,\1,p'`
ln -sf $EV $IR
chmod 644 $IR
sleep 3
lircd -Hdevinput -d$IR
sleep 1
irxevent -d ~vdr/.lircrc
}
--8---cut here---end---8---
--
Peter
___
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] inputlirc with devices referenced by /dev/input/by-id/...
Hi, i have the following problem: With Ubuntu 12.04 inputlirc doesn't work anymore when using the symlics under /dev/input/by-id/... I have a Hama IR Remote, the symlinks for the remote are: /dev/input/by-id/usb-05a4_9881-event-kbd - ../event2 /dev/input/by-id/usb-05a4_9881-if01-event-mouse - ../event3 When using this links in /etc/default/inputlirc like the following ## EVENTS=/dev/input/by-id/usb-05a4_9881* OPTIONS=-g -m 0 -c ## then inputlirc doesn't start. With the following content: ## EVENTS=/dev/input/event2 /dev/input/event3 OPTIONS=-g -m 0 -c ## inputlirc starts and works as expected. unfortunately the device (event2/3) changes from reboot to reboot. The upper version of the config (with by-id) has been worked under ubuntu 10.10 without any problem. I have tried to create static device names with the manual under http://wiki.xbmc.org/index.php?title=HOW-TO:Configure_VRC-1100_remote_for_Ubuntu;, but it didn't work. after restarting udev, there was no device /dev/input/irremote0 is it a known bug that lirc doesn't work with by-id device names ? Have any other the same problem ? Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Missing /dev/fb for pvr350
Hi folks, i like to re-setup my vdr with ubuntu 12.04. The Plugin pvr350 cannot find the framebuffer. I have a device /dev/fb0, but it seems that this is the framebuffer of my tv-out of my mother board. When booting my old ubuntu 10.10, there are two framebuffer devices (fb0 and fb1). can anybody give me a clue why there is no frame buffer on my system for the pvr350 device ? Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Missing /dev/fb for pvr350
thx a lot, i have forgotten this module. now the pvr350 is working 2013/7/25 Lars Hanisch d...@flensrocker.de Hi, Am 25.07.2013 13:22, schrieb Rainer Blickle: Hi folks, i like to re-setup my vdr with ubuntu 12.04. The Plugin pvr350 cannot find the framebuffer. I have a device /dev/fb0, but it seems that this is the framebuffer of my tv-out of my mother board. When booting my old ubuntu 10.10, there are two framebuffer devices (fb0 and fb1). can anybody give me a clue why there is no frame buffer on my system for the pvr350 device ? Have you loaded ivtvfb? Lars. Regards, Rainer ___ 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
[vdr] Blocking svdrp with epgsearch-1.0.0
Hi, when running vdr with the epgsearch-1.0.0-plugin, i wasn't able to add epgdata via the pute-svdrp-command anymore. The svdrp-client seems to hang. With version epgsearch-0.9.25.beta17 there wasn't any problem. I can provide logs if someone tells me how. Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Blocking svdrp with epgsearch-1.0.0
I attached the logfile (with -v 3). I have taken a look on it, but nothing found. 2011/10/18 Christian Wieninger cwienin...@gmx.de: Hi Rainer, there were no significant changes in SVDRP handling between these versions. Did you set the correct (same as VDR) SVDRP port in epgsearchs setup? Please start epgsearch with the parameters -v 2 to generate an epgsearch.log file in epgsearchs configuration directory. cheers, Christian Am 18.10.2011 10:34, schrieb Rainer Blickle: Hi, when running vdr with the epgsearch-1.0.0-plugin, i wasn't able to add epgdata via the pute-svdrp-command anymore. The svdrp-client seems to hang. With version epgsearch-0.9.25.beta17 there wasn't any problem. I can provide logs if someone tells me how. Regards, Rainer ___ 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 epgsearch.log.tar.gz Description: GNU Zip compressed data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Streamdev to Streamdev with PVRInput card
Hi Rob, Can we put a check in streamdev to check if it's a pvrinput device and recall even if the frequency is the same? if i got it right the pvr devices hasn't to be retuned when switching the channel, but the externchannelswitch-script has to be executed. IMO it isn't a good idea to check for a pvrinput device in the softdevice server. These two plug-ins shouldn't have any dependencies. What you really need is that the external channel script gets executed If some constraints are fullfilled. My first idea is to extend the core vdr for a callback function which informs plugins about attaching/detaching receivers to/from a device and retuning of a device. With this informations a plugin could execute such externchannelswitch-scripts. But i think there is a problem that can't be fixed with this approach: When watch live tv on channel 1 and streamdev requests channel 2, vdr cannot handle this. Why? : vdr/streamdev doesn't know that 2 different pvrinput-devices are needed. Correct me if i'm wrong ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Streamdev to Streamdev with PVRInput card
Hi Rob,
for your (and only for your) problem there could be an easier solution:
When doing a channel switch streamdev queries for a new device while
the current device is still active (means receivers are attached to
the device). If no device could be found, streamdev detaches itself
and queries again.
If streamdev only queries for a device after detaching itself, the
pvrinput device gets closed and reopened again incl. executing the
channel switch thing. This is a really hack with some disadvantages
(e.g. like larger channel switch times in case of multiple channels in
a transponder) but i guess this would help.
I guess doing the following line should be sufficient in
server/connection.c (streamdev-version 0.5.0-CVS):
bool cServerConnection::ProvidesChannel(const cChannel *Channel, int Priority)
{
const cChannel *current =
Channels.GetByNumber(cDevice::CurrentChannel());
const cChannel *current =
Channels.GetByNumber(cDevice::CurrentChannel());
cDevice *device = CheckDlevice(Channel, Priority, false);
cDevice *device = 0;
if (!device || (device == cDevice::ActualDevice()
!cSuspendCtl::IsActive()
StreamdevServerSetup.SuspendMode != smAlways
current != NULL
!TRANSPONDER(Channel, current))) {
// mustn't switch actual device
// maybe a device would be free if THIS connection did turn off
its streams?
Detach();
device = CheckDevice(Channel, Priority, false);
Attach();
2011/6/9 Rainer Blickle rainer.blic...@googlemail.com:
Hi Rob,
Can we put a check in streamdev to check if it's a pvrinput device and
recall even if the frequency is the same?
if i got it right the pvr devices hasn't to be retuned when switching
the channel, but the externchannelswitch-script has to be executed.
IMO it isn't a good idea to check for a pvrinput device in the
softdevice server. These two plug-ins shouldn't have any dependencies.
What you really need is that the external channel script gets executed
If some constraints are fullfilled. My first idea is to extend the
core vdr for a callback function which informs plugins about
attaching/detaching receivers to/from a device and retuning of a
device.
With this informations a plugin could execute such
externchannelswitch-scripts.
But i think there is a problem that can't be fixed with this approach:
When watch live tv on channel 1 and streamdev requests channel 2, vdr
cannot handle this. Why? : vdr/streamdev doesn't know that 2 different
pvrinput-devices are needed. Correct me if i'm wrong
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Streamdev to Streamdev with PVRInput card
Hi Rob, I also don't think its a pvrinput problem because: streamdev doesn't query for a new device if the current and the next channel has the same transponder. This is checked via the following define: channels.h:#define ISTRANSPONDER(f1, f2) (abs((f1) - (f2)) 4) //XXX All the channels in channel.conf have the same frequency, so streamdev only changes the receivers but doesn't query for a device. I havent understand exactly what you are doing. Do you use an analogue input (like scart) of the pvr500 card and the channel switch script changes the channel of another device ? If so, i could imagine the frequency in channels.conf doesn't matter and you could simply modify the frequencies. Regards, Rainer 2011/6/8 Rob Davis r...@davis-family.info: I have a PVR500 with the PVRInput plugin running on my Backend. I am using an old Hauppauge FF DVB-s card just as a frontend on another low powered system in order to throw the PVRInput channels to the kitchen. On the backend it's all working, however, switching between channels doesn't quite work, as the streamdev server will give the client the same channel over and over again regardless of what it requested, unless the device changes (ie, if I go from /dev/video1 to /dev/video2 it'll change channel). how do you force switching the video device? i hacked device.c.. But don't tell anyone.. :-) An example of the channel list is: 2-WTTW PBS_Affiliate ntsc;WTTW:67250:TV|NTSC:V:0:301+101=2:300=@4:0:0:30020:32:32:0 3-WREX NBC_Affiliate ntsc;WREX:67250:TV|NTSC:V:0:301+101=2:300=@4:305:0:30030:48:48:0 4-WTVO ABC_Affiliate ntsc;WTVO:67250:TV|NTSC:V:0:301+101=2:300=@4:0:0:30040:64:64:0 5-WIFR CBS_Affiliate ntsc;WIFR:67250:TV|NTSC:V:0:301+101=2:300=@4:0:0:30050:80:80:0 6-WQRF Fox_Affiliate ntsc;WQRF:67250:TV|NTSC:V:0:301+101=2:300=@4:0:0:30060:96:96:0 But, obviously all on the same line. I think this is probably an issue with streamdev rather than pvrinput as it works with Vomp happily. I need it to detach and change channel in order to trigger the external channel changer script. pvrinput does its channel settings (this includes executing the externchannelswitch-script) inside its function OpenDvr() while the encoder is still stopped. The settings will only be done if the bool ChannelSettingsDone is false. This bool is always false at first plugin start. I guess this is the reason why your channel settings were done once: Jun 7 19:13:24 oac vdr: [8795] entering cPvrDevice::OpenDvr: Dvr of /dev/video1 (PVR500#1) is closed Jun 7 19:13:24 oac vdr: [8795] entering cPvrDevice::CloseDvr: Dvr of /dev/video1 (PVR500#1) is closed Jun 7 19:13:24 oac vdr: [8795] cPvrDevice::ResetBuffering(): tsBuffer prefill = 314524 for /dev/video1 (PVR500#1) Jun 7 19:13:24 oac vdr: [8795] channel is television. Jun 7 19:13:24 oac vdr: [8795] OpenDvr: calling /etc/vdr/plugins/pvrinput/externchannelswitch.sh 30040 4 1 67250 Jun 7 19:13:25 oac vdr: [8795] OpenDvr: returned from /etc/vdr/plugins/pvrinput/externchannelswitch.sh 30040 4 1 67250 Jun 7 19:13:25 oac vdr: [8795] OpenDvr: sleeping for 3 seconds... Jun 7 19:13:28 oac vdr: [8795] OpenDvr: waking up Jun 7 19:13:28 oac vdr: [8795] SetVBImode(525, 0) on /dev/video1 When leaving OpenDvr, the bool is set to true. It will only become false again during runtime, if vdr calls the pvrinput- function SetChannelDevice() and determines the needed settings. And this is your problem. There are no debug messages from pvrinput's SetChannelDevice() or ProvidesChannel(), so vdr never calls these pvrinput functions - although a channel switch for a pvrinput device is requested. But why? I have no idea. It works for you with vomp. It worked for me with streamdev when I tested this last year. But I had only streamdev-server running and used vlc to switch channels. Maybe a streamdev developer reads this and has an idea or can explain possible interactions between streamdev-client, vdr and a receiving device. I think this is a streamdev issue not a pvrinput one, as if I change from channel 5 to 6 on the remote streamdev client it will continue to display channel 5. If both my tuners are busy then it will lock to channel 5 on my backend if I test it with xineliboutput. Not lock to channel 6. I had a look at the http::// streamdev playlist settings and it sees different channel pids. Streamdev to vlc would work as it breaks the streamdev connection when you change channel. But streamdev-server to streamdev-client doesn't seem to break the connection, just request a second channel as it releases the first. ___ 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
Re: [vdr] [Patch] Make RGYB buttons customizeable
Yes i do. But the request can be refused, of course. Why not asking. I have a hama MCE ir. Dont know how many people use this remote. 2011/4/1 fnu v...@auktion.hostingkunde.de: My remote has the color order Yellow, Red, Blue, Green (only an example, i dont have the remote at hand). Lets say the buttons are Button0, Button1, Button2, Button3 My (and perhaps only my) opinion is that vdr should request the leftmost color button, then the color right next to it (and so on) while learning. The color displayed in the osd should be assigned via the setup menu. Are you seriously asking for a major change like this, just for your most propably unique remote control? The color order of the RGYB buttons is a common standard, defined for Teletext centuries ago. So, 99.999% of all remotes providing these keys do have this order. http://en.wikipedia.org/wiki/Teletext Regards fnu ___ 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
Re: [vdr] [Patch] Make RGYB buttons customizeable
2011/3/30 Steffen Barszus steffenbpu...@googlemail.com: 2011/3/30 Oliver Schinagl oli...@schinagl.nl: I belive that is exactly only what this patch does, it changes the positions on the screen for the ST-NG theme I think (it's been a while I admit). So if VDR is told that the red button performs the job of the red button, then everything is ok. To recap, the problem I had with VDR that caused me to write this patch, was: My Remote control had 2 buttons different from where VDR expected the buttons to be. E.g. VDR wants Red Yellow Green Blue, but my remote control was Red Yellow Blue Green. My remote has the color order Yellow, Red, Blue, Green (only an example, i dont have the remote at hand). Lets say the buttons are Button0, Button1, Button2, Button3 When learning, vdr wants the keys Red,Yellow, Green, Blue to get pressed. In the vdr layout Button0 is Red, Button1 is Yellow and so on ... while watching a recording vdr jumps 1 minute in the past when pressing yellow and one minute in the future when pressing green. These are the middle color buttons. I also wanted to have this functionality in the middle buttons (on the buttons 1 and 2). So i pressed the Buttons Yellow, Red, Blue, Green while learning Red,Yellow, Green, Blue. Then i have the jumping +/-1 Minute functionality still on the middle color buttons. The only thing left is that the color on the osd has to be adjusted, but not the positions of the text on it. If have dont this by modifying your patch (the texts for -DrawText are taken directly from the parameters, not from the mapping). My (and perhaps only my) opinion is that vdr should request the leftmost color button, then the color right next to it (and so on) while learning. The color displayed in the osd should be assigned via the setup menu. @Klaus: If there is a change to integrate this into the vdr, i would provide a patch for it. So in the end, this patch works for you and does what you want? Or is your remote layed out as VDR expects it? I would say better patch your remote. A sharp knife and a screwdriver might be quite effective and will fix the problem also for the next vdr releases ^^ This would be a real good solution, but i dont want to void my warranty :-) SCNR Steffen ___ 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
Re: [vdr] [Patch] Make RGYB buttons customizeable
Sorry for the noise, because: when learning lirc i havn't pressed the colors vdr wanted to be pressed, i pressed them from left to right. Afterwards, when switching the colors of the on-screen buttons, i thought only the color but not the positions of the on screen buttons get changed. When pressing the correct color buttons while learning, everything is ok. But i don't want this because then jumping +/- 1 minute while watching a recording are not on the middle color keys. All i would like to have is that only the color on the on-screen buttons changes. 2011/3/29 Rainer Blickle rainer.blic...@googlemail.com: I will take a look on it 2011/3/29 Oliver Schinagl oli...@schinagl.nl: I've never heard of that plugin before, and don't have it as such, so no idea how it goes wrong. Can you more closely describe how it goes wrong? From the description, I think they implement their own additional 'skin' and thus the plugin would have to be ported aswel. On 03/29/11 10:00, Rainer Blickle wrote: I've tried the patch and it worked at the first glance. But with the plugin Extrecmenu there are problems with the color keys. So i rolled back the patch. 2010/10/19 VDR User user@gmail.com: On Tue, Oct 19, 2010 at 12:16 AM, Oliver Schinagl oli...@schinagl.nl wrote: Nobody has any comment at all? :) I haven't found an issue as of yet running this for weeks now on my own VDR. I must say, it is nice to have the color order of the buttons match my remote :) The color arrangement already matches all of my remotes so I don't have any use for it. However, because I think it's useful to other users since a lot of remotes have a different color order, I'll help test it if you provide a VDR-1.7.16 compatible patch. That's my only condition as I'm not willing to downgrade my VDR boxes for this. If your patch made it into VDR and there are any plugins which use position to relate functions as you described (for example, right most key=ffwd) then maybe there also needs to be some mechanism for plugins to know which key is where (if there isn't one already). After VDR has been programmed for red/green/blue/yellow keys, then it can associate something like color1/color2/color3/color4 to the color order. Another thought is that VDR is supposed to get a truecolor OSD upgrade so we'll finally be able to have a great looking (HD) interface to use VDR with. Maybe the functionality of your patch is something Klaus has already considered during that upgrade. That's only speculation however but worth asking I think. Regards. ___ 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
I've tried the patch and it worked at the first glance. But with the plugin Extrecmenu there are problems with the color keys. So i rolled back the patch. 2010/10/19 VDR User user@gmail.com: On Tue, Oct 19, 2010 at 12:16 AM, Oliver Schinagl oli...@schinagl.nl wrote: Nobody has any comment at all? :) I haven't found an issue as of yet running this for weeks now on my own VDR. I must say, it is nice to have the color order of the buttons match my remote :) The color arrangement already matches all of my remotes so I don't have any use for it. However, because I think it's useful to other users since a lot of remotes have a different color order, I'll help test it if you provide a VDR-1.7.16 compatible patch. That's my only condition as I'm not willing to downgrade my VDR boxes for this. If your patch made it into VDR and there are any plugins which use position to relate functions as you described (for example, right most key=ffwd) then maybe there also needs to be some mechanism for plugins to know which key is where (if there isn't one already). After VDR has been programmed for red/green/blue/yellow keys, then it can associate something like color1/color2/color3/color4 to the color order. Another thought is that VDR is supposed to get a truecolor OSD upgrade so we'll finally be able to have a great looking (HD) interface to use VDR with. Maybe the functionality of your patch is something Klaus has already considered during that upgrade. That's only speculation however but worth asking I think. Regards. ___ 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
Re: [vdr] [Patch] Make RGYB buttons customizeable
I will take a look on it 2011/3/29 Oliver Schinagl oli...@schinagl.nl: I've never heard of that plugin before, and don't have it as such, so no idea how it goes wrong. Can you more closely describe how it goes wrong? From the description, I think they implement their own additional 'skin' and thus the plugin would have to be ported aswel. On 03/29/11 10:00, Rainer Blickle wrote: I've tried the patch and it worked at the first glance. But with the plugin Extrecmenu there are problems with the color keys. So i rolled back the patch. 2010/10/19 VDR User user@gmail.com: On Tue, Oct 19, 2010 at 12:16 AM, Oliver Schinagl oli...@schinagl.nl wrote: Nobody has any comment at all? :) I haven't found an issue as of yet running this for weeks now on my own VDR. I must say, it is nice to have the color order of the buttons match my remote :) The color arrangement already matches all of my remotes so I don't have any use for it. However, because I think it's useful to other users since a lot of remotes have a different color order, I'll help test it if you provide a VDR-1.7.16 compatible patch. That's my only condition as I'm not willing to downgrade my VDR boxes for this. If your patch made it into VDR and there are any plugins which use position to relate functions as you described (for example, right most key=ffwd) then maybe there also needs to be some mechanism for plugins to know which key is where (if there isn't one already). After VDR has been programmed for red/green/blue/yellow keys, then it can associate something like color1/color2/color3/color4 to the color order. Another thought is that VDR is supposed to get a truecolor OSD upgrade so we'll finally be able to have a great looking (HD) interface to use VDR with. Maybe the functionality of your patch is something Klaus has already considered during that upgrade. That's only speculation however but worth asking I think. Regards. ___ 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [1.7.16] problem with GetClippedNumProvidedSystems
Hi Lars, from my point of view this is not a problem and no fault of gcc 4.4.3. Why ?: When selecting a device for receiving (cDevice::GetDevice as far i know) there are 3 bits for the count of modulation systems. Is is the impact variable. The method isn't used anywhere else. The impact is smaller (numberic value) if a device has less modulation systems. Perhaps (and only perhaps) in some situations another device would be taken to receive a specific channel. Regards Rainer 2011/1/19 L. Hanisch d...@flensrocker.de: Hi, I get log messages like: ERROR: device 1 supports 7 modulation systems but cDevice::GetDevice() currently only supports 4 delivery systems which should be fixed It's a Satelco EasyWatch (DVB-C): frontend 0/0 provides DVB-C with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 (Philips TDA10023 DVB-C) But AvailableBits is 4, MaxNumProvidedSystems computes to 15 and NumProvidedSystems is 7 if I write them with isyslog to the log. Is it a fault of gcc 4.4.3? Has anyone any idea? I just don't know what to do with this... Regards, Lars. ___ 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
Re: [vdr] VDR loading locale
I have/had this problem when starting vdr not in the directory where the binary is. I used the parameter --localedir=..., but it didn't work. The default value for the locale dir is ./locale. At the moment i am changing to the directory where the vdr binary is located and start it there. 2010/11/29 crow c...@linux.org.ba: In my case i selected these bs_BA.UTF-8 UTF-8 bs_BA ISO-8859-2 de_AT.UTF-8 UTF-8 de_AT ISO-8859-1 de...@euro ISO-8859-15 en_US.UTF-8 en_US.ISO-8859-1 And did locale-gen to generate these, and all went fine. Just on VDR 1.7.16 start I see in its log this: Nov 29 16:16:40 localhost vdr: [14907] VDR version 1.7.16 started Nov 29 16:16:40 localhost vdr: [14907] switched to user 'vdr' Nov 29 16:16:40 localhost vdr: [14907] codeset is 'UTF-8' - known Nov 29 16:16:40 localhost vdr: [14907] found 0 locales in /usr/share/locale Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'deu,ger' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'slv,slo' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'ita' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'dut,nla,nld' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'por' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'fra,fre' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'nor' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'fin,suo' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'pol' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'esl,spa' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'ell,gre' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'sve,swe' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'rom,rum' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'hun' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'cat,cln' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'rus' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'hrv' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'est' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'dan' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'cze,ces' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'tur' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'ukr' Nov 29 16:16:40 localhost vdr: [14907] no locale for language code 'ara' And no other language then English is posible to select inside OSD Settings. If i just add these more inside /etc/locale.gen de_DE.UTF-8 UTF-8 de_DE ISO-8859-1 de...@euro ISO-8859-15 and do again locale-gen (which also went fine), in log is to see this: Nov 29 16:18:52 localhost vdr: [17933] VDR version 1.7.16 started Nov 29 16:18:52 localhost vdr: [17933] switched to user 'vdr' Nov 29 16:18:52 localhost vdr: [17933] codeset is 'UTF-8' - known Nov 29 16:18:52 localhost vdr: [17933] found 27 locales in /usr/share/locale Nov 29 16:18:52 localhost vdr: [17933] no locale for language code 'por' Nov 29 16:18:52 localhost vdr: [17933] loading plugin: /usr/lib/vdr/plugins/libvdr-signal.so.1.7.16 And i can select there other language then just English, even no locale for them. Is this above normal behavior or something is wrong here... ___ 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
Re: [vdr] Strange problem with one specific channel
Hi Dirk, if you have a solution, pls reply the answer to your question. You have written your solution in the vdr portal. For the others: The pids of the channel have changed. After creating a new channels.conf the channel can be received. 2010/10/25 Rainer Blickle rainer.blic...@googlemail.com: Hi, perhaps the pid's have changed. Pls do a rescan (with wscan or so) and compare the newly generated channels.conf with your entry. 2010/10/22 Dirk E. Wagner m...@wagner-budenheim.de: Hi, On 18.10.2010 12:00, vdr-requ...@linuxtv.org wrote: I have a strange problem with a relatively new DVB-T/SD/MPEG2 channel in Sweden. If I try to record from it all I get is a zero-byte file and VDR restarts after the standard 30 seconds reporting the infamous ERROR: video data stream broken. All other channels on that mux are perfectly OK in VDR. I can confirm this problem with vdr 1.6 and 1.7 with DVB-T channel Super-RTL in Rhein-Main-Area in Germany. I posted this in the german vdr forum, but without response: http://vdr-portal.de/board/thread.php?threadid=99985 The Super-RTL channel worked for a long time without problems. Since several weeks the problem arise, so I think the dvb stream was changed. ___ 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
Re: [vdr] Strange problem with one specific channel
Hi, perhaps the pid's have changed. Pls do a rescan (with wscan or so) and compare the newly generated channels.conf with your entry. 2010/10/22 Dirk E. Wagner m...@wagner-budenheim.de: Hi, On 18.10.2010 12:00, vdr-requ...@linuxtv.org wrote: I have a strange problem with a relatively new DVB-T/SD/MPEG2 channel in Sweden. If I try to record from it all I get is a zero-byte file and VDR restarts after the standard 30 seconds reporting the infamous ERROR: video data stream broken. All other channels on that mux are perfectly OK in VDR. I can confirm this problem with vdr 1.6 and 1.7 with DVB-T channel Super-RTL in Rhein-Main-Area in Germany. I posted this in the german vdr forum, but without response: http://vdr-portal.de/board/thread.php?threadid=99985 The Super-RTL channel worked for a long time without problems. Since several weeks the problem arise, so I think the dvb stream was changed. ___ 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
Re: [vdr] Alternative-Channel patch
The patch won't be applied to the main stream. You're right that the patch spreads about many multiple files. I was afraid (and i'm still) that i am the only person needing an applying the patch. Perhaps its also possible to provide such functionality with a plugin. I will examine the source code and analyze ... If not, i will provide a smaller patch without some of the features. Because i changed some interface, the skincurses plugin is also affected by the patch. But you don't need to use it for using the alternative functionality. Do you intend to apply the patch ? 2010/10/14 Rob Davis r...@davis-family.info: On 14/10/10 02:27, Rainer Blickle wrote: Has anybody but me applied this patch ? Rainer The patch seems spread across vdr and skincurses, which I don't use, so it didn't apply. Am looking at breaking it up into manageable parts and trying. -- Rob Davis ___ 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] Technotrend DVB-C 1501
Hi, i have a Technotrend DVB-C 1501 device (I guess the chip is the saa7146). With this card i cannot view a recording or live tv with the xineliboutput. live tv or a recording done by a pvrinput device works fine. Does anyone has a clue why the dvb-c device doesn't work with xineliboutput ? I have an ubuntu system with vdr 1.7.16. Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Technotrend DVB-C 1501
Hi, after searching a while i found it. With vdr-version 1.7.8 the cvs version of xineliboutput has to be used. Now everything works fine. 2010/10/15 Rainer Blickle rainer.blic...@googlemail.com: Hi, i have a Technotrend DVB-C 1501 device (I guess the chip is the saa7146). With this card i cannot view a recording or live tv with the xineliboutput. live tv or a recording done by a pvrinput device works fine. Does anyone has a clue why the dvb-c device doesn't work with xineliboutput ? I have an ubuntu system with vdr 1.7.16. Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Alternative-Channel patch
Has anybody but me applied this patch ? Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Supported FF cards
Hi, i have found the following code snippet in dvbsdffdevice.c: 0x110A, // Fujitsu Siemens DVB-C 0x13C2, // Technotrend/Hauppauge WinTV DVB-S rev1.X or Fujitsu Siemens DVB-C 0x13C20001, // Technotrend/Hauppauge WinTV DVB-T rev1.X 0x13C20002, // Technotrend/Hauppauge WinTV DVB-C rev2.X 0x13C20003, // Technotrend/Hauppauge WinTV Nexus-S rev2.X 0x13C20004, // Galaxis DVB-S rev1.3 0x13C20006, // Fujitsu Siemens DVB-S rev1.6 0x13C20008, // Technotrend/Hauppauge DVB-T 0x13C2000A, // Technotrend/Hauppauge WinTV Nexus-CA rev1.X 0x13C2000E, // Technotrend/Hauppauge WinTV Nexus-S rev2.3 0x13C21002, // Technotrend/Hauppauge WinTV DVB-S rev1.3 SE Are these all supported ff cards ? Or ar these all available ff cards at all ? Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Supported FF cards
there are enough other solution as decoder without tuner What do you mean with other solutions ? I have a pvr350 cards for output. Do you mean xineliboutput or streamdev or other real hardware ? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] FF-Card and Receivers
Hi, i have a question about a vdr with a ff card. When watching tv with a ff card (= not in transfer mode): Is there a receiver attached to the primary device ? I cannot test it by myself because i dont have a ff card. Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] priorities 0
Hi, i have a question regarding receivers with priority 0. I have taken a look at cDvbDevice::ProvidesChannel (1.7.15). When priority is 0 hasPriority gets set to true even if there are other receivers for a different channel. In this case NeedsDetachReceivers is set to false. If cDvbDevice::ProvidesChannel is called with a priority 0, then the Channel parameter has to be the Channel currently receiving on the device. Why: If the cDvbDevice::ProvidesChannel is called with priority 0 and a channel other than the current receiving, needsDetachReceived would be kept to false, the receiver would be added the the list of receivers, but the channel doesn't get switched. Or does the Channel doesn't matter if the priority is 0 ? My question: is my assumption correct ? Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Impact in cDevice::GetDevice
Hi Lars, a third one (just comes to my mind, not deeply thought about): Write a device-plugin which provides a new source. Then you will have your own channels. In each channel entry you can configure which real channels are behind this and the plugin will attach a receiver to the next free real device and passes through the data. That would be a transparent way for recordings, live tv etc. and you don't have to patch vdr (hopefully). You only have to look where to get the epg but I think there's a copy epg from one channel to another-patch... i've also thought about such a function. I stopped thinking about this when recognizing the following (an example): There is a non-ff-device like xineliboutput, softdevice, pvr350 or something like this. Then vdr needs to start the transfer mode. The transfer (cTransferControl resp. cTransfer) object gets attached (i think as a receiver, but perhaps something else). The newly device needs also a transfer object because it is not the device providing the channel. Then there are 2 chained transfer objects. For Recordings, there is a cRecord object. This record objects receives also the stream from a device. There i need another transfer object, too. This complexity gets multiplied with more than one receiver (streamdev, liveview, recordings). At this moment, for me this is like rocket science. There is another, easier way. To introduce such functionality to pvrinput (thats the devices i have and at the moment i'm watching dvb-c channels. if the dvb-c device is in use, i switch to a pvrinput channel). For the (and only for this) channels provided by the pvrinput plugin there is an alternative approach: pvrinput can tune to an analog channel if it is requested for an dvb-c one. Cheers, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Impact in cDevice::GetDevice
This impact algorithm has evolved over time and is a very fragile thing. Looks like only people have very deep insight in this algorithm should change it. For alternate channel, wouldn't it be better to try all possible channels one after the other until one succeeds? I would not expect GetDevice to return a device for a different channel than requested. I have two different solutions in mind. The first one: Modify the cDevice::GetDevice method. It returns a device able to provide the same semantic channel as requested (semantic channel = channel with the same programme). Modify the cDevice::SetChannel method. If the requested channel couldn't be provided by the device, the method will try to provide the configured alternatives one. Pros: The user have the epg and the original channel number on the osd Cons: Modifies the methods in an unexpected way. Plugins and other parts of the vdr doesn't work anymore. The second one: When pressing CH+/- or selecting an channel directly (via 0-9) and the selected channel is not available, switch the channel explicit to an alternative one. (explicit = also display the channel number and the epg of the alternative channel). Pros: After switching to the new channel, the vdr is in a clean and consitent state. Cons: The vdr has switched to complete another channel when using CH+/-. Checking for timer conflicts won't work correctly in both ways (without changes), because this algorithm doesn't know about alternative channels. But it would be much easier to implement this when using the second approach. Cheers, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Impact in cDevice::GetDevice
Hi, in the method cDevice::GetDevice the device with the least impact is searched (the block with imp = x; imp |= ). For calculating the impact (higher value = bigger impact) some facts are used. The most prio fact is prefer the primary device for live viewing, the least prio is prefer CAMs that are known to decrypt this channel. Does anyone know why the facts are ordered in this way ? Why ?: At the moment i'm developing a patch providing alternative channels. An alternative channel is a channel providing the same programme as the original channel, but with another receiving technique (like DVB-T instead of DVB-C). My alternative technique is analoge (via pvrinput). For this, i introduced a new fact programme is received from an alternative channel. Therefor i have to define the priority of this new fact regarding the impact. So i'd like to know more why the prio is as it is. Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Primary Device
Hi Folks, i have a question: What is the primary device. I have the following devices: - xineliboutput or PVR350 - pvrinput-device None of the devices can do both, receive and showing a stream . Which of the devices is the primary device. How is the primary device determined ? Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] test-infrastructure
Are the test sources included in the plugin? And if so, how do i execute the tests? Am 06.08.2010 02:00 schrieb Tobi listacco...@e-tobi.net: Rainer Blickle wrote: How do you (everyone subscribed to this list) test your developed code ? In the Vodcatcher plugin I used CxxTest: http://projects.vdr-developer.org/git/?p=vdr-plugin-vodcatcher.git;a=tree TomG uses CxxTest in the Sudoku plugin as well: http://projects.vdr-developer.org/git/?p=vdr-plugin-sudoku.git;a=tree In general unit testing C++ code can be kinda painful compared to Nunit, Junit or RSpec. CxxTest was the best C++ unit testing tool I could find, but maybe there exists something better now. Besides this you can use Valgrind to hunt down mem leaks and cppcheck for static code analysis. Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] test-infrastructure
Hi folks, i have a question regarding testing infrastructure in the vdr project: Is there any infrastructure for automated tests used by the developer. The only infrastructure i know of is the remote control. svdrp commands could be used for automated testing, but i never seen one using it. How do you (everyone subscribed to this list) test your developed code ? Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Alternate-Channel-Patch
Hi everybody, there was the alternate channel patch (http://www.vdr-wiki.de/wiki/index.php/Alternative_channel-patch). This patch provides alternative channels for timers, if the programmed channel was not available. Is there any patch providing this functionality for live-tv, too ? If not, i would like to develop such a functionality. Does anybody knows why the patch doesn't get integrated ? Is such a functionality unwanted ? What is the workflow to parcipiate in developing the vdr ? Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities in streamdev
Hi Frank, my first (and also not nice) fix on my dev system was to detach the current receiver before calling cDevice::GetDevice. But this is also only a quickfix because when a timer records, the live tv will be stopped because of the priority. My first not-quickfix idea was to add a additional boolean parameter to the cDevice::GetDevice method, for convenience with a default value (e.g. detachIfNecessary). If this value is true, the method would detach the receiver. If this value is false, the method wouldn't detach. With a value of false, the Method would still be a query method. Regards, Rainer 2010/7/6 Frank Schmirler v...@schmirler.de: Hi Rainer, On Mon, 5 Jul 2010 07:28:37 +0200, Rainer Blickle wrote Later in the code of cServerConnection::GetDevice, if the Method cDevice::GetDevice doesn't return a device, the current receiver gets detached. In my infrastructure this doesnt happend because the live receiver will nearly always gets detached ( The only exception is when a timer records). To prevent this, i changed the code in that way that the streamdev-receiver gets detached before calling cDevice::GetDevice). thanks for tracking this issue down and for the detailed bugreport. The DetachAllReceivers part in cDevice::GetDevice(...) was introduced in VDR 1.5.0. This change effectively turned this method from being a query only method into something with side effects. The proper (though not nice) solution seems to be copying cDevice::GetDevice(...) into streamdev server, leaving out the problematic parts. I quickly hacked together a patch at http://www.vdr-developer.org/mantisbt/view.php?id=582. It's totally untested, but maybe you want to give it a try. Might take a while until I have time to test it. Regards, Frank ___ 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] priorities in streamdev
Hi everybody, i have a question regarding the streamdev plugin. I have 2 tv cards, both gets accessed with the pvrinput plugin, but the problem i have would be the same with dvb devices. I also watch TV on the PC with the two cards. I have another pc (laptop) with vdr installed. There i installed the streamdev-client plugin. When switching the channel on the laptop with the up/down keys, the live picture gets interrupted with a black screen for about half a second. My wife doesn't like this very much. I had a look into the source code and found following: - The receiver of the pc has the priority 0, the receiver of the streamdev-server 1. - When switching with the up/down keys, the streamdev-client sends an PROV-Message to the streamdev-server. The streamdev-server tries to get a device (Method cServerConnection::GetDevice). The Receiver of the old streamdev-channel is still receiving. - The Method cServerConnection::GetDevice calls cDevice::GetDevice. The priority in the function call is 1. In the cDevice::GetDevice method the devices gets iterated, calling on each device the method cDevice::ProvidesChannel. Because the priority property of this call is 1, the old receiver of the streamdev-server has also a priority of 1 and the live-receiver has the priority of 0, the only device which can provide the channel is the device of the live-tv. - In the latter of the method cDevice::GetDevice the live-receiver gets detached via d-DetachAllReceivers. Later in the code of cServerConnection::GetDevice, if the Method cDevice::GetDevice doesn't return a device, the current receiver gets detached. In my infrastructure this doesnt happend because the live receiver will nearly always gets detached ( The only exception is when a timer records). To prevent this, i changed the code in that way that the streamdev-receiver gets detached before calling cDevice::GetDevice). Is the detaching of live-tv an known issue or is this a feature ? Should have the live tv receiver a priority greather than streamdev-receiver ? If so, the live-tv wouldn't get detached ? Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
