Hi list, hi Klaus,
In continuation of this old topic [1] and the bug ticket [2]:
I've written a patch that changes handling of receivers in VDR. The patch makes sure that receivers of priority of -1 won't block a device, without re-introducing the Live TV Freeze [3] bug.
Details of this issue are very well documented in [2], patches are also available there.
In short, -1 receivers are supposed to be disconnectable at any time, but transfer mode runs at -1 priority too, and should not be disconnected. Transfer mode runs at -1 so that an existing transfer mode does not block channel switching. The solution is to let the channel switch code know that the transfer source device will soon be available.
Cheers,
Udo
[1] http://www.linuxtv.org/pipermail/vdr/2008-June/017073.html [2] http://projects.vdr-developer.org/issues/show/10 [3] http://linuxtv.org/mailinglists/vdr/2004/05-2004/msg00115.html
Hi Udo,
On Sun, 18 Jul 2010 15:45:02 +0200, Udo Richter wrote
In short, -1 receivers are supposed to be disconnectable at any time, but transfer mode runs at -1 priority too, and should not be disconnected. Transfer mode runs at -1 so that an existing transfer mode does not block channel switching. The solution is to let the channel switch code know that the transfer source device will soon be available.
Good shot. Streamdev suffers from a similar problem and would benefit from this patch, too. If a streamdev-client prepars to switch channels, the current stream blocks a device which will also become available a little later. At the moment streamdev temporarily detaches the client's receiver if no other device is able to do the job anyway. With the volatile flag this should no longer be necessary.
Cheers, Frank
Am 19.07.2010 10:44, schrieb Frank Schmirler:
Good shot. Streamdev suffers from a similar problem and would benefit from this patch, too. If a streamdev-client prepars to switch channels, the current stream blocks a device which will also become available a little later. At the moment streamdev temporarily detaches the client's receiver if no other device is able to do the job anyway. With the volatile flag this should no longer be necessary.
My first attempt was less intrusive by specially marking live related receivers and handling them different on device search, but I decided to go the more complex way to solve the search-new-before-disconnect conflict generally. Seems it has a first use already. :)
Cheers,
Udo
-
Frank Schmirler -
Udo Richter