VDR developer version 1.7.30 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.30.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.29-1.7.30.diff
MD5 checksums:
c6d75f2962bc3e22d9313c0ee4fa113a vdr-1.7.30.tar.bz2 a63098efcc58bc697d6b890097d9c370 vdr-1.7.29-1.7.30.diff
WARNING: ========
This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging.
The default skin "LCARS" displays the signal strengths and qualities of all devices in its main menu. For devices that have an stb0899 frontend chip (like the TT-budget S2-3200) retrieving this information from the driver is rather slow, which results in a sluggish response to user input in the main menu. To speed this up you may want to apply the patches from
ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches
to the LinuxDVB driver source.
The changes since version 1.7.29:
- Fixed sorting recordings in the top level video directory. - Fixed handling control characters in SI data in case of UTF-8 encoded strings (thanks to Mehdi Karamnejad for reporting a problem with garbled UTF-8 EPG data and helping to debug it). - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - When checking whether a video directory is empty, file names that start with a dot ('.') are now ignored and will be implicitly removed if the directory contains no other files. This fixes the leftover ".sort" files that were introduced in version 1.7.29. - Added IsUpdate() to the EPG handler interface (thanks to Jörg Wendel). - Fixed detecting transfer mode on full featured DVB cards (thanks to Stefan Huelswitt for reporting a problem with updating CA descriptors in such cases). - Fixed a race condition when zapping in transfer mode (reported by Reinhard Nissl). This involves a slight change in the semantics of the cReceiver::Activate() function, which is now called with 'false' *after* the receiver has been detached from the device. - The new function cDevice::ReadFilter() can be used by devices to implement their own way of retrieving section filter data (thanks to Deti Fliegl). - The new function cDevice::HasInternalCam() can be implemented by devices that provide encrypted channels in an already decrypted form, without requiring explicit handling of a CAM (thanks to Tobias Grimm). - VDR can now be built according to the FHS ("File system Hierarchy Standard") by activating the line #USEFHS = 1 in a copy of the file Make.config.template (thanks to Dennis Bendlin, as well as Christopher Reimer and Udo Richter for contributing to the patch). - By default (without FHS support) the config directory is now set to the value given in the -v option if only -v and no -c is given. - Fixed a long delay at the end when replaying a recording that has stopped recording less than an hour ago (typically time shift mode or a freshly edited recording). - Fixed getting the file size and number of frames of ongoing recordings (only the timestamp of the recording's directory was checked, while it should have been that of the index file). - Fixed sluggish response when manipulating editing marks while a cutting thread is running (reported by Torsten Lang). - The new setup options "OSD/Color key [0123]" can be used to adjust the sequence of the color buttons displayed in the menus to that of the color keys on your remote control (based on a patch from Oliver Schinagl). Authors of plugins that implement skins may want to adapt their SetButtons() function in order to make use of this new feature. See, for instance, the function cSkinClassicDisplayMenu::SetButtons() in skinclassic.c for details.
Have fun!
Klaus
On Monday 10 September 2012 - 16:05:25, Klaus Schmidinger wrote:
- When checking whether a video directory is empty, file names that start
with a dot ('.') are now ignored and will be implicitly removed if the directory contains no other files. This fixes the leftover ".sort" files that were introduced in version 1.7.29.
I possibly missed the discussion about that item.
I consider the implicit removal of dot-files problematic and suboptimal. Until vdr 1.7.29 it was possible to create mount-points and execute a "touch <mount-point>/.nodelete" to ensure, the vdr will not delete that mount- point. From OSD-menu then mounting of external storage was possible.
It is of cause stil possible, as scripts could create directories, but that may cause problems with access-permissions.
Creating an empty file without leading dot will prohibit the removal too, but I think, the directory will then appear in the recording menu, which is not the case, with just a dotfile in.
Would it be possible to remove the ".sort" files only or add support for a hidden keyfile, that will not be removed?
cheers Gero
On 10.09.2012 16:38, Gero wrote:
On Monday 10 September 2012 - 16:05:25, Klaus Schmidinger wrote:
- When checking whether a video directory is empty, file names that start
with a dot ('.') are now ignored and will be implicitly removed if the directory contains no other files. This fixes the leftover ".sort" files that were introduced in version 1.7.29.
I possibly missed the discussion about that item.
I consider the implicit removal of dot-files problematic and suboptimal. Until vdr 1.7.29 it was possible to create mount-points and execute a "touch <mount-point>/.nodelete" to ensure, the vdr will not delete that mount- point.
From OSD-menu then mounting of external storage was possible.
It is of cause stil possible, as scripts could create directories, but that may cause problems with access-permissions.
Creating an empty file without leading dot will prohibit the removal too, but I think, the directory will then appear in the recording menu, which is not the case, with just a dotfile in.
The recording menu only displays directories that contain actual recordings (or subdirectories with recordings). A plain file doesn't trigger displaying a directory.
Klaus
Hi,
attached is a patch which extends the cmd call function to: if a recording is deleted. The cmd call 'edited' where not mentioned, which I now did.
Would be nice, if it find's a way into the main vdr.
Alexander
On 11.09.2012 09:29, hondansx@gmx.de wrote:
Hi,
attached is a patch which extends the cmd call function to: if a recording is deleted. The cmd call 'edited' where not mentioned, which I now did.
Would be nice, if it find's a way into the main vdr.
What would this be good for?
Klaus
| On 11.09.2012 09:29, hondansx@gmx.de wrote: |> Hi, |> |> attached is a patch which extends the cmd call function to: if a |> recording |> is deleted. |> The cmd call 'edited' where not mentioned, which I now did. |> |> Would be nice, if it find's a way into the main vdr. | | What would this be good for?
If a recording is deleted, you could do everything you want. For example: rename, restore, move it to another location in condition this is a important/not seen or a autocut+deleted recording.
I use vdr in a server environment with multiple clients and I will get noticed if somebody deletes anything. So I assume this make more sense in a server environment. ;-) Alexander
Hi Klaus,
I would like this function, too. Because I have a script, which converts VDR-recordings to smaller mp4 for my mobile. And with that vdr-cmd-script, running after a recording was deleted, it would be possible to delete the associated mp4-file automatically.
Greetings, Stephan.
Am 09/11/12 09:41, schrieb Klaus Schmidinger:
On 11.09.2012 09:29, hondansx@gmx.de wrote:
Hi,
attached is a patch which extends the cmd call function to: if a recording is deleted. The cmd call 'edited' where not mentioned, which I now did.
Would be nice, if it find's a way into the main vdr.
What would this be good for?
Klaus
10.09.2012 17:05, Klaus Schmidinger kirjoitti:
The changes since version 1.7.29:
[...]
- The new function cDevice::HasInternalCam() can be implemented by devices that provide encrypted channels in an already decrypted form, without requiring explicit handling of a CAM (thanks to Tobias Grimm).
Hmm, I'm the original author of the patch, not sure why Tobias Grimm is credited here (I sent it to you several years ago - for some reason I thought you didn't like it, but I guess I should've just sent it again... sorry for that).
On 11 September 2012 10:30, Anssi Hannula anssi.hannula@iki.fi wrote:
10.09.2012 17:05, Klaus Schmidinger kirjoitti:
- The new function cDevice::HasInternalCam() can be implemented by devices that provide encrypted channels in an already decrypted form, without requiring explicit handling of a CAM (thanks to Tobias Grimm).
Hmm, I'm the original author of the patch, not sure why Tobias Grimm is credited here (I sent it to you several years ago - for some reason I thought you didn't like it, but I guess I should've just sent it again... sorry for that).
11.09.2012 19:05, Dominic Evans kirjoitti:
On 11 September 2012 10:30, Anssi Hannula anssi.hannula@iki.fi wrote:
10.09.2012 17:05, Klaus Schmidinger kirjoitti:
- The new function cDevice::HasInternalCam() can be implemented by devices that provide encrypted channels in an already decrypted form, without requiring explicit handling of a CAM (thanks to Tobias Grimm).
Hmm, I'm the original author of the patch, not sure why Tobias Grimm is credited here (I sent it to you several years ago - for some reason I thought you didn't like it, but I guess I should've just sent it again... sorry for that).
Ah, so I *did* send it again after all ;)
On 11.09.2012 11:30, Anssi Hannula wrote:
Hmm, I'm the original author of the patch, not sure why Tobias Grimm is credited here
Sorry, that's probably because I maintained this in the Debian package since 2008 and the patch tools added my name to the patch header.
I think Manuel sent the patch to Klaus - he asked me 3 months ago who the original author is and from
http://projects.vdr-developer.org/git/vdr-plugin-streamdev.git/tree/CONTRIBU...
...I figured out it's you.
This information probably got lost somewhere.
I didn't meant to take credit for this! But I'm sure Klaus will fix this.
Tobias
12.09.2012 10:39, Tobi kirjoitti:
On 11.09.2012 11:30, Anssi Hannula wrote:
Hmm, I'm the original author of the patch, not sure why Tobias Grimm is credited here
Sorry, that's probably because I maintained this in the Debian package since 2008 and the patch tools added my name to the patch header.
I think Manuel sent the patch to Klaus - he asked me 3 months ago who the original author is and from
http://projects.vdr-developer.org/git/vdr-plugin-streamdev.git/tree/CONTRIBU...
...I figured out it's you.
Yeah, he asked me too and I said the same.
This information probably got lost somewhere.
Yep :)
I didn't meant to take credit for this! But I'm sure Klaus will fix this.
On 11.09.2012 11:30, Anssi Hannula wrote:
10.09.2012 17:05, Klaus Schmidinger kirjoitti:
The changes since version 1.7.29:
[...]
- The new function cDevice::HasInternalCam() can be implemented by devices that provide encrypted channels in an already decrypted form, without requiring explicit handling of a CAM (thanks to Tobias Grimm).
Hmm, I'm the original author of the patch, not sure why Tobias Grimm is credited here (I sent it to you several years ago - for some reason I thought you didn't like it, but I guess I should've just sent it again... sorry for that).
Sorry about that - I have fixed it for the next developer version.
Klaus
On 09/10/2012 05:05 PM, Klaus Schmidinger wrote:
VDR developer version 1.7.30 is now available at
I tried to use for a first time with VDR the HVR-4000's multible delivery systems under same frontend feature that was introduced in 1.7.23. (HVR-4000 has DVB-T and DVB-S/S2 in the same card but only one of these delivery systems can work at a time.) In addition I have normal hvr-1300 DVB-T only tuner. If I connect cable only to HVR-4000, I can not get DVB-T channels visible with VDR. (but dvb apps like scan will work from the command line).
The error looks similar than somebody else reported at a time when 1.7.23 was released but now I would expect of having new enough kernel running. My system info and logs are following:
1) Kernel version: 3.3.8-desktop-2.mga2
DVB API version is 5.5 (grep DVB-API)
include/linux/dvb/version.h:#define DVB_API_VERSION 5 include/linux/dvb/version.h:#define DVB_API_VERSION_MINOR 5
2) tree /dev/dvb/ /dev/dvb/ ├── adapter0 │ ├── demux0 │ ├── dvr0 │ ├── frontend0 │ └── net0 └── adapter1 ├── demux0 ├── demux1 ├── dvr0 ├── dvr1 ├── frontend0 ├── frontend1 ├── net0 └── net1
3) VDR log which indicates device or resource busy error for adapter1/fronend1 device.
Sep 17 23:51:34 localhost vdr: [15256] VDR version 1.7.30 started Sep 17 23:51:34 localhost vdr: [15256] codeset is 'UTF-8' - known Sep 17 23:51:34 localhost vdr: [15256] found 28 locales in ./locale Sep 17 23:51:34 localhost vdr: [15256] loading plugin: ./PLUGINS/lib/libvdr-xineliboutput.so.1.7.30 Sep 17 23:51:34 localhost vdr: [15256] loading plugin: ./PLUGINS/lib/libvdr-osdteletext.so.1.7.30 Sep 17 23:51:34 localhost vdr: [15256] loading plugin: ./PLUGINS/lib/libvdr-skinsoppalusikka.so.1.7.30 Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/setup.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/sources.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/diseqc.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/scr.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/channels.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/timers.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/svdrphosts.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/remote.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/keymacros.conf Sep 17 23:51:34 localhost vdr: [15257] video directory scanner thread started (pid=15256, tid=15257) Sep 17 23:51:34 localhost vdr: [15258] video directory scanner thread started (pid=15256, tid=15258) Sep 17 23:51:34 localhost vdr: [15256] registered source parameters for 'A - ATSC' Sep 17 23:51:34 localhost vdr: [15256] registered source parameters for 'C - DVB-C' Sep 17 23:51:34 localhost vdr: [15256] registered source parameters for 'S - DVB-S' Sep 17 23:51:34 localhost vdr: [15256] registered source parameters for 'T - DVB-T' Sep 17 23:51:34 localhost vdr: [15256] probing /dev/dvb/adapter0/frontend0 Sep 17 23:51:34 localhost vdr: [15256] creating cDvbDevice Sep 17 23:51:34 localhost vdr: [15256] new device number 1 Sep 17 23:51:34 localhost vdr: [15259] epg data reader thread started (pid=15256, tid=15259) Sep 17 23:51:34 localhost vdr: [15259] reading EPG data from /storagedisc/video/epg.data Sep 17 23:51:34 localhost vdr: [15258] video directory scanner thread ended (pid=15256, tid=15258) Sep 17 23:51:34 localhost vdr: [15256] frontend 0/0 provides DVB-T with QPSK,QAM16,QAM64 ("Conexant CX22702 DVB-T") Sep 17 23:51:34 localhost vdr: [15256] probing /dev/dvb/adapter1/frontend0 Sep 17 23:51:34 localhost vdr: [15256] creating cDvbDevice Sep 17 23:51:34 localhost vdr: [15256] new device number 2 Sep 17 23:51:34 localhost vdr: [15261] tuner on frontend 0/0 thread started (pid=15256, tid=15261) Sep 17 23:51:34 localhost vdr: [15261] cTimeMs: using monotonic clock (resolution is 1 ns) Sep 17 23:51:34 localhost vdr: [15262] section handler thread started (pid=15256, tid=15262) Sep 17 23:51:34 localhost vdr: [15257] video directory scanner thread ended (pid=15256, tid=15257) Sep 17 23:51:34 localhost vdr: [15256] frontend 1/0 provides DVB-S,DVB-S2 with QPSK ("Conexant CX24116/CX24118") Sep 17 23:51:34 localhost vdr: [15265] section handler thread started (pid=15256, tid=15265) Sep 17 23:51:34 localhost vdr: [15264] tuner on frontend 1/0 thread started (pid=15256, tid=15264) Sep 17 23:51:34 localhost vdr: [15259] epg data reader thread ended (pid=15256, tid=15259) Sep 17 23:51:39 localhost vdr: [15256] ERROR (dvbdevice.c,1058): /dev/dvb/adapter1/frontend1: Device or resource busy Sep 17 23:51:39 localhost vdr: [15256] found 2 DVB devices
Mika
On 17.09.2012 23:17, Mika Laitio wrote:
On 09/10/2012 05:05 PM, Klaus Schmidinger wrote:
VDR developer version 1.7.30 is now available at
I tried to use for a first time with VDR the HVR-4000's multible delivery systems under same frontend feature that was introduced in 1.7.23. (HVR-4000 has DVB-T and DVB-S/S2 in the same card but only one of these delivery systems can work at a time.) In addition I have normal hvr-1300 DVB-T only tuner. If I connect cable only to HVR-4000, I can not get DVB-T channels visible with VDR. (but dvb apps like scan will work from the command line).
The error looks similar than somebody else reported at a time when 1.7.23 was released but now I would expect of having new enough kernel running. My system info and logs are following:
- Kernel version: 3.3.8-desktop-2.mga2
DVB API version is 5.5 (grep DVB-API)
include/linux/dvb/version.h:#define DVB_API_VERSION 5 include/linux/dvb/version.h:#define DVB_API_VERSION_MINOR 5
- tree /dev/dvb/
/dev/dvb/ ├── adapter0 │ ├── demux0 │ ├── dvr0 │ ├── frontend0 │ └── net0 └── adapter1 ├── demux0 ├── demux1 ├── dvr0 ├── dvr1 ├── frontend0 ├── frontend1 ├── net0 └── net1
- VDR log which indicates device or resource busy error for
adapter1/fronend1 device.
[ kls: fixed wrapped log lines ]
Sep 17 23:51:34 localhost vdr: [15256] VDR version 1.7.30 started Sep 17 23:51:34 localhost vdr: [15256] codeset is 'UTF-8' - known Sep 17 23:51:34 localhost vdr: [15256] found 28 locales in ./locale Sep 17 23:51:34 localhost vdr: [15256] loading plugin: ./PLUGINS/lib/libvdr-xineliboutput.so.1.7.30 Sep 17 23:51:34 localhost vdr: [15256] loading plugin: ./PLUGINS/lib/libvdr-osdteletext.so.1.7.30 Sep 17 23:51:34 localhost vdr: [15256] loading plugin: ./PLUGINS/lib/libvdr-skinsoppalusikka.so.1.7.30 Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/setup.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/sources.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/diseqc.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/scr.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/channels.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/timers.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/svdrphosts.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/remote.conf Sep 17 23:51:34 localhost vdr: [15256] loading /home/lamikr/misc/vdr/vdr.git/keymacros.conf Sep 17 23:51:34 localhost vdr: [15257] video directory scanner thread started (pid=15256, tid=15257) Sep 17 23:51:34 localhost vdr: [15258] video directory scanner thread started (pid=15256, tid=15258) Sep 17 23:51:34 localhost vdr: [15256] registered source parameters for 'A - ATSC' Sep 17 23:51:34 localhost vdr: [15256] registered source parameters for 'C - DVB-C' Sep 17 23:51:34 localhost vdr: [15256] registered source parameters for 'S - DVB-S' Sep 17 23:51:34 localhost vdr: [15256] registered source parameters for 'T - DVB-T' Sep 17 23:51:34 localhost vdr: [15256] probing /dev/dvb/adapter0/frontend0 Sep 17 23:51:34 localhost vdr: [15256] creating cDvbDevice Sep 17 23:51:34 localhost vdr: [15256] new device number 1 Sep 17 23:51:34 localhost vdr: [15259] epg data reader thread started (pid=15256, tid=15259) Sep 17 23:51:34 localhost vdr: [15259] reading EPG data from /storagedisc/video/epg.data Sep 17 23:51:34 localhost vdr: [15258] video directory scanner thread ended (pid=15256, tid=15258) Sep 17 23:51:34 localhost vdr: [15256] frontend 0/0 provides DVB-T with QPSK,QAM16,QAM64 ("Conexant CX22702 DVB-T") Sep 17 23:51:34 localhost vdr: [15256] probing /dev/dvb/adapter1/frontend0 Sep 17 23:51:34 localhost vdr: [15256] creating cDvbDevice Sep 17 23:51:34 localhost vdr: [15256] new device number 2 Sep 17 23:51:34 localhost vdr: [15261] tuner on frontend 0/0 thread started (pid=15256, tid=15261) Sep 17 23:51:34 localhost vdr: [15261] cTimeMs: using monotonic clock (resolution is 1 ns) Sep 17 23:51:34 localhost vdr: [15262] section handler thread started (pid=15256, tid=15262) Sep 17 23:51:34 localhost vdr: [15257] video directory scanner thread ended (pid=15256, tid=15257) Sep 17 23:51:34 localhost vdr: [15256] frontend 1/0 provides DVB-S,DVB-S2 with QPSK ("Conexant CX24116/CX24118") Sep 17 23:51:34 localhost vdr: [15265] section handler thread started (pid=15256, tid=15265) Sep 17 23:51:34 localhost vdr: [15264] tuner on frontend 1/0 thread started (pid=15256, tid=15264) Sep 17 23:51:34 localhost vdr: [15259] epg data reader thread ended (pid=15256, tid=15259) Sep 17 23:51:39 localhost vdr: [15256] ERROR (dvbdevice.c,1058): /dev/dvb/adapter1/frontend1: Device or resource busy Sep 17 23:51:39 localhost vdr: [15256] found 2 DVB devices
If this device can only provide one delivery system at a time, they all need to be provided through the *same* frontend.
From the log I can see that the driver apparently makes DVB-S/DVB-S2 available under adapter1/frontend0 and tries to provide DVB-T on adapter1/frontend1. But if it does so, it tells the application that it can provide DVB-S/DVB-S2 *and* DVB-T at the *same* time - which apparently isn't the case.
Klaus
From the log I can see that the driver apparently makes DVB-S/DVB-S2 available under adapter1/frontend0 and tries to provide DVB-T on adapter1/frontend1. But if it does so, it tells the application that it can provide DVB-S/DVB-S2 *and* DVB-T at the *same* time - which apparently isn't the case.
Yes, you are correct. If I use frontend0 for DVB-S, I can't use frontend 1 at a same time for DVB-T. I will try in the evening to build the latest drivers myself to check whether both frontends are still created also with that one.
Are there some other cards/drivers available with similar limitation where only a single frontend0 is created?
Mika
On 19-09-12 09:25, Mika Laitio wrote:
From the log I can see that the driver apparently makes DVB-S/DVB-S2 available under adapter1/frontend0 and tries to provide DVB-T on adapter1/frontend1. But if it does so, it tells the application that it can provide DVB-S/DVB-S2 *and* DVB-T at the *same* time - which apparently isn't the case.
Yes, you are correct. If I use frontend0 for DVB-S, I can't use frontend 1 at a same time for DVB-T. I will try in the evening to build the latest drivers myself to check whether both frontends are still created also with that one.
Are there some other cards/drivers available with similar limitation where only a single frontend0 is created?
I unfortunatly missed half the discussion, but for two frontends to work, you need a dual-tuner card. I currently have a Terratec Cynergy dual T PCI-e card, that has two tuners that can be individually be controlled with dvb-fe-tool. I think the name dual-tuner is actually wrong, as it should be dual-frontend, tripple tuner in my case. One front-end can be connected to DVB-T-tuner Or Analogue TV-tuner (currently not working afaik) and the second frontend can be connected to a different DVB-T-tuner Or DVB-C-tuner.
Check the output of dvb-fe-tool and see what it outputs. Or, your driver is bugged/manufacturer lied about it's actual capabilities!
Mika
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
Am 19.09.2012 09:25, schrieb Mika Laitio:
From the log I can see that the driver apparently makes DVB-S/DVB-S2 available under adapter1/frontend0 and tries to provide DVB-T on adapter1/frontend1. But if it does so, it tells the application that it can provide DVB-S/DVB-S2 *and* DVB-T at the *same* time - which apparently isn't the case.
Yes, you are correct. If I use frontend0 for DVB-S, I can't use frontend 1 at a same time for DVB-T. I will try in the evening to build the latest drivers myself to check whether both frontends are still created also with that one.
As far as I know the driver for the HVR4000 has not been changed to use the new dvb-api capabilities for switching the frontend type. Maybe you can persuade them, the last user hadn't success yet... :(
Lars.
Are there some other cards/drivers available with similar limitation where only a single frontend0 is created?
Mika
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr