Hi,
now that I've moved from pci dvb-c cards to usb dvb-c cards, I started to think what happens if dvb-devices are inserted/ejected when vdr is running. I haven't actually tried what happens, but it looks like hotswapping isn't supported? I guess adding a new device could be done quite easily e.g. by probing new cards. But ejecting a device might not be that easy I guess as there may be device pointers around vdr?
This also leads to another problem with (linux and vdr) device numbering, as the nature of usb devices is lot less constant as with pci devices. I noticed that e.g. if you insert 3 devices (and have adapters 0,1,2) and remove the second adapter, then you only have (in linux) adapters 0 and 2. Even if the device is ejected when vdr is not running, it looks like to me (by reading cDvbDevice::Initialize()) that only adapter 0 is detected by vdr, as the initialize loop stops after adapter 1 is not found...
Even though this isn't really a problem for most installations, I wanted to start a thread to give this some thought.
Teemu
I don't have an answer to your question but I was told by a driver dev that linux usb hotplugging is buggy & horrid. Might want to consider not doing it.
Am 03.04.2010 21:17, schrieb Teemu Rantanen:
now that I've moved from pci dvb-c cards to usb dvb-c cards, I started to think what happens if dvb-devices are inserted/ejected when vdr is running. I haven't actually tried what happens, but it looks like hotswapping isn't supported?
VDR is far from being able to hot-swap.
As you've noticed, VDR only accepts properly ordered devices, and stops after first device that is not present. This could surely be fixed easily, and I think there have been existing patches for this. While on that, allowing to use DVB names other than /dev/dvb/ adapterX would be nice.
Adding devices dynamically should also be solveable with some care, the device list just needs to be extended. An easy way would be to poll frequently for new devices, or on manual request.
Removing devices however is really difficult. There's currently no mechanism to unload a device before VDR is exiting. Also, removing devices throws some questions, like what to do with running recorings (re-tune to other devices, possibly cancelling lower priority recordings?), and how to properly shut down all background access.
Finally, device removal needs to be detected, as the removed device will continue to exist until being closed.
All in all, solveable, but probably not very high on the todo list...
Cheers,
Udo
On Sun, Apr 04, 2010 at 12:35:04AM +0200, Udo Richter wrote:
Am 03.04.2010 21:17, schrieb Teemu Rantanen:
now that I've moved from pci dvb-c cards to usb dvb-c cards, I started to think what happens if dvb-devices are inserted/ejected when vdr is running. I haven't actually tried what happens, but it looks like hotswapping isn't supported?
VDR is far from being able to hot-swap.
This is true, but there is a workaround for that. It involves one indirection in the device handling by a plugin.
During the development of the mcli-plugin for the NetCeiver the same issue appeared. The networked tuners are already virtualized, they get visible a few seconds after the plugin start and may also disappear or change their type. So hotplugging support was a must.
It is now solved by the mcli plugin by allocating all (16) devices at startup. When the various Provides*-methods are called for tuning, the plugin searches in its internal resource database for an appropriate tuner and assigns it to the vdr-device. If there is no appropriate tuner for the request the Provides-methods return simply false, so the device is skipped. That is virtualizing of already virtual tuners :-O
This means also that every tuner has initially no type like DVB-S/C/T. The type is allocated on demand during tuning and reset when the device has no active PIDs (for short, actually it's a bit more complicated since there is no reliable resource usage tracking in vdr...).
Am 04.04.2010 03:37, schrieb Georg Acher:
It is now solved by the mcli plugin by allocating all (16) devices at startup. When the various Provides*-methods are called for tuning, the plugin searches in its internal resource database for an appropriate tuner and assigns it to the vdr-device. If there is no appropriate tuner for the request the Provides-methods return simply false, so the device is skipped. That is virtualizing of already virtual tuners :-O
This means also that every tuner has initially no type like DVB-S/C/T. The type is allocated on demand during tuning and reset when the device has no active PIDs (for short, actually it's a bit more complicated since there is no reliable resource usage tracking in vdr...).
Very impressive! Doing all that as a plugin is some smart plugin interface usage!
For a VDR internal method things would get easier, no need to pre-allocate dummies. Cleaning up the mess however is not as easy.
How did you solve the case that a device disappears while being used? If this happens for a recording, then VDR would terminate with a VDSB, or? Do you silently switch the device to another resource?
Cheers,
Udo
On Sun, Apr 04, 2010 at 10:54:02AM +0200, Udo Richter wrote:
How did you solve the case that a device disappears while being used? If this happens for a recording, then VDR would terminate with a VDSB, or? Do you silently switch the device to another resource?
As long as the device is used by vdr with a successful Provides() at the beginning, it cannot disappear, even if the "real" device behind it is gone. However, the vdr-device will get a no-lock after 10s and femon sees no longer a type and description after one minute. That also triggers the VDSB message, but recording goes on if the resource re-appears, as the vdr-device is not shutdown.
Since the tuner behind it is already virtualized, it will be immediately attached again to the "dangling" dvbdevice if something matching appears, e.g. when the network gets reconnected. This is due to the fact that the tuning parameters are included in the MLDv2-messages the mcli-plugin will resend every few seconds for an open device. The streaming starts again when an appropriate server gets these messages.
In principle it is possible to switch to another resource, but the current firmware supports no distributed sources (=satellite positions) over different NetCeivers, they need to be exclusive. We have already a peer-to-peer-like firmware that supports distributed resources and would allow redundant NetCeivers, but it still needs some CPU optimizations for the slow CPU on the NetCeiver...
However, internally in one NetCeiver an expensive resource (like a rotor or a S2-tuner that were used because no other tuners were free at that time) is automatically switched back to a cheaper resource if possible. This is almost invisible from the outside...
On 4 April 2010 03:37, Georg Acher acher@in.tum.de wrote:
On Sun, Apr 04, 2010 at 12:35:04AM +0200, Udo Richter wrote:
Am 03.04.2010 21:17, schrieb Teemu Rantanen:
now that I've moved from pci dvb-c cards to usb dvb-c cards, I started to think what happens if dvb-devices are inserted/ejected when vdr is running. I haven't actually tried what happens, but it looks like hotswapping isn't supported?
VDR is far from being able to hot-swap.
This is true, but there is a workaround for that. It involves one indirection in the device handling by a plugin.
During the development of the mcli-plugin for the NetCeiver the same issue appeared. The networked tuners are already virtualized, they get visible a few seconds after the plugin start and may also disappear or change their type. So hotplugging support was a must.
It is now solved by the mcli plugin by allocating all (16) devices at startup. When the various Provides*-methods are called for tuning, the plugin searches in its internal resource database for an appropriate tuner and assigns it to the vdr-device. If there is no appropriate tuner for the request the Provides-methods return simply false, so the device is skipped. That is virtualizing of already virtual tuners :-O
Can this solution coexist with vdr-streamdev/iptv? I ask because currently vdr-streamdev does not support dynamic increase in streams to remote server(s). Only way now is to copy the plugin multiple times and load them accordingly. If the plugin is loaded 3 times, then it will allow 3 connections. I take it this will then consume 3 devices?
This means also that every tuner has initially no type like DVB-S/C/T. The type is allocated on demand during tuning and reset when the device has no active PIDs (for short, actually it's a bit more complicated since there is no reliable resource usage tracking in vdr...).
-- Georg Acher, acher@in.tum.de http://www.lrr.in.tum.de/~acher "Oh no, not again !" The bowl of petunias
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 3 April 2010 21:17, Teemu Rantanen tvr@iki.fi wrote:
Hi, now that I've moved from pci dvb-c cards to usb dvb-c cards, I started to think what happens if dvb-devices are inserted/ejected when vdr is running. I haven't actually tried what happens, but it looks like hotswapping isn't supported? I guess adding a new device could be done quite easily e.g. by probing new cards. But ejecting a device might not be that easy I guess as there may be device pointers around vdr? This also leads to another problem with (linux and vdr) device numbering, as the nature of usb devices is lot less constant as with pci devices. I
That is true for pci devices because there is a persistent udev rule created for pci devices. I guess usb can also have a persistent rule/association created. However this will not solve your problem where device 0 and 2 is mapped persistently and 1 is still missing. Vdr will there for stop at 1 :(
noticed that e.g. if you insert 3 devices (and have adapters 0,1,2) and remove the second adapter, then you only have (in linux) adapters 0 and 2. Even if the device is ejected when vdr is not running, it looks like to me (by reading cDvbDevice::Initialize()) that only adapter 0 is detected by vdr, as the initialize loop stops after adapter 1 is not found... Even though this isn't really a problem for most installations, I wanted to start a thread to give this some thought.
Teemu
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-
Georg Acher -
Teemu Rantanen -
Theunis Potgieter -
Udo Richter -
VDR User