VDR developer version 1.7.24 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.24.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.23-1.7.24.diff
MD5 checksums:
a034c5e399417dfc583483f650d003ee vdr-1.7.24.tar.bz2 aa1a2b202da92e65945ff39470b26618 vdr-1.7.23-1.7.24.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 changes since version 1.7.23:
- Updated the Italian OSD texts (thanks to Diego Pierotto). - Fixed a high load in case a transponder can't be received. - Improved the way DVB_API_VERSION is checked. - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Fixed asserting there is a live programme if the primary device is bonded with a device that starts a recording on a different band. - Fixed the return type of cMyDeviceHook::DeviceProvidesTransponder() in PLUGINS.html. - Fixed a crash in a plugin using cDeviceHook when VDR ends (reported by Oliver Endriss). - Some improvements to the Makefiles (thanks to Christian Ruppert). - Fixed cRecording::LengthInSeconds(), which wrongfully rounded the result to full minutes (thanks to Christoph Haubrich). - Symbolic links are no longer resolved in cRecordings::ScanVideoDir() (thanks to Sundararaj Reel). - The epg.data file is now read in a separate thread to make the startup process faster in case the file is very large (suggested by Helmut Auer). - Fixed selecting the primary device for receiving the live viewing channel in case it is bonded with an other device and has no receiver attached to it. - Fixed a possible crash when canceling VDR while displaying subtitles, and the primary device is no longer available. - Improved handling subtitles of BBC channels. - No longer using tabs as delimiter in the EPG bugfix log (they were garbled in the log file). - Added a missing '.' after the month in VPS strings. - Added some missing 'const' to cDevice (thanks to Joachim Wilke). - Fixed handling the PrimaryLimit when requesting a device for live viewing (reported by Uwe Scheffler). - Removed superfluous calls to SetVideoFormat() from device constructors. This function is called in cDevice::SetPrimaryDevice(), anyway. - An ongoing editing process is now canceled if either the original or the edited version of the recording is deleted from the Recordings menu. - The SVDRP command DELR now won't delete a recording that is currently being edited. - Removed code stub for obsolete SVDRP command MOVT. - The DVB device adapters/frontends are now probed by scanning the /dev/dvb directory instead of looping through adapter/frontend numbers. This allows for "holes" in the device numbering. - cReadDir::Next() now skips directory entries "." and "..". - Fixed a possible deadlock in time shift mode. - Fixed switching into time shift mode when pausing live video (thanks to Reinhard Nissl for helping to debug this one).
Have fun!
Klaus
On 19.02.2012 14:54, Klaus Schmidinger wrote:
VDR developer version 1.7.24 is now available ... ...
- Fixed switching into time shift mode when pausing live video (thanks to Reinhard Nissl for helping to debug this one).
Just realized that on channels with 50fps the info file needs to be re-read to get the actual fps rate after the index file has been written:
--- dvbplayer.c 2012/02/19 10:48:02 2.23 +++ dvbplayer.c 2012/02/19 14:21:22 @@ -291,6 +291,8 @@ delete index; index = NULL; } + else if (PauseLive) + framesPerSecond = cRecording(FileName).FramesPerSecond(); // the fps rate might have changed from the default }
cDvbPlayer::~cDvbPlayer()
Klaus
Hi, when I replay a recording with 1.7.24 and switch several times from replay to fast replay and back, it takes too long until VDR responds to the remote. Happens with old recordings and recordings made with 1.7.24. With 1.7.23 no problem. Jörg
Am 19.02.2012 19:51, schrieb Joerg Riechardt:
Hi, when I replay a recording with 1.7.24 and switch several times from replay to fast replay and back, it takes too long until VDR responds to the remote. Happens with old recordings and recordings made with 1.7.24. With 1.7.23 no problem.
This happens with the vdr-xine plugin only. With softhddevice or xineliboutput it is ok. Jörg
Jörg
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 19.02.2012 20:45, Joerg Riechardt wrote:
Am 19.02.2012 19:51, schrieb Joerg Riechardt:
Hi, when I replay a recording with 1.7.24 and switch several times from replay to fast replay and back, it takes too long until VDR responds to the remote. Happens with old recordings and recordings made with 1.7.24. With 1.7.23 no problem.
This happens with the vdr-xine plugin only. With softhddevice or xineliboutput it is ok. Jörg
It also works fine with the TT S2-6400.
The only thing I could image to be causing this are the changes in dvbplayer.c regarding "Fixed a possible deadlock in time shift mode". Can you please try with dvbplayer.[hc] from version 1.7.23? This will also remove the fix for pausing live video, but that should be independent from this problem.
Oh, and just to make sure: you haven't applied any other patches, have you?
Klaus
Am 19.02.2012 22:04, schrieb Klaus Schmidinger:
On 19.02.2012 20:45, Joerg Riechardt wrote:
Am 19.02.2012 19:51, schrieb Joerg Riechardt:
Hi, when I replay a recording with 1.7.24 and switch several times from replay to fast replay and back, it takes too long until VDR responds to the remote. Happens with old recordings and recordings made with 1.7.24. With 1.7.23 no problem.
This happens with the vdr-xine plugin only. With softhddevice or xineliboutput it is ok. Jörg
It also works fine with the TT S2-6400.
The only thing I could image to be causing this are the changes in dvbplayer.c regarding "Fixed a possible deadlock in time shift mode". Can you please try with dvbplayer.[hc] from version 1.7.23? This will also remove the fix for pausing live video, but that should be independent from this problem.
Oh, and just to make sure: you haven't applied any other patches, have you?
Klaus
With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is ok again. Other patches were not involved. Jörg
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 20.02.2012 00:06, Joerg Riechardt wrote:
Am 19.02.2012 22:04, schrieb Klaus Schmidinger:
On 19.02.2012 20:45, Joerg Riechardt wrote:
Am 19.02.2012 19:51, schrieb Joerg Riechardt:
Hi, when I replay a recording with 1.7.24 and switch several times from replay to fast replay and back, it takes too long until VDR responds to the remote. Happens with old recordings and recordings made with 1.7.24. With 1.7.23 no problem.
This happens with the vdr-xine plugin only. With softhddevice or xineliboutput it is ok. Jörg
It also works fine with the TT S2-6400.
The only thing I could image to be causing this are the changes in dvbplayer.c regarding "Fixed a possible deadlock in time shift mode". Can you please try with dvbplayer.[hc] from version 1.7.23? This will also remove the fix for pausing live video, but that should be independent from this problem.
Oh, and just to make sure: you haven't applied any other patches, have you?
Klaus
With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is ok again. Other patches were not involved. Jörg
Well, then I guess it's best if I revoke that change. Any objections? Or maybe a fix for the vdr-xine problem?
(See also http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/p...).
Klaus
On 2012-02-20 11:18, Klaus Schmidinger wrote:
On 20.02.2012 00:06, Joerg Riechardt wrote:
With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is ok again. Other patches were not involved. Jörg
Well, then I guess it's best if I revoke that change. Any objections? Or maybe a fix for the vdr-xine problem?
It seems that the dxr3 plugin is similarly affected, and reverting to the 1.7.23 versions gets rid of the problem for it as well.
Am 20.02.2012 10:18, schrieb Klaus Schmidinger:
On 20.02.2012 00:06, Joerg Riechardt wrote:
With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is ok again. Other patches were not involved. Jörg
Well, then I guess it's best if I revoke that change. Any objections? Or maybe a fix for the vdr-xine problem?
(See also http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/p...).
I'm also seeing (hearing) reproducible glitches on playback with a TT-6400, on 1.7.24. I've reverted just the changes from the patch at vdr-portal, and the glitches were gone. So +1 for reverting.
For ease of use the attached patch sums up the revert. Because of an indenting issue the original patch doesn't revert cleanly.
Cheers,
Udo
Hi,
On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote
- Fixed handling the PrimaryLimit when requesting a device for live viewing (reported by Uwe Scheffler).
Refers to the following change in device.c: - if (device[i]->ProvidesChannel(Channel, Priority, &ndr)) { // this device is basicly able to do the job + if (device[i]->ProvidesChannel(Channel, (LiveView && device[i]->IsPrimaryDevice()) ? Setup.PrimaryLimit : Priority, &ndr)) { // this device is basicly able to do the job
With this modification the GetDevice parameter Priority becomes meaningless in case LiveView is true. This should at least be mentioned in the function's documentation in device.h.
Anyway, I think a better way to fix the problem would be to change the priority parameter of the GetDevice calls involved from "GetDevice(channel, 0, true)" to "GetDevice(channel, Setup.PrimaryLimit, true)". There are two calls in device.c and one call in menu.c.
Imagine a two card system with PrimaryLimit 20, a high priority recording (e.g. 50) running on the PrimaryDevice and a low priority recording (e.g. 10) on the second card. With 1.7.24 live TV would not interrupt the low priority recording, as PrimaryLimit priority is only used when checking the PrimaryDevice, but priority 0 is used when checking the second card.
The way 1.7.24 resolves the problem is not wrong as according to MANUAL PrimaryLimit is not meant to affect transfer mode. IMHO it should, as the intention of this parameter is prefering LiveTV to low priority recordings. I'm still hoping to get a more priority driven device selection. BTW: Any update on this related issue: http://www.mail-archive.com/vdr@linuxtv.org/msg14166.html?
Regards, Frank
On 24.02.2012 15:37, Frank Schmirler wrote:
Hi,
On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote
- Fixed handling the PrimaryLimit when requesting a device for live viewing (reported by Uwe Scheffler).
Refers to the following change in device.c:
if (device[i]->ProvidesChannel(Channel, Priority,&ndr)) { // thisdevice is basicly able to do the job
if (device[i]->ProvidesChannel(Channel, (LiveView&&device[i]->IsPrimaryDevice()) ? Setup.PrimaryLimit : Priority,&ndr)) { // this device is basicly able to do the job
With this modification the GetDevice parameter Priority becomes meaningless in case LiveView is true. This should at least be mentioned in the function's documentation in device.h.
Anyway, I think a better way to fix the problem would be to change the priority parameter of the GetDevice calls involved from "GetDevice(channel, 0, true)" to "GetDevice(channel, Setup.PrimaryLimit, true)". There are two calls in device.c and one call in menu.c.
Imagine a two card system with PrimaryLimit 20, a high priority recording (e.g. 50) running on the PrimaryDevice and a low priority recording (e.g. 10) on the second card. With 1.7.24 live TV would not interrupt the low priority recording, as PrimaryLimit priority is only used when checking the PrimaryDevice, but priority 0 is used when checking the second card.
The way 1.7.24 resolves the problem is not wrong as according to MANUAL PrimaryLimit is not meant to affect transfer mode. IMHO it should, as the intention of this parameter is prefering LiveTV to low priority recordings. I'm still hoping to get a more priority driven device selection.
IIRC that whole "Primary Limit" thing was introduced because in the beginning the full featured DVB cards were unable to record and play at the same time. So it could happen that a timer occupied the primary device and left the user with a black screen. Since the old FF cards have been given the ability to do simultaneous recording and replay a long time ago, and the new TT S2-6400 has been able to do this from the very start, I'd rather prefer to do away with the "Primary Limit" altogether - to make things simpler instead of more complex ;-)
So, is there anybody who would *really* miss the "Primary Limit" if it were gone?
BTW: Any update on this related issue: http://www.mail-archive.com/vdr@linuxtv.org/msg14166.html?
I assume you are referring to
http://projects.vdr-developer.org/attachments/355/vdr-1.7.12-detachreceiver-...
Well, I don't like the idea of introducing yet another parameter ("volatile") here. The "priority" should be sufficient to solve this. So if you can suggest a solution that works solely with priorities, I might take a look ;-)
Klaus
Am 24.02.2012 17:23, schrieb Klaus Schmidinger:
On 24.02.2012 15:37, Frank Schmirler wrote:
On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote
- Fixed handling the PrimaryLimit when requesting a device for live
viewing (reported by Uwe Scheffler).
Hmmm, didn't even notice that change...
Anyway, I think a better way to fix the problem would be to change the priority parameter of the GetDevice calls involved from "GetDevice(channel, 0, true)" to "GetDevice(channel, Setup.PrimaryLimit, true)". There are two calls in device.c and one call in menu.c.
My 'volatile' patch did this, and it worked so far. I like that a lot more than the 1.7.24 solution that just adds another quirk to the priority system. If in doubt, this should just raise the priority on channel switching. I don't think that it would cause any negative side effects, esp. since this priority is ignored at the end anyway. (see below)
IIRC that whole "Primary Limit" thing was introduced because in the beginning the full featured DVB cards were unable to record and play at the same time. So it could happen that a timer occupied the primary device and left the user with a black screen. Since the old FF cards have been given the ability to do simultaneous recording and replay a long time ago, and the new TT S2-6400 has been able to do this from the very start, I'd rather prefer to do away with the "Primary Limit" altogether - to make things simpler instead of more complex ;-)
Keep in mind that a recording on an un-modded SD-FF device nowadays can cause broken recordings because of limited bandwidth. Being able to record and play at the same time is a rather theoretical ability, especially if its transfer mode playback.
However, I never had PrimaryLimit set to anything but 0.
http://projects.vdr-developer.org/attachments/355/vdr-1.7.12-detachreceiver-...
For description: http://projects.vdr-developer.org/issues/show/10
Well, I don't like the idea of introducing yet another parameter ("volatile") here. The "priority" should be sufficient to solve this. So if you can suggest a solution that works solely with priorities, I might take a look ;-)
That patch actually goes the same way as the above fix, but beside that its more about the detaching issue, and just fixed the PrimaryLimit issue on the way, so its not directly related. Even dropping PrimaryLimit wouldn't solve this issue.
One of the core problems is that VDR selects a new device for live viewing before disconnecting the old live device. Thus, all live related receivers will still be present and will block the current device from being re-used. VDR works around this just because live view has no receivers (FF cards) or -1 priority receivers (transfer mode, subtitles), that are always of lower priority than anything.
As a conequence, VDR has to ignore the '-1 can always be disconnected' rule, or it would also disconnect transfer mode on timers, regardless of free devices. And this leads to the osdteletext issue that the teletext receiver still blocks the device on channel switch. VDR's own receivers also work around this because they get disconnected before doing the final and counting GetDevice call, but plugins cannot do that at that time.
A clean solution should imho do these things: - Fix the find-device-before-disconnecting loop - Transfer mode devices with 'real' priorities - Honor the -1 priority as always-detachable
In the end, you need to know at a very early point (ChUp pressed etc.) whether a device will be available for live view, even if it is still used right now, and might be used on (if ChUp fails).
Letting VDR know that a device will probably soon be detached was one of the smarter solutions to this. Another alternative I was thinking of was to let the device know that a receiver is 'live-related', and thus can be canceled for another live view, but the 'volatile' solution was more general.
Maybe it would be possible to manually lower the transfer mode receivers to -1 when calling GetDevice with live view, and raise them back to PrimaryLimit (or 0) at the end. Not sure if that's more elegant...
Cheers,
Udo
On Fri, 24 Feb 2012 19:33:06 +0100, Udo Richter wrote
Am 24.02.2012 17:23, schrieb Klaus Schmidinger:
IIRC that whole "Primary Limit" thing was introduced because in the beginning the full featured DVB cards were unable to record and play at the same time. So it could happen that a timer occupied the primary device and left the user with a black screen. Since the old FF cards have been given the ability to do simultaneous recording and replay a long time ago, and the new TT S2-6400 has been able to do this from the very start, I'd rather prefer to do away with the "Primary Limit" altogether - to make things simpler instead of more complex ;-)
I was not aware of this as I have no FF card. For me, "Primary Limit" always was the "Priority of Live TV". Ok, MANUAL talks about being allowed to "use the primary DVB interface" and not denial to "affect live TV", but the use case "recordings that should take place only when there is nothing else to do, but should never keep the user from viewing stuff on the primary interface" clearly pointed into that direction.
Always using priority 0 instead of a configurable "Primary Limit" means there's no way to get anything with less priority than live TV but without the "may always be detached" meaning of negative priorities.
Streamdev is using the "Primary Limit" to control priorities between multiple clients and partially also between clients and server. Only "partially" due to transfer mode receiver device running with priority -1. Currently a plugin can't simply call GetDevice with a non-negative priority without disturbing Live TV in transfer mode. Some ugly workarounds were necessary in streamdev to handle this.
Well, I don't like the idea of introducing yet another parameter ("volatile") here. The "priority" should be sufficient to solve this. So if you can suggest a solution that works solely with priorities, I might take a look ;-)
Well, the -1 priority on the transfer mode receiver device solves the "receivers still attached when switching channels" problem. But it introduces an exceptional case which causes problems (osdteletext) or makes apparently simple things hard to handle (streamdev GetDevice). Trading this for an explicit parameter sounds like a very good deal to me.
Letting VDR know that a device will probably soon be detached was one of the smarter solutions to this. Another alternative I was thinking of was to let the device know that a receiver is 'live- related', and thus can be canceled for another live view, but the 'volatile' solution was more general.
Maybe it would be possible to manually lower the transfer mode receivers to -1 when calling GetDevice with live view, and raise them back to PrimaryLimit (or 0) at the end. Not sure if that's more elegant...
+1 for the "volatile" solution. Streamdev-server has to handle channel switches, too. On the server side they are not "live-related", but the problem is the same: The receivers for the previous channel are still attached. "Volatile" would obsolete an other workaround in streamdev.
Regards, Frank
On 25.02.2012 00:21, Frank Schmirler wrote:
On Fri, 24 Feb 2012 19:33:06 +0100, Udo Richter wrote
Am 24.02.2012 17:23, schrieb Klaus Schmidinger:
IIRC that whole "Primary Limit" thing was introduced because in the beginning the full featured DVB cards were unable to record and play at the same time. So it could happen that a timer occupied the primary device and left the user with a black screen. Since the old FF cards have been given the ability to do simultaneous recording and replay a long time ago, and the new TT S2-6400 has been able to do this from the very start, I'd rather prefer to do away with the "Primary Limit" altogether - to make things simpler instead of more complex ;-)
I was not aware of this as I have no FF card. For me, "Primary Limit" always was the "Priority of Live TV". Ok, MANUAL talks about being allowed to "use the primary DVB interface" and not denial to "affect live TV", but the use case "recordings that should take place only when there is nothing else to do, but should never keep the user from viewing stuff on the primary interface" clearly pointed into that direction.
Always using priority 0 instead of a configurable "Primary Limit" means there's no way to get anything with less priority than live TV but without the "may always be detached" meaning of negative priorities.
Streamdev is using the "Primary Limit" to control priorities between multiple clients and partially also between clients and server. Only "partially" due to transfer mode receiver device running with priority -1. Currently a plugin can't simply call GetDevice with a non-negative priority without disturbing Live TV in transfer mode. Some ugly workarounds were necessary in streamdev to handle this.
Well, I don't like the idea of introducing yet another parameter ("volatile") here. The "priority" should be sufficient to solve this. So if you can suggest a solution that works solely with priorities, I might take a look ;-)
Well, the -1 priority on the transfer mode receiver device solves the "receivers still attached when switching channels" problem. But it introduces an exceptional case which causes problems (osdteletext) or makes apparently simple things hard to handle (streamdev GetDevice). Trading this for an explicit parameter sounds like a very good deal to me.
Letting VDR know that a device will probably soon be detached was one of the smarter solutions to this. Another alternative I was thinking of was to let the device know that a receiver is 'live- related', and thus can be canceled for another live view, but the 'volatile' solution was more general.
Maybe it would be possible to manually lower the transfer mode receivers to -1 when calling GetDevice with live view, and raise them back to PrimaryLimit (or 0) at the end. Not sure if that's more elegant...
+1 for the "volatile" solution. Streamdev-server has to handle channel switches, too. On the server side they are not "live-related", but the problem is the same: The receivers for the previous channel are still attached. "Volatile" would obsolete an other workaround in streamdev.
Definitely *no* "volatile"!
PrimaryLimit is going to be dropped, since the old FF-DVB cards can now (since version 1.7.21) be run with the --outputonly option to avoid problems with recording high bandwidth channels. Besides, with HDTV becoming ever more popular those cards are pretty much obsolete by now (the TT S2-6400 has no problems recording and replaying high bandwidth channels simultaneously). And, last but not least, people using software players won't notice this change, anyway.
There was also apparently some misunderstanding about what PrimaryLimit was supposed to do. It was *never* meant to allow "Channel switching can cancel timers with priority <= Setup.PrimaryLimit" (as noted at the bottom of http://projects.vdr-developer.org/issues/show/10). Its sole purpose was to not use the primary device for recording low priority timers and leave the user with a black screen. Those days are long gone, and PrimaryLimit is obsolete and causing nothing but trouble.
A recording shall *always* have priority over live viewing.
Since cReceivers can have priorities between -99 and 99, the priority for an unused device has been changed from -1 to -100.
The attached patch implements all these changes (*.po files left out for clarity). Please try this and let me know if anything doesn't work as expected. I did try running a recording on the primary device, so that live view would be done in Transfer mode from the secondary device (only two devices activated for testing) and had no problem with zapping through channels with Up/Down. I also tried starting a recording on device 2 while in Transfer Mode, and the live channel was switched to device 1 when the recording kicked in.
Klaus
On Sat, 25 Feb 2012 15:39:17 +0100, Klaus Schmidinger wrote
There was also apparently some misunderstanding about what PrimaryLimit was supposed to do. It was *never* meant to allow "Channel switching can cancel timers with priority <= Setup.PrimaryLimit" (as noted at the bottom of http://projects.vdr- developer.org/issues/show/10). Its sole purpose was to not use the primary device for recording low priority timers and leave the user with a black screen. Those days are long gone, and PrimaryLimit is obsolete and causing nothing but trouble.
A recording shall *always* have priority over live viewing.
I would be fine with that with respect to recordings, but this shouldn't be generally true for cReceivers. What I'm hoping to get is the possiblity to attach a cReceiver with a lower priority than live TV but without the "cReceivers with negative priority do not count".
Since cReceivers can have priorities between -99 and 99, the priority for an unused device has been changed from -1 to -100.
Udo Richter's patch basically turned "PrimaryLimit" into a configurable "LiveTV priority". A "LiveTV priority" > 0 gains you cReceivers with a priority less than live TV but still non-negative. To fix the "Transfer mode receiver device has priority -1" problem, he introduced "volatile".
Instead of a configurable "LiveTV priority", your approach uses the fixed priority value 0 for LiveTV. The new idle priority of -100 opens the range for cReceivers with negative priority. The problem is, that *any* negative priority is still considered as "may be detached anytime", so there's still no real "cReceiver with less priority than live TV".
I suggest the following additional changes: - instead of any negative priority, only priority -MAXPRIORITY gets the special meaning of "may be detached anytime" - the constructor of cReceiver should use default priority -MAXPRIORITY, so not all plugins have to be updated to keep their previous behaviour - use LIVEPRIORITY-1 as priority for cTransfer
I can't however overlook the impact these modifications have.
Regards, Frank
On 27.02.2012 14:33, Frank Schmirler wrote:
On Sat, 25 Feb 2012 15:39:17 +0100, Klaus Schmidinger wrote
There was also apparently some misunderstanding about what PrimaryLimit was supposed to do. It was *never* meant to allow "Channel switching can cancel timers with priority<= Setup.PrimaryLimit" (as noted at the bottom of http://projects.vdr- developer.org/issues/show/10). Its sole purpose was to not use the primary device for recording low priority timers and leave the user with a black screen. Those days are long gone, and PrimaryLimit is obsolete and causing nothing but trouble.
A recording shall *always* have priority over live viewing.
I would be fine with that with respect to recordings, but this shouldn't be generally true for cReceivers. What I'm hoping to get is the possiblity to attach a cReceiver with a lower priority than live TV but without the "cReceivers with negative priority do not count".
Since cReceivers can have priorities between -99 and 99, the priority for an unused device has been changed from -1 to -100.
Udo Richter's patch basically turned "PrimaryLimit" into a configurable "LiveTV priority". A "LiveTV priority"> 0 gains you cReceivers with a priority less than live TV but still non-negative. To fix the "Transfer mode receiver device has priority -1" problem, he introduced "volatile".
Instead of a configurable "LiveTV priority", your approach uses the fixed priority value 0 for LiveTV. The new idle priority of -100 opens the range for cReceivers with negative priority. The problem is, that *any* negative priority is still considered as "may be detached anytime", so there's still no real "cReceiver with less priority than live TV".
I suggest the following additional changes:
- instead of any negative priority, only priority -MAXPRIORITY gets the
special meaning of "may be detached anytime"
- the constructor of cReceiver should use default priority -MAXPRIORITY, so
not all plugins have to be updated to keep their previous behaviour
- use LIVEPRIORITY-1 as priority for cTransfer
I can't however overlook the impact these modifications have.
Me neither - and that's why I strongly oppose them ;-)
What exactly is the use case for this, anyway?
VDR has two purposes: "live view" and "recording". And the current priority scheme handles this pretty well IMO.
Klaus
On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote
On 27.02.2012 14:33, Frank Schmirler wrote:
I suggest the following additional changes:
- instead of any negative priority, only priority -MAXPRIORITY gets the
special meaning of "may be detached anytime"
- the constructor of cReceiver should use default priority -MAXPRIORITY, so
not all plugins have to be updated to keep their previous behaviour
- use LIVEPRIORITY-1 as priority for cTransfer
I can't however overlook the impact these modifications have.
Me neither - and that's why I strongly oppose them ;-)
Then maybe it's time to return to KISS - perhaps in VDR 2.1.x? Maybe there's more obsolete stuff which can be thrown overboard. I feel it's time to start from scratch with the device selection code, keeping also the new challenges in mind (like e.g. the HD/SD or DVB-S/-T simulcast thingy).
What exactly is the use case for this, anyway?
VDR has two purposes: "live view" and "recording". And the current priority scheme handles this pretty well IMO.
I guess in the meantime you could add "network streaming" to the list of purposes, too. There are a lots of people using streamdev out there for VDR-to-VDR-, HTTP- or Multicast-Streaming of live TV. Especially the VDR-to-VDR-Streaming part is challenging. The easy case is a headless server somewhere in the attic. No need to care about live TV. But some people's "server" is their main VDR in the living room and they usually want clients with a priority which is lower than local live TV. That's the use case.
At the moment it all works pretty well in streamdev, but the whole thing is quite fragile with respect to API changes, time-consuming to maintain (e.g. an almost 1:1 copy of cDevice::GetDevice) or laborious (e.g. synchronisation with VDR main thread for switching LiveTV). So it's not that streamdev depends on Udo Richter's patch or PrimaryLimit. But I was hoping for some perspective to get rid of some of the most ugly workarounds in the long run. The patch would have been a big step into that direction. Still, for a nice solution some more (but probably much less dramatic) modifications in the VDR core would be necessary.
Regards, Frank
On 28.02.2012 09:32, Frank Schmirler wrote:
On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote
On 27.02.2012 14:33, Frank Schmirler wrote:
I suggest the following additional changes:
- instead of any negative priority, only priority -MAXPRIORITY gets the
special meaning of "may be detached anytime"
- the constructor of cReceiver should use default priority -MAXPRIORITY, so
not all plugins have to be updated to keep their previous behaviour
- use LIVEPRIORITY-1 as priority for cTransfer
I can't however overlook the impact these modifications have.
Me neither - and that's why I strongly oppose them ;-)
Then maybe it's time to return to KISS - perhaps in VDR 2.1.x? Maybe there's more obsolete stuff which can be thrown overboard. I feel it's time to start from scratch with the device selection code, keeping also the new challenges in mind (like e.g. the HD/SD or DVB-S/-T simulcast thingy).
That's surely something I'm going to lok at after version 2.0.
What exactly is the use case for this, anyway?
VDR has two purposes: "live view" and "recording". And the current priority scheme handles this pretty well IMO.
I guess in the meantime you could add "network streaming" to the list of purposes, too. There are a lots of people using streamdev out there for VDR-to-VDR-, HTTP- or Multicast-Streaming of live TV. Especially the VDR-to-VDR-Streaming part is challenging. The easy case is a headless server somewhere in the attic. No need to care about live TV. But some people's "server" is their main VDR in the living room and they usually want clients with a priority which is lower than local live TV. That's the use case.
At the moment it all works pretty well in streamdev, but the whole thing is quite fragile with respect to API changes, time-consuming to maintain (e.g. an almost 1:1 copy of cDevice::GetDevice) or laborious (e.g. synchronisation with VDR main thread for switching LiveTV). So it's not that streamdev depends on Udo Richter's patch or PrimaryLimit. But I was hoping for some perspective to get rid of some of the most ugly workarounds in the long run. The patch would have been a big step into that direction. Still, for a nice solution some more (but probably much less dramatic) modifications in the VDR core would be necessary.
I'll keep this in mind for "after version 2.0".
Klaus
On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
On 28.02.2012 09:32, Frank Schmirler wrote:
On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote
On 27.02.2012 14:33, Frank Schmirler wrote:
I can't however overlook the impact these modifications have.
Me neither - and that's why I strongly oppose them ;-)
Then maybe it's time to return to KISS - perhaps in VDR 2.1.x?
Oups - this principle is good to start on any date. Best would be start using it today :)
Maybe there's more obsolete stuff which can be thrown overboard. I feel it's time to start from scratch with the device selection code, keeping also the new challenges in mind (like e.g. the HD/SD or DVB-S/-T simulcast thingy).
This is only one aspect, that really needs to be redesigned / completely rewritten from scratch.
What exactly is the use case for this, anyway?
VDR has two purposes: "live view" and "recording". And the current priority scheme handles this pretty well IMO.
I guess in the meantime you could add "network streaming" to the list of purposes, too.
Sure!
But talking about future, I think a good VDR-design would be a real client/server-design. Or lets say a modern VDR consists of a backend and a frontend, which may run on different machines, but may also be run on the same machine.
So networking is evident and vital.
If I understand things right, the decoding of streams is a frontend task, so it would be possible to abstract all datasources as input. That means, streams may come from dvb-card, network, files (any file, that might contain stream data) and of cause from plugins, that might generate streams from pictures or the like.
So the backend (beside the recording/timer part) just uniforms the streams and makes them available via network. Frontend demuxes/decodes the streams (if necessary) and routes them to the real output devices.
Taking into account, that networking can be broadcasted via UDP or streamed over single TCP-connection, it implies that different frontends might use the same stream from backend or each frontend might use a different stream. That also implies a complete different handling of setup and/or input/commands from frontend.
If connection between backend- and frontend-vdr could be established over network, as well as using shared memory, the 2 parts could behave like one, if they were run on the same machine.
With that design, vdr could handle all media, that make sense respect to looking and listening, so no more need for xbmc and other hacks ;)
At the moment it all works pretty well in streamdev, ...
As far as I understood available docs, streamdev is not able to handle recordings, so I would not say "all works"
I'll keep this in mind for "after version 2.0".
Why so far?
I think, many vdr-users crave for redesign and I'm sure, that some users are willing to participate.
kind regards
Gero
On 28/02/12 10:24, Gero wrote:
At the moment it all works pretty well in streamdev, ...
As far as I understood available docs, streamdev is not able to handle recordings, so I would not say "all works"
Streamdev does work fine for recordings. However, I tend to use e-tobi's fuse filesystem to export the recordings dir over NFS
On 02/28/2012 11:24 AM, Gero wrote:
I think, many vdr-users crave for redesign and I'm sure, that some users are willing to participate.
I drooped vdr in favor of tvheadend just for many of the design reason you mentioned:
1) Clear backend/front end design, 2) Better network protocol between the two, 3) code simplicity
So look at the features and principles when redesigning.
-- eric
On Dienstag 28 Februar 2012, Eric Valette wrote:
On 02/28/2012 11:24 AM, Gero wrote:
I think, many vdr-users crave for redesign and I'm sure, that some users are willing to participate.
I drooped vdr in favor of tvheadend just for many of the design reason ...
Whow - I'm impressed ;)
Installation and configuration (!) - really sexy.
... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR, so I think it could be a good template for future vdr-development, but not serve as a vdr-replacement. At least I think, that OSD is a must have.
Generation of channel-list - so fast and easy (just few mouseclicks) - I never could imagine such an ease of usage.
I think it would be hard to beat that configuration in ease of use, flexibility and supported variants. With the webinterface its already ready for using android as remote :O
challenging goal ;)
kind regards
Gero
On 02/28/2012 03:08 PM, Gero wrote:
... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR, so I think it could be a good template for future vdr-development, but not serve as a vdr-replacement.
Well openelec distrib does have means to use tvheadend...
At least I think, that OSD is a must have.
I prefer to have it in a front end that is able to manage a sophisticated remote correctly.
--eric
Eric Valette Eric.Valette@Free.fr writes:
On 02/28/2012 03:08 PM, Gero wrote:
... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR, so I think it could be a good template for future vdr-development, but not serve as a vdr-replacement.
Well openelec distrib does have means to use tvheadend...
At least I think, that OSD is a must have.
I prefer to have it in a front end that is able to manage a sophisticated remote correctly.
what do you use as a frontend ? xbmc, showtime ? is it possible to have multiple independant osd ? i like the xine and xinelibouput plugins way a lot, on my laptop no need to install a huge (and sometimes bloaty) media center, just have to run xine or vdr-sxfe and it comes with tv+osd+remote.
On 02/28/2012 03:49 PM, syrius.ml@no-log.org wrote:
Eric ValetteEric.Valette@Free.fr writes:
On 02/28/2012 03:08 PM, Gero wrote:
... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR, so I think it could be a good template for future vdr-development, but not serve as a vdr-replacement.
Well openelec distrib does have means to use tvheadend...
At least I think, that OSD is a must have.
I prefer to have it in a front end that is able to manage a sophisticated remote correctly.
what do you use as a frontend ? xbmc, showtime ?
I use XBMC in general, but may also use mplayer or vlc using the http streaming URL from the web GUI.
is it possible to have multiple independant osd ?
You mean not on the same machine right?
i like the xine and xinelibouput plugins way a lot, on my laptop no need to install a huge (and sometimes bloaty) media center, just have to run xine or vdr-sxfe and it comes with tv+osd+remote.
The tvheadend HTSP streaming library is really thin. I guess integrating it is like integrating a streamdev client/vnsi client.
-- eric
Hi,
On Tuesday 28 February 2012 - 15:49:32, syrius.ml@no-log.org wrote:
i like the xine and xinelibouput plugins way a lot, on my laptop no need to install a huge (and sometimes bloaty) media center, ...
Agreed! That's why I like vdr-sxfe. On standard distributions one file to install and it works out of the box.
Even a self-compiled frontend with fresh home-brewed xinelib is not a big thing and works without having to touch anything on the backend ... I can't do the same with xine, which is already somewhat bloated too.
So, Yes - that's why I like my current VDR-setup :)
kind regards
Gero
28.02.2012 12:24, Gero kirjoitti:
On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
On 28.02.2012 09:32, Frank Schmirler wrote:
On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote
What exactly is the use case for this, anyway?
VDR has two purposes: "live view" and "recording". And the current priority scheme handles this pretty well IMO.
I guess in the meantime you could add "network streaming" to the list of purposes, too.
Sure!
But talking about future, I think a good VDR-design would be a real client/server-design. Or lets say a modern VDR consists of a backend and a frontend, which may run on different machines, but may also be run on the same machine.
So networking is evident and vital.
If I understand things right, the decoding of streams is a frontend task, so it would be possible to abstract all datasources as input. That means, streams may come from dvb-card, network, files (any file, that might contain stream data) and of cause from plugins, that might generate streams from pictures or the like.
So the backend (beside the recording/timer part) just uniforms the streams and makes them available via network. Frontend demuxes/decodes the streams (if necessary) and routes them to the real output devices.
Taking into account, that networking can be broadcasted via UDP or streamed over single TCP-connection, it implies that different frontends might use the same stream from backend or each frontend might use a different stream. That also implies a complete different handling of setup and/or input/commands from frontend.
If connection between backend- and frontend-vdr could be established over network, as well as using shared memory, the 2 parts could behave like one, if they were run on the same machine.
With that design, vdr could handle all media, that make sense respect to looking and listening, so no more need for xbmc and other hacks ;)
I'd very much like something that would result in a better-behaving server-client VDR system, i.e. so that clients just see the recordings,timers,channels,epg just like they are on the server, instead of duplication and the mess when they get out-of-sync.
I guess Klaus wants to keep VDR working as a monolithic entity like it currently is, though, but maybe a "thin-client" (VDR instance with viewing+menu only, with timers/recordings/channels transmitted from the main VDR instance) support could be added as an optional feature.
(and probably a similar "headless" option to have VDR without current-channel and GUI and stuff like that, for the backend)
At the moment it all works pretty well in streamdev, ...
As far as I understood available docs, streamdev is not able to handle recordings, so I would not say "all works"
I'll keep this in mind for "after version 2.0".
Why so far?
Because 1.6.0 was released a long time ago, and we want a new stable version soon? :)
I think, many vdr-users crave for redesign and I'm sure, that some users are willing to participate.
On Tuesday 28 February 2012 - 20:12:54, Anssi Hannula wrote:
28.02.2012 12:24, Gero kirjoitti:
On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
I'll keep this in mind for "after version 2.0".
Why so far?
Because 1.6.0 was released a long time ago, and we want a new stable version soon? :)
Sure! - But next stable version would be 1.8 - wouldn't it?
So why no start redeeming pledges with 1.9? I believe any day would be a good point to start :)
...or is it preferable see people move to real client/server systems and make them fit their every day requirements? Networking has become familiar to lots of people without any IT background - nowadays lot of homes have a fritzbox with Wlan and a netbook with wlan too. Fritzbox has startet to integrate android phones with wlan - so that all is quite natural for non IT people yet.
So integrating a headless vdr into existing network is no more restricted to nerds (or at least every male teenager is a nerd).
kind regards
Gero
On Wed, 29 Feb 2012 05:38:06 +0100 Gero geronimo013@gmx.de wrote:
On Tuesday 28 February 2012 - 20:12:54, Anssi Hannula wrote:
28.02.2012 12:24, Gero kirjoitti:
On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
I'll keep this in mind for "after version 2.0".
Why so far?
Because 1.6.0 was released a long time ago, and we want a new stable version soon? :)
Sure! - But next stable version would be 1.8 - wouldn't it?
Next stable will be 2.0 AFAIK ...
On 29.02.2012 08:17, Steffen Barszus wrote:
On Wed, 29 Feb 2012 05:38:06 +0100 Gerogeronimo013@gmx.de wrote:
On Tuesday 28 February 2012 - 20:12:54, Anssi Hannula wrote:
28.02.2012 12:24, Gero kirjoitti:
On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
I'll keep this in mind for "after version 2.0".
Why so far?
Because 1.6.0 was released a long time ago, and we want a new stable version soon? :)
Sure! - But next stable version would be 1.8 - wouldn't it?
Next stable will be 2.0 AFAIK ...
Yes, the next stable version will be 2.0. Version 1.0 was the "SD version", and version 2.0 shall be the "HD version" ;-).
I'll see to make "client/server" a priority after that.
Klaus
Klaus Schmidinger wrote:
Yes, the next stable version will be 2.0. Version 1.0 was the "SD version", and version 2.0 shall be the "HD version" ;-).
I'll see to make "client/server" a priority after that.
What does this mean? Do you plan built-in networking support or do you plan to improve streamdev? IMHO it is a big task to make really good networking support. Keeping this code separate (means: A plugin) isn't a that bad idea, I think. Of course, this plugin could be delivered directly with VDR, like the other "built-in" plugins.
Yours
Manuel
On 29.02.2012 16:48, Manuel Reimer wrote:
Klaus Schmidinger wrote:
Yes, the next stable version will be 2.0. Version 1.0 was the "SD version", and version 2.0 shall be the "HD version" ;-).
I'll see to make "client/server" a priority after that.
What does this mean? Do you plan built-in networking support or do you plan to improve streamdev? IMHO it is a big task to make really good networking support. Keeping this code separate (means: A plugin) isn't a that bad idea, I think. Of course, this plugin could be delivered directly with VDR, like the other "built-in" plugins.
I'll cross that bridge when I get there ;-)
Klaus
On Wed, 29 Feb 2012 16:48:33 +0100 Manuel Reimer manuel.reimer@gmx.de wrote:
Klaus Schmidinger wrote:
Yes, the next stable version will be 2.0. Version 1.0 was the "SD version", and version 2.0 shall be the "HD version" ;-).
I'll see to make "client/server" a priority after that.
What does this mean? Do you plan built-in networking support or do you plan to improve streamdev? IMHO it is a big task to make really good networking support. Keeping this code separate (means: A plugin) isn't a that bad idea, I think. Of course, this plugin could be delivered directly with VDR, like the other "built-in" plugins.
I don't think a plugin is enough. For better client-server VDR needs to support multiple clients watching different channels with different OSDs simultaneously.
On Wednesday 29 February 2012 - 17:50:27, Tony Houghton wrote:
On Wed, 29 Feb 2012 16:48:33 +0100 Manuel Reimer manuel.reimer@gmx.de wrote:
Klaus Schmidinger wrote:
Yes, the next stable version will be 2.0. Version 1.0 was the "SD version", and version 2.0 shall be the "HD version" ;-).
I'll see to make "client/server" a priority after that.
What does this mean? Do you plan built-in networking support or do you plan to improve streamdev? IMHO it is a big task to make really good networking support. Keeping this code separate (means: A plugin) isn't a that bad idea, I think. Of course, this plugin could be delivered directly with VDR, like the other "built-in" plugins.
I don't think a plugin is enough.
I agree.
I think, it is evident not confuse plugin-networking with client/server networking. OK, currently the client/server support works only through plugins, as there is no vdr-frontend - but Klaus should not care about plugin- networking on designing client/server functionality.
C/S-communication should be completely private to vdr - just like internal communication. Plugins may keep on doing their networking, i.e. to connect other frontends like xine or whatever - but that's not the internal communication, vdr relies on.
For better client-server VDR needs to support multiple clients watching different channels with different OSDs simultaneously.
Yeah, that would be very nice :)
kind regards
Gero
Am 29.02.2012 17:50, schrieb Tony Houghton:
On Wed, 29 Feb 2012 16:48:33 +0100 Manuel Reimer manuel.reimer@gmx.de wrote:
What does this mean? Do you plan built-in networking support or do you plan to improve streamdev? IMHO it is a big task to make really good networking support. Keeping this code separate (means: A plugin) isn't a that bad idea, I think. Of course, this plugin could be delivered directly with VDR, like the other "built-in" plugins.
I don't think a plugin is enough. For better client-server VDR needs to support multiple clients watching different channels with different OSDs simultaneously.
Not necessarily. I think the key solution is to modularize VDR's internal structures, with well defined interfaces between them. A receiving module that provides stream sources, a recording module that does all the timer work, a frontend module that can display, a storage module that can store and provide videos, for example. A timer menu that belongs to a recording backend, a recording menu that displays content of storage modules, several frontends that can connect to one recording backend or several storage modules, and all can connect to different sources.
With defined and pluggable structures between them, its easy to have them either locally connected or linked over network. Whether that's done by a plugin or VDR internally doesn't matter.
In any case this would be the biggest rewrite of major parts of VDR ever, with lots of breakage, total loss of plugin compatibility and very long development cycle.
Cheers,
Udo
On Wednesday 29 February 2012 - 20:45:54, Udo Richter wrote:
Am 29.02.2012 17:50, schrieb Tony Houghton:
For better client-server VDR needs to support multiple clients watching different channels with different OSDs simultaneously.
Not necessarily. I think the key solution is to modularize VDR's internal structures, with well defined interfaces between them.
Well, that task is overdue, but not necessary to provide real a C/S app. But I think, the C/S task is easier to workout after a complete redesign and modularization. Additionally the modules should be grouped by layers, which makes design cleaner.
A timer menu that belongs to a recording backend, a recording menu that displays content of storage modules, several frontends that can connect to one recording backend or several storage modules, ...
I think, here is already the first shortcoming in design. May be cause you're thinking with today plugins in mind? If several independent clients open a timer menu, they should not interfere each other. If the menu is tied to the recording module (which should be a singleton), timer-menu would be like a singleton and a keystroke of one client changes the menu of all other clients too. That's not desired.
Therefore menu representation should be decoupled from menu data, so i.e. the recording module (as all backend modules) provides their data (the timer-list) as list or tree structure only.
The vdr provides a menu for each client, which is based on the same (singleton) list of timers. This way, each client can operate independently and if one client changes a timer, every other client will see the change - but no client is disturbed by the actions of other clients.
So from my point of view, future design will have different types of plugins, like backend- and frontend-plugin (or name the plugin templates by the layer they belong to). They might have the same interface, but I think, it is better to differ the interfaces, so a plugin cannot be misused by accident. So backend-plugin (like nowadays dvdswitch) will only be allowed to provide a list of items, which will be used by OSD-Providers, that will create a menu different for each client and of cause, each menu can have different/independent state. For configuration a backend module may only say, I need an integer value called "value", ranged from 0 to 5 with default of 2 - and it is up to the OSD- painter (skin), whether to use a slider or an input field, or what ever ... The backend module should not be allowed to care about user input elements.
Thinking about configuration, the backend should be able to configure the number of possible clients and so the open ports.
When a client connects, the vdr looks for a free input-module, that serves life-stream. Having multiple independent clients, the command to change the channel should not have any side-effect to other clients, nor disturb an active recording.
Additionally it should be possible to configure the preferred input device used by this client for life-view. Other devices may be configured as fallback, in case the preferred device is not available. For FF-clients it is evident to have a preferred input device without any fallback. I think, this way no further distinction between FF-client and other clients is necessary.
With defined and pluggable structures between them, its easy to have them either locally connected or linked over network. Whether that's done by a plugin or VDR internally doesn't matter.
Oh - I think it does matter!
As I already wrote, from my point of view, plugins may continue do networking, but the connection between backend- and frontend-part of vdr should not be public nor affected by any plugin. And the connection does not have to be tied to networking. Networking is just one implementation of internal communication, which could easily replaced by a communication, that uses shared memory or pipes or what ever - if backend and frontend reside at the same machine. So modules of internal connection may be interchangeable, but they should be considered private to vdr-core.
Don't know, whether it makes sense to look a existing C/S protocols. If I got it right, there's no standard for it and each plugin uses its own protocol. C/S networking needs one channel for streaming from server to client and one channel for commands from client to server. This 2-channel networking is standard for any networking, so I don't see, where networking is a challenge. It might be the smallest and easiest part of the redesign.
Real challenge is the break down and distribution of responsibility.
In any case this would be the biggest rewrite of major parts of VDR ever, with lots of breakage, total loss of plugin compatibility and very long development cycle.
:) so the earlier this task starts, the earlier it may finish :)
kind regards
Gero
Am 01.03.2012 06:37, schrieb Gero:
A timer menu that belongs to a recording backend, a recording menu that displays content of storage modules, several frontends that can connect to one recording backend or several storage modules, ...
I think, here is already the first shortcoming in design. May be cause you're thinking with today plugins in mind?
You got me wrong on that. My vision would be that timer UI and recording backend are two modules, and in a more complex environment there may be several UI frontends connected to one (or more?) recording backends. Any client should be able to edit timers on the server independently, the backend shouldn't even have any UI.
In fact, any UI should be located in the frontend. For all sxfe fans: A frontend implementation itself could split into two parts, one server-side frontend, and one lightweight stream&OSD display. Or keep latency low and put a more complex frontend on the client, that acts independently of the server backend.
A high-level frontend could connect to one or more receiver backends to get channels on demand, would be able to schedule timers on recording backend(s), and would be able to play back from storage sources. Why not allow a storage plugin to act as a media player instead of just VDR recording server? Or on-the-fly transcoding on recording?
Additionally it should be possible to configure the preferred input device used by this client for life-view. Other devices may be configured as fallback, in case the preferred device is not available.
Thought of that. Generally, the default link between video frontend and receiver backend should be handled like transfer mode, to make things more unique. For the case of FF cards, there could be an additional prefer-this-backend-for-this-frontend rule, and a shortcut in transfer control that routes the video stream within the card instead of user space.
As I already wrote, from my point of view, plugins may continue do networking, but the connection between backend- and frontend-part of vdr should not be public nor affected by any plugin.
Well, I have a different vision: More like recording server and streaming client, where all the UI logic resides in the client, and the server doesn't need to know about UI at all. One advantage: Allow a frontend to connect to more than one backend. For example, have two 'full' VDR systems with receivers, recording capabilities and storage, and some streaming clients. And then let each of them use any receiver, any recording capability, and any recording storage that is available.
As said, the server itself could spawn several clients, so sxfe-like lightweight viewers can connect to it. There could also be shortcuts if backends are on the same machine or in the same executable, so not everything must go over network.
However, thats all pretty much vision and far from being reality.
Cheers,
Udo
On Wed, Feb 29, 2012 at 11:45 AM, Udo Richter udo_richter@gmx.de wrote:
In any case this would be the biggest rewrite of major parts of VDR ever, with lots of breakage, total loss of plugin compatibility and very long development cycle.
It's not a small task, but I believe the end product will be well worth the effort. VDR has the benefit of having coder support. If people are willing (as I think they would be), one option to spread the workload could be Klaus assigning different portions to different contributors that would like to work on it. If Klaus is clear about what he wants and is in good communication with other coders, perhaps it could become more of a team effort with Klaus as team captain.. It's a lot of work but there's no reason it should take years to complete either. Especially if the design is well-thought out ahead of time.
As far as plugin breakage.. I would expect there to be some growing pains and plugin maintainers needing to fix/add support for this is just a necessary part of the progression. Keep in mind, people have been wishing for VDR to go this route for quite a while so even if it means extra work fixing plugins, I think you'll find more people welcoming this change than not.
Am 01.03.2012 07:03, schrieb VDR User:
one option to spread the workload could be Klaus assigning different portions to different contributors that would like to work on it. If Klaus is clear about what he wants and is in good communication with other coders, perhaps it could become more of a team effort with Klaus as team captain..
The number of Klaus per VDR has always been quite limited. A developer team would surely speed things up, but I also understand that Klaus prefers to keep all development in his own hands instead of delegating and supervising. Letting 'his baby' off the hook isn't easy, and I would understand if he prefers to keep it under control.
Cheers,
Udo
On Thu, Mar 1, 2012 at 12:12 PM, Udo Richter udo_richter@gmx.de wrote:
Am 01.03.2012 07:03, schrieb VDR User:
one option to spread the workload could be Klaus assigning different portions to different contributors that would like to work on it. If Klaus is clear about what he wants and is in good communication with other coders, perhaps it could become more of a team effort with Klaus as team captain..
The number of Klaus per VDR has always been quite limited. A developer team would surely speed things up, but I also understand that Klaus prefers to keep all development in his own hands instead of delegating and supervising. Letting 'his baby' off the hook isn't easy, and I would understand if he prefers to keep it under control.
I'm not talking about him releasing control of anything. I'm talking about people wanting & willing to help develope, being assigned a code task and parameters. When the work is complete, Klaus reviews and either accepts/merges, or instructs the coder what needs to be changed. There's no reason for Klaus to release control of anything in this model. As long as there's a clear instruction of what he wants, and good communication along the way, I can't think of any good reason against it.
In a sense this already happens, just on a smaller scale. VDR already contains non-Klaus code. Surely there's a middle ground where development can be assisted because in reality this doesn't need to take forever. Nobody expects it to be finished in a week, but it doesn't need to take forever either.
On 01.03.2012 22:17, VDR User wrote:
On Thu, Mar 1, 2012 at 12:12 PM, Udo Richterudo_richter@gmx.de wrote:
Am 01.03.2012 07:03, schrieb VDR User:
one option to spread the workload could be Klaus assigning different portions to different contributors that would like to work on it. If Klaus is clear about what he wants and is in good communication with other coders, perhaps it could become more of a team effort with Klaus as team captain..
The number of Klaus per VDR has always been quite limited. A developer team would surely speed things up, but I also understand that Klaus prefers to keep all development in his own hands instead of delegating and supervising. Letting 'his baby' off the hook isn't easy, and I would understand if he prefers to keep it under control.
I'm not talking about him releasing control of anything. I'm talking about people wanting& willing to help develope, being assigned a code task and parameters. When the work is complete, Klaus reviews and either accepts/merges, or instructs the coder what needs to be changed. There's no reason for Klaus to release control of anything in this model. As long as there's a clear instruction of what he wants, and good communication along the way, I can't think of any good reason against it.
In a sense this already happens, just on a smaller scale. VDR already contains non-Klaus code. Surely there's a middle ground where development can be assisted because in reality this doesn't need to take forever. Nobody expects it to be finished in a week, but it doesn't need to take forever either.
Guys, *please*! I stated earlier that I am currently concentrating on making a stable version 2.0, and that I will see to make client/server a priority *after* that. This discussion at the moment is rather distracting for me, because I do read each posting but don't want to add to this topic right now. I was hoping that, by saying I'll deal with client/server after version 2.0, this topic could be put to rest for the moment. Unfortunately the exact opposite has happened. Another lession learned... ;-)
Klaus
Am 01.03.2012 22:25, schrieb Klaus Schmidinger:
Guys, *please*! I stated earlier that I am currently concentrating on making a stable version 2.0, and that I will see to make client/server a priority *after* that.
Agreed, lets focus on 2.0 for now. We just got carried away dreaming of VDR 3.0 already. ;)
Its never too early to dream tho'...
Cheers,
Udo
On Thu, 01 Mar 2012 22:12:19 +0100 Manuel Reimer manuel.reimer@gmx.de wrote:
Tony Houghton wrote:
I don't think a plugin is enough. For better client-server VDR needs to support multiple clients watching different channels with different OSDs simultaneously.
It just has to deliver the data. The OSD itself is created by the client.
That's how most other TV software works, but if you count VDR itself as "server" and vdr-sxfe as "client" then my understanding is that the server generates the OSD and the client just renders the pixmap it gets from the server. That wouldn't necessarily have to change if and when VDR goes fully client-server, but if I was implementing something from scratch I'd prefer to do the rendering on the client. It would reduce server load and network traffic, and be more logical to my mind. And free up more of Klaus' time to concentrate on core functionality while other people can add bling :-).
Going off on a tangent, there's been some discussion about "Pause and rewind live TV". That could be implemented fairly easily in clients with a big RAM buffer, without adding any complexity to the server.
On Wed, Feb 29, 2012 at 12:20 AM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
Yes, the next stable version will be 2.0. Version 1.0 was the "SD version", and version 2.0 shall be the "HD version" ;-).
Sounds good! :)
I'll see to make "client/server" a priority after that.
I honestly had to read this a couple times to make sure I wasn't misunderstanding some how. This is a huge announcement and I think everyone will agree a big step in the right direction to suit modern needs. Since it sounds like true server/client will really happen for VDR now, maybe it would be a wise idea to start a dedicated thread to it for collecting information on identifying the needs/wants, and ways they can be met. This is a great opportunity to thoroughly think things through so the actual server/client design & integration addresses all the necessary considerations.
...What an awesome way to start off the day! You're my hero Klaus! :D
On 2.3.2012 12:17, Pertti Kosunen wrote:
It would be great if next stable could include ttxtsubs-plugin readiness, i.e. recording/viewing teletext subtitles would not require patching of main VDR code anymore.
It would be also great if next stable could include mainmenuhooks-patch so extrecmenu- and epgsearch-plugins would not require patching VDR code anymore.
Am 02.03.2012 11:35, schrieb Jarkko Kangas:
On 2.3.2012 12:17, Pertti Kosunen wrote:
It would be great if next stable could include ttxtsubs-plugin readiness, i.e. recording/viewing teletext subtitles would not require patching of main VDR code anymore.
It would be also great if next stable could include mainmenuhooks-patch so extrecmenu- and epgsearch-plugins would not require patching VDR code anymore.
It would be also great if next stable would include the other 13 patches that I regularly use, but I doubt it. Throwing every wish into it would probably delay it forever, esp. for patches like mainmenuhooks that is planned to be superseded by more general planned changes at some point.
Cheers,
Udo
Because 1.6.0 was released a long time ago, and we want a new stable version soon? :)
I agree, 1.7 devel versions have many nice improvements like the support for hvr-4000's multiple frontends in same adapter. Even thought most active users in this mail list very likely uses developer versions, there are probably lot of users still using stable 1.6.0 and would also prefer to run the Next stable once released.
But I hope that the mentioned real client-server redesign that could handle many simultaneous clients watching different streams would be then the main goals next version after that. Current way of doing it at least with xineliboutput is just too complex and error prone.
Mika
On Wednesday 29 February 2012 05:58:21 Mika Laitio wrote:
Because 1.6.0 was released a long time ago, and we want a new stable version soon? :)
I agree, 1.7 devel versions have many nice improvements like the support for hvr-4000's multiple frontends in same adapter. Even thought most active users in this mail list very likely uses developer versions, there are probably lot of users still using stable 1.6.0 and would also prefer to run the Next stable once released.
And the Linux distributions will generally only package 'stable' versions.
On 29.02.2012 08:24, Dave wrote:
And the Linux distributions will generally only package 'stable' versions.
For Debian I'm already packaging 1.7.x, because 1.6 became pretty much useless nowadays. Wheezy is going to freeze in June and I hope that VDR becomes stable until then.
Tobias
29.02.2012 10:30, Tobi kirjoitti:
On 29.02.2012 08:24, Dave wrote:
And the Linux distributions will generally only package 'stable' versions.
For Debian I'm already packaging 1.7.x, because 1.6 became pretty much useless nowadays. Wheezy is going to freeze in June and I hope that VDR becomes stable until then.
For Mageia (upcoming mga2) I just recently updated the packages to 1.7.x, and Fedora seems to also be shipping 1.7.x already.
Am 27.02.2012 14:33, schrieb Frank Schmirler:
Instead of a configurable "LiveTV priority", your approach uses the fixed priority value 0 for LiveTV. The new idle priority of -100 opens the range for cReceivers with negative priority. The problem is, that *any* negative priority is still considered as "may be detached anytime", so there's still no real "cReceiver with less priority than live TV".
Unfortunately not, because "may be detached anytime" is intentionally broken since VDR 1.3.7 (2004). Fixing it would reintroduce the "Live TV freeze on recording start" bug. Extending this to priorities down to -99 doesn't change anything, and I currently see no real advantage in it: Why would someone want an unimportant stream with priority -10, and another with -20? VDR itself doesn't use them, so anything below 0 would be the same.
Maybe, with some ugly hacks, Streamdev could emulate the old PrimaryLimit by adding some kind of priority offset to all streams, but as long as the rest is all broken, there's no real point in it.
- instead of any negative priority, only priority -MAXPRIORITY gets the
special meaning of "may be detached anytime"
See above. Would require transfer mode to run on -99 too, otherwise would re-introduce live TV freeze.
- the constructor of cReceiver should use default priority -MAXPRIORITY, so
not all plugins have to be updated to keep their previous behaviour
- use LIVEPRIORITY-1 as priority for cTransfer
Such -1 offset workarounds usually don't work, I would prefer not to have them. For example, one transfer device can still block another before detaching or via Streamdev. The only consistent solution is to give transfer mode the same priority as primary device live priority, either PrimaryLimit or 0.
Cheers,
Udo
On Mon, 27 Feb 2012 21:29:44 +0100, Udo Richter wrote
Am 27.02.2012 14:33, schrieb Frank Schmirler:
Instead of a configurable "LiveTV priority", your approach uses the fixed priority value 0 for LiveTV. The new idle priority of -100 opens the range for cReceivers with negative priority. The problem is, that *any* negative priority is still considered as "may be detached anytime", so there's still no real "cReceiver with less priority than live TV".
Unfortunately not, because "may be detached anytime" is intentionally broken since VDR 1.3.7 (2004). Fixing it would reintroduce the "Live TV freeze on recording start" bug.
Ah, I see. The "Receiving(true)" in cDvbDevice::ProvidesChannel which came in with 1.3.8. That was the missing piece. Thanks for pointing me there.
- the constructor of cReceiver should use default priority -MAXPRIORITY, so
not all plugins have to be updated to keep their previous behaviour
- use LIVEPRIORITY-1 as priority for cTransfer
Such -1 offset workarounds usually don't work, I would prefer not to have them. For example, one transfer device can still block another before detaching or via Streamdev. The only consistent solution is to give transfer mode the same priority as primary device live priority, either PrimaryLimit or 0.
That was an attempt to get a solution without "volatile". A "don't ever use priority "PrimaryLimit" (or 0) elsewhere" would have been better than nothing.
Regards, Frank
I'm included in the list of people that wished VDR supported real server/client. I don't mean hacks and workarounds but real true support, which of course means a major redesign. I know several users who hated to but left VDR because it lacks this. Bringing VDR to modern times/needs would be absolutely great but based on previous posts it seems very unlikely this is going to happen. :(
Then again it looked like Klaus would never give HD & non-FF priority and that need was meet so who knows?
On 28.02.2012 16:48, Frank Schmirler wrote:
On Mon, 27 Feb 2012 21:29:44 +0100, Udo Richter wrote
Am 27.02.2012 14:33, schrieb Frank Schmirler:
Instead of a configurable "LiveTV priority", your approach uses the fixed priority value 0 for LiveTV. The new idle priority of -100 opens the range for cReceivers with negative priority. The problem is, that *any* negative priority is still considered as "may be detached anytime", so there's still no real "cReceiver with less priority than live TV".
Unfortunately not, because "may be detached anytime" is intentionally broken since VDR 1.3.7 (2004). Fixing it would reintroduce the "Live TV freeze on recording start" bug.
Ah, I see. The "Receiving(true)" in cDvbDevice::ProvidesChannel which came in with 1.3.8. That was the missing piece. Thanks for pointing me there.
- the constructor of cReceiver should use default priority -MAXPRIORITY, so
not all plugins have to be updated to keep their previous behaviour
- use LIVEPRIORITY-1 as priority for cTransfer
Such -1 offset workarounds usually don't work, I would prefer not to have them. For example, one transfer device can still block another before detaching or via Streamdev. The only consistent solution is to give transfer mode the same priority as primary device live priority, either PrimaryLimit or 0.
That was an attempt to get a solution without "volatile". A "don't ever use priority "PrimaryLimit" (or 0) elsewhere" would have been better than nothing.
Even though VDR itself doesn't have the necessity for "remote receivers" (yet), I see the problem for streamdev. I have therefore reconsidered this matter and will make the following changes for the next developer version:
- Revised priority handling to allow receivers with a priority that is lower than that of live viewing (with suggestions from Frank Schmirler): + An idle device (one that is not used for live viewing and has no receiver attached to it) now has priority IDLEPRIORITY (-100). + An unused CAM slot now has priority IDLEPRIORITY. + The default priority of a cReceiver is now MINPRIORITY (-99). + A device that is used only for live viewing (no matter whether it's in Transfer Mode or real live mode) now has priority TRANSFERPRIORITY (-1). + The function cDevice::Receiving() now returns true if there is any receiver attached to the device. Its boolean parameter has no meaning any more. + The default value for the Priority parameter of the function cDevice::ProvidesChannel() has been changed to IDLEPRIORITY.
When searching for a device for live viewing, VDR uses priority 0 for the search (thus avoiding any devices that are serving actual timer recordings), and - if going into Transfer Mode - gives the cReceiver a priority of -1. That way the next search for a live device will be able to use the one that is currently serving the Transfer Mode, because the search has a higher priority (this is pretty much the same as it was before).
Now a "remote transfer mode" (which I assume is what streamdev and the like implement) can use a "search priority" of, say, -10, and a transfer priority of -11. That way the remote mechanism will also be able to reuse devices, just like local Transfer Mode. And local live mode can override remotely used devices due to its higher priority.
I'm currently testing these changes in my own production VDR (local live and transfer mode only) and will release them in version 1.7.25 shortly. Let me know then if this works for you.
Klaus
On Wed, 29 Feb 2012 16:17:07 +0100, Klaus Schmidinger wrote
Even though VDR itself doesn't have the necessity for "remote receivers" (yet), I see the problem for streamdev. I have therefore reconsidered this matter and will make the following changes for the next developer version:
- Revised priority handling to allow receivers with a priority that
is lower than that of live viewing (with suggestions from Frank Schmirler): + An idle device (one that is not used for live viewing and has no receiver attached to it) now has priority IDLEPRIORITY (-100). + An unused CAM slot now has priority IDLEPRIORITY.
- The default priority of a cReceiver is now MINPRIORITY (-99).
- A device that is used only for live viewing (no matter whether
it's in Transfer Mode or real live mode) now has priority TRANSFERPRIORITY (-1). + The function cDevice::Receiving() now returns true if there is any receiver attached to the device. Its boolean parameter has no meaning any more. + The default value for the Priority parameter of the function cDevice::ProvidesChannel() has been changed to IDLEPRIORITY.
When searching for a device for live viewing, VDR uses priority 0 for the search (thus avoiding any devices that are serving actual timer recordings), and - if going into Transfer Mode - gives the cReceiver a priority of -1. That way the next search for a live device will be able to use the one that is currently serving the Transfer Mode, because the search has a higher priority (this is pretty much the same as it was before).
Now a "remote transfer mode" (which I assume is what streamdev and the like implement) can use a "search priority" of, say, -10, and a transfer priority of -11. That way the remote mechanism will also be able to reuse devices, just like local Transfer Mode. And local live mode can override remotely used devices due to its higher priority.
I'm currently testing these changes in my own production VDR (local live and transfer mode only) and will release them in version 1.7.25 shortly. Let me know then if this works for you.
Wow - this is good news. Thanks for reconsidering!
Frank
Am 29.02.2012 16:17, schrieb Klaus Schmidinger:
- The function cDevice::Receiving() now returns true if there is any
receiver attached to the device. Its boolean parameter has no meaning any more.
Please remember to drop the following line from PLUGINS.html, as it is now finally completely void:
(any negative value will allow a cReceiver to be detached from its cDevice at any time.)
This was handled via Receiving(true).
This still leaves the live related receivers unhandled, and since there's no way to port the 'volatile' patch without reverting your changes, we still have the old osdteletext-channel-blocking bug.
What about having yet another plugin callback that fires before switching a live channel? Currently, plugins get notified after channel change, and thats too late to disconnect receivers early. And since receiving at -1 doesn't have any special meaning any more, there's no way to get receivers out of way early enough.
Roughly, the callback should be at the places where these two get called:
DELETENULL(liveSubtitle); DELETENULL(dvbSubtitleConverter);
(Thats how VDR's own receivers get out of way.) That way, GetDevice(ch, 0, true) will still have the weired behavior of returning different devices before and after initiating the live view channel switch, but at least after disconnecting all live related receivers, the correct device will be returned.
Cheers,
Udo
On Wed, 29 Feb 2012 21:33:31 +0100, Udo Richter wrote
Am 29.02.2012 16:17, schrieb Klaus Schmidinger:
- The function cDevice::Receiving() now returns true if there is any
receiver attached to the device. Its boolean parameter has no meaning any more.
Please remember to drop the following line from PLUGINS.html, as it is now finally completely void:
(any negative value will allow a cReceiver to be detached from its cDevice
at any time.)
This was handled via Receiving(true).
This still leaves the live related receivers unhandled, and since there's no way to port the 'volatile' patch without reverting your changes, we still have the old osdteletext-channel-blocking bug.
Wouldn't it help to run those live related receivers with priority IDLEPRIORITY and having cDevice::Receiving() ignore receivers with priority IDLEPRIORITY?
The default priority of cReceiver should become IDLEPRIORITY instead of MINPRIORITY then.
Regards, Frank
On 01.03.2012 09:38, Frank Schmirler wrote:
On Wed, 29 Feb 2012 21:33:31 +0100, Udo Richter wrote
Am 29.02.2012 16:17, schrieb Klaus Schmidinger:
- The function cDevice::Receiving() now returns true if there is any
receiver attached to the device. Its boolean parameter has no meaning any more.
Please remember to drop the following line from PLUGINS.html, as it is now finally completely void:
(any negative value will allow a cReceiver to be detached from its cDevice
at any time.)
This was handled via Receiving(true).
This still leaves the live related receivers unhandled, and since there's no way to port the 'volatile' patch without reverting your changes, we still have the old osdteletext-channel-blocking bug.
Wouldn't it help to run those live related receivers with priority IDLEPRIORITY and having cDevice::Receiving() ignore receivers with priority IDLEPRIORITY?
Wouldn't that get us back to square one? ;-)
The default priority of cReceiver should become IDLEPRIORITY instead of MINPRIORITY then.
I don't like that. I want an idle device to have a lower priority than one that has any kind of receiver attached to it.
Klaus
On Fri, 02 Mar 2012 11:08:42 +0100, Klaus Schmidinger wrote
On 01.03.2012 09:38, Frank Schmirler wrote:
On Wed, 29 Feb 2012 21:33:31 +0100, Udo Richter wrote
Am 29.02.2012 16:17, schrieb Klaus Schmidinger:
- The function cDevice::Receiving() now returns true if there is any
receiver attached to the device. Its boolean parameter has no meaning any more.
Please remember to drop the following line from PLUGINS.html, as it is now finally completely void:
(any negative value will allow a cReceiver to be detached from its cDevice
at any time.)
This was handled via Receiving(true).
This still leaves the live related receivers unhandled, and since there's no way to port the 'volatile' patch without reverting your changes, we still have the old osdteletext-channel-blocking bug.
Wouldn't it help to run those live related receivers with priority IDLEPRIORITY and having cDevice::Receiving() ignore receivers with priority IDLEPRIORITY?
Wouldn't that get us back to square one? ;-)
Well, no. Previously live TV and related receivers were treated the same way (same priority, both handled as if they were not present). Currently we have different priorities (-1 and -99) and both are not ignored. So the -99 receiver is not in the way when switching live TV, but it will have an impact on device selection. Ignoring receivers with IDLEPRIORITY (or likewise MINPRIORITY) would solve this.
Regards, Frank
On 02.03.2012 12:54, Frank Schmirler wrote:
On Fri, 02 Mar 2012 11:08:42 +0100, Klaus Schmidinger wrote
On 01.03.2012 09:38, Frank Schmirler wrote:
On Wed, 29 Feb 2012 21:33:31 +0100, Udo Richter wrote
Am 29.02.2012 16:17, schrieb Klaus Schmidinger:
+ The function cDevice::Receiving() now returns true if there is anyreceiver attached to the device. Its boolean parameter has no meaning any more.
Please remember to drop the following line from PLUGINS.html, as it is now finally completely void:
(any negative value will allow a cReceiver to be detached from its cDevice
at any time.)
This was handled via Receiving(true).
This still leaves the live related receivers unhandled, and since there's no way to port the 'volatile' patch without reverting your changes, we still have the old osdteletext-channel-blocking bug.
Wouldn't it help to run those live related receivers with priority IDLEPRIORITY and having cDevice::Receiving() ignore receivers with priority IDLEPRIORITY?
Wouldn't that get us back to square one? ;-)
Well, no. Previously live TV and related receivers were treated the same way (same priority, both handled as if they were not present). Currently we have different priorities (-1 and -99) and both are not ignored. So the -99 receiver is not in the way when switching live TV, but it will have an impact on device selection. Ignoring receivers with IDLEPRIORITY (or likewise MINPRIORITY) would solve this.
But where would that be different from the previous version, where all receivers with negative priorities have been ignored? Now I'm confused...
Klaus
On Fri, 02 Mar 2012 13:01:23 +0100, Klaus Schmidinger wrote
On 02.03.2012 12:54, Frank Schmirler wrote:
On Fri, 02 Mar 2012 11:08:42 +0100, Klaus Schmidinger wrote
On 01.03.2012 09:38, Frank Schmirler wrote:
On Wed, 29 Feb 2012 21:33:31 +0100, Udo Richter wrote
Am 29.02.2012 16:17, schrieb Klaus Schmidinger:
+ The function cDevice::Receiving() now returns true if there is anyreceiver attached to the device. Its boolean parameter has no meaning any
more.
Please remember to drop the following line from PLUGINS.html, as it is now finally completely void:
(any negative value will allow a cReceiver to be detached from its cDevice
at any time.)
This was handled via Receiving(true).
This still leaves the live related receivers unhandled, and since there's no way to port the 'volatile' patch without reverting your changes, we still have the old osdteletext-channel-blocking bug.
Wouldn't it help to run those live related receivers with priority IDLEPRIORITY and having cDevice::Receiving() ignore receivers with priority IDLEPRIORITY?
Wouldn't that get us back to square one? ;-)
Well, no. Previously live TV and related receivers were treated the same way (same priority, both handled as if they were not present). Currently we have different priorities (-1 and -99) and both are not ignored. So the -99 receiver is not in the way when switching live TV, but it will have an impact on device selection. Ignoring receivers with IDLEPRIORITY (or likewise MINPRIORITY) would solve this.
But where would that be different from the previous version, where all receivers with negative priorities have been ignored? Now I'm confused...
Currently there's no such thing like a "live TV related receiver" (like for the osdteletext-plugin). A "live related receiver" will always follow the current live channel. So it shouldn't be in the way when switching channels and will probably never show up alone but always in company with the live TV transfer mode receiver.
VDR up to 1.7.24 had transfer mode receiver at priority -1, live related receivers at -1. All negative priorities treated the same way, i.e. either totally ignored or not ignored at all. No black screen in transfer mode when a recording starts as the transfer mode receiver at -1 is not ignored (Receiving(true) in ProvidesChannel()). But for the same reason a live related receiver at -1 (or any other negative priority) isn't detached when the live channel is being switched. The same problem would also apply to low priority "remote transfer mode" receivers.
The current state of the patch has transfer mode receiver at priority -1, live related receivers by default at -99. No receivers are ignored. Black screen in transfer mode when a recordings starts? Don't know if it's back but I assume the impact in GetDevice takes care of it. The live related receiver is still attached when switching live TV, but it no longer blocks the channel switch due to its lower priority. So low priority "remote transfer mode" should be fine, too. However the live related receiver isn't totally ignored. Receiving() will detect it an so it e.g. has an impact on device selection which is even higher than NumProvidedSystems().
Now lets assume, Receiving() would ignore a receiver at either IDLEPRIORITY or MINPRIORITY. Black screen? Still don't know ;). Live related receiver? Still attached when switching live TV and still not in the way due to low priority. Same for "remote transfer mode". But now Receiving() no longer reports it, so no impact on device selection. The boolean parameter of Receiving() must still be ignored of course.
Moving cStatus::MsgChannelSwitch(this, 0) and plugins with "live related receivers" reacting to it by detaching the receiver should achive the same.
Cheers, Frank
On 29.02.2012 21:33, Udo Richter wrote:
Am 29.02.2012 16:17, schrieb Klaus Schmidinger:
- The function cDevice::Receiving() now returns true if there is any
receiver attached to the device. Its boolean parameter has no meaning any more.
Please remember to drop the following line from PLUGINS.html, as it is now finally completely void:
(any negative value will allow a cReceiver to be detached from its cDevice at any time.)
I don't think so. I've rather added the following note:
(any negative value will allow a cReceiver to be detached from its cDevice at any time *in favor of a timer recording or live viewing*).
This was handled via Receiving(true).
This still leaves the live related receivers unhandled, and since there's no way to port the 'volatile' patch without reverting your changes, we still have the old osdteletext-channel-blocking bug.
What about having yet another plugin callback that fires before switching a live channel? Currently, plugins get notified after channel change, and thats too late to disconnect receivers early. And since receiving at -1 doesn't have any special meaning any more, there's no way to get receivers out of way early enough.
Roughly, the callback should be at the places where these two get called:
DELETENULL(liveSubtitle); DELETENULL(dvbSubtitleConverter);(Thats how VDR's own receivers get out of way.)
There are two places in GetDevice() where cStatus::MsgChannelSwitch(this, 0) is called, but they are both *after* the final call to GetDevice(). And there is this comment
// only report status if we are actually going to switch the channel
which refers to a change that was made in version 1.1.10:
- Only calling cStatus::MsgChannelSwitch() if a channel is actually going to be switched or has actually been switched successfully (thanks to Stefan Huelswitt).
So before moving the call to cStatus::MsgChannelSwitch() to where it was before version 1.1.10 (which I believe would be what you suggested above) this needs to be given some thought. Personally I wouldn't mind making this change, so if nobody objects, I will.
That way, GetDevice(ch, 0, true) will still have the weired behavior of returning different devices before and after initiating the live view channel switch, but at least after disconnecting all live related receivers, the correct device will be returned.
The reason why different devices may be selected here is because when zapping through channels with Up and Down, the first GetDevice() call is done while the current live channel is still active, so the device currently used for live viewing may be avoided because of receivers attached to it. If there is an other device without receivers, but otherwise having the same "impact", that one will be chosen. When the actual SetChannel() call is made, VDR detaches its own receivers from the device and does another GetDevice() call. This time the original live device may be chosen. I don't think that this really is a problem, because a device will always be found, even if temporarily a different one will be preferred. What I really see as a problem here now is that the first call to GetDevice() may call a device's DetachAllReceivers() and the second GetDevice() call may then decide to actually use a different device. I'm currently considering giving GetDevice() another parameter:
static cDevice *GetDevice(const cChannel *Channel, int Priority, bool LiveView, bool Query = false);
and make it not do any CAM assignments or receiver detachments if Query is true, but only check whether there is any device available.
Klaus
On Fri, 02 Mar 2012 11:06:03 +0100, Klaus Schmidinger wrote
I'm currently considering giving GetDevice() another parameter:
static cDevice *GetDevice(const cChannel *Channel, int Priority, bool LiveView, bool Query = false);
and make it not do any CAM assignments or receiver detachments if Query is true, but only check whether there is any device available.
Yes, please. This is on top of my "additional wishes" list and would finally save me the copy of cDevice::GetDevice() I have in streamdev which became necessary since GetDevice() got these "side effects" in VDR 1.5.0.
Regards, Frank
Am 02.03.2012 11:06, schrieb Klaus Schmidinger:
On 29.02.2012 21:33, Udo Richter wrote:
Roughly, the callback should be at the places where these two get called:
DELETENULL(liveSubtitle); DELETENULL(dvbSubtitleConverter);(Thats how VDR's own receivers get out of way.)
There are two places in GetDevice() where cStatus::MsgChannelSwitch(this, 0) is called, but they are both *after* the final call to GetDevice(). And there is this comment
// only report status if we are actually going to switch the channel
which refers to a change that was made in version 1.1.10:
- Only calling cStatus::MsgChannelSwitch() if a channel is actually
going to be switched or has actually been switched successfully (thanks to Stefan Huelswitt).
Good point. What if VDR wants to switch, but fails. Is it possible that the channel change still fails after deleting liveSubtitle and dvbSubtitleConverter? How does VDR itself handle this? Need to investigate this.
If a call to MsgChannelSwitch(this, 0) was done on channel change, we have to make sure that the corresponding call for the new channel does happen, or - worst case - there's a call for the old channel again.
What I really see as a problem here now is that the first call to GetDevice() may call a device's DetachAllReceivers() and the second GetDevice() call may then decide to actually use a different device. I'm currently considering giving GetDevice() another parameter:
static cDevice *GetDevice(const cChannel *Channel, int Priority, bool LiveView, bool Query = false);
+1, as I know that something like this was on some wish lists for some time. ;)
Cheers,
Udo
On 02.03.2012 18:13, Udo Richter wrote:
Am 02.03.2012 11:06, schrieb Klaus Schmidinger:
On 29.02.2012 21:33, Udo Richter wrote:
Roughly, the callback should be at the places where these two get called:
DELETENULL(liveSubtitle); DELETENULL(dvbSubtitleConverter);(Thats how VDR's own receivers get out of way.)
There are two places in GetDevice() where cStatus::MsgChannelSwitch(this, 0) is called, but they are both *after* the final call to GetDevice(). And there is this comment
// only report status if we are actually going to switch the channel
which refers to a change that was made in version 1.1.10:
- Only calling cStatus::MsgChannelSwitch() if a channel is actually
going to be switched or has actually been switched successfully (thanks to Stefan Huelswitt).
Good point. What if VDR wants to switch, but fails. Is it possible that the channel change still fails after deleting liveSubtitle and dvbSubtitleConverter? How does VDR itself handle this? Need to investigate this.
If switching to a certain channel fails, VDR will notice that the primary device no longer HasProgramme() and will try to switch to a different channel.
If a call to MsgChannelSwitch(this, 0) was done on channel change, we have to make sure that the corresponding call for the new channel does happen, or - worst case - there's a call for the old channel again.
What I really see as a problem here now is that the first call to GetDevice() may call a device's DetachAllReceivers() and the second GetDevice() call may then decide to actually use a different device. I'm currently considering giving GetDevice() another parameter:
static cDevice *GetDevice(const cChannel *Channel, int Priority, bool LiveView, bool Query = false);
+1, as I know that something like this was on some wish lists for some time. ;)
I'll release version 1.7.25 later today, so that all these changes can be reviewed and tested.
Klaus
On 3/3/2012 4:48 AM, Klaus Schmidinger wrote:
On 02.03.2012 18:13, Udo Richter wrote:
Am 02.03.2012 11:06, schrieb Klaus Schmidinger:
On 29.02.2012 21:33, Udo Richter wrote:
Roughly, the callback should be at the places where these two get called:
DELETENULL(liveSubtitle); DELETENULL(dvbSubtitleConverter);
(Thats how VDR's own receivers get out of way.)
There are two places in GetDevice() where cStatus::MsgChannelSwitch(this, 0) is called, but they are both *after* the final call to GetDevice(). And there is this comment
// only report status if we are actually going to switch the channel
which refers to a change that was made in version 1.1.10:
- Only calling cStatus::MsgChannelSwitch() if a channel is actually
going to be switched or has actually been switched successfully (thanks to Stefan Huelswitt).
Good point. What if VDR wants to switch, but fails. Is it possible that the channel change still fails after deleting liveSubtitle and dvbSubtitleConverter? How does VDR itself handle this? Need to investigate this.
If switching to a certain channel fails, VDR will notice that the primary device no longer HasProgramme() and will try to switch to a different channel.
If a call to MsgChannelSwitch(this, 0) was done on channel change, we have to make sure that the corresponding call for the new channel does happen, or - worst case - there's a call for the old channel again.
What I really see as a problem here now is that the first call to GetDevice() may call a device's DetachAllReceivers() and the second GetDevice() call may then decide to actually use a different device. I'm currently considering giving GetDevice() another parameter:
static cDevice *GetDevice(const cChannel *Channel, int Priority, bool LiveView, bool Query = false);
+1, as I know that something like this was on some wish lists for some time. ;)
I'll release version 1.7.25 later today, so that all these changes can be reviewed and tested.
Klaus
A problem I have run into before is not that a channel is down, though that also happens, but that a tuner is down. I've had tuner crashes, but vdr just stayed with that tuner/chanel and recorded nothing. I currently have 5 ATA tuners. 2 Dual tuner cards and a single.
"Timothy D. Lenz" tlenz@vorgon.com writes:
[...]
A problem I have run into before is not that a channel is down, though that also happens, but that a tuner is down. I've had tuner crashes, but vdr just stayed with that tuner/chanel and recorded nothing. I currently have 5 ATA tuners. 2 Dual tuner cards and a single.
You might want to have a look at the wonderful dynamite patch and plugin: http://projects.vdr-developer.org/projects/plg-dynamite
On 04.03.2012 19:04, Timothy D. Lenz wrote:
... A problem I have run into before is not that a channel is down, though that also happens, but that a tuner is down. I've had tuner crashes, but vdr just stayed with that tuner/chanel and recorded nothing. I currently have 5 ATA tuners. 2 Dual tuner cards and a single.
Didn't VDR report a "video data stream broken" and perform a restart?
Klaus
On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:
On 04.03.2012 19:04, Timothy D. Lenz wrote:
... A problem I have run into before is not that a channel is down, though that also happens, but that a tuner is down. I've had tuner crashes, but vdr just stayed with that tuner/chanel and recorded nothing. I currently have 5 ATA tuners. 2 Dual tuner cards and a single.
Didn't VDR report a "video data stream broken" and perform a restart?
That problem coincides with my problem of recordings with length 0 and filesize of few megabytes. Didn't know that it comes from a crashed tuner.
If I remember right, there was no "video data stream broken" message and after enabling the automatic shutdown I realized, that the vdr waits until no recording is active before initiating the restart.
So the automatic restart did not really help anything, especially in environments, where multiple parallel recordings are most probably to happen.
kind regards
Gero
On 05.03.2012 04:47, Gero wrote:
On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:
On 04.03.2012 19:04, Timothy D. Lenz wrote:
... A problem I have run into before is not that a channel is down, though that also happens, but that a tuner is down. I've had tuner crashes, but vdr just stayed with that tuner/chanel and recorded nothing. I currently have 5 ATA tuners. 2 Dual tuner cards and a single.
Didn't VDR report a "video data stream broken" and perform a restart?
That problem coincides with my problem of recordings with length 0 and filesize of few megabytes. Didn't know that it comes from a crashed tuner.
If I remember right, there was no "video data stream broken" message and after enabling the automatic shutdown I realized, that the vdr waits until no recording is active before initiating the restart.
So the automatic restart did not really help anything, especially in environments, where multiple parallel recordings are most probably to happen.
It doesn't matter whether there is only one or multiple recordings. Whenever a "video data stream broken" occurs, VDR performs an immediate "emergency exit" (unless you turned that off, but then you're on your own). So if a tuner doesn't deliver any more data, VDR restarts and reloads the driver (provided you use a properly set up "runvdr" script).
Klaus
On Monday 05 March 2012 - 09:02:56, Klaus Schmidinger wrote:
On 05.03.2012 04:47, Gero wrote:
On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:
On 04.03.2012 19:04, Timothy D. Lenz wrote:
... A problem I have run into before is not that a channel is down, though that also happens, but that a tuner is down. I've had tuner crashes, but vdr just stayed with that tuner/chanel and recorded nothing. I currently have 5 ATA tuners. 2 Dual tuner cards and a single.
Didn't VDR report a "video data stream broken" and perform a restart?
That problem coincides with my problem of recordings with length 0 and filesize of few megabytes. Didn't know that it comes from a crashed tuner.
If I remember right, there was no "video data stream broken" message and after enabling the automatic shutdown I realized, that the vdr waits until no recording is active before initiating the restart.
So the automatic restart did not really help anything, especially in environments, where multiple parallel recordings are most probably to happen.
It doesn't matter whether there is only one or multiple recordings. Whenever a "video data stream broken" occurs, VDR performs an immediate "emergency exit" (unless you turned that off, but then you're on your own).
That might be true.
When I first reported recordings with length 0, the emergency exit was disabled. That time I had log-entries with "video data stream broken". According your advice, I enabled it, but since then I had no more log-entries with "video data stream broken", but had recordings with length 0
So there might be other reasons that stop vdr from recording without any notice / log entry
So if a tuner doesn't deliver any more data, VDR restarts and reloads the driver (provided you use a properly set up "runvdr" script).
Hm, I gues my runvdr might be ok, since my backend does timer-controlled wakeup and shuts down in idle state.
kind regards
Gero
On 3/5/2012 2:52 AM, Gero wrote:
On Monday 05 March 2012 - 09:02:56, Klaus Schmidinger wrote:
On 05.03.2012 04:47, Gero wrote:
On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:
On 04.03.2012 19:04, Timothy D. Lenz wrote:
... A problem I have run into before is not that a channel is down, though that also happens, but that a tuner is down. I've had tuner crashes, but vdr just stayed with that tuner/chanel and recorded nothing. I currently have 5 ATA tuners. 2 Dual tuner cards and a single.
Didn't VDR report a "video data stream broken" and perform a restart?
That problem coincides with my problem of recordings with length 0 and filesize of few megabytes. Didn't know that it comes from a crashed tuner.
If I remember right, there was no "video data stream broken" message and after enabling the automatic shutdown I realized, that the vdr waits until no recording is active before initiating the restart.
So the automatic restart did not really help anything, especially in environments, where multiple parallel recordings are most probably to happen.
It doesn't matter whether there is only one or multiple recordings. Whenever a "video data stream broken" occurs, VDR performs an immediate "emergency exit" (unless you turned that off, but then you're on your own).
That might be true.
When I first reported recordings with length 0, the emergency exit was disabled. That time I had log-entries with "video data stream broken". According your advice, I enabled it, but since then I had no more log-entries with "video data stream broken", but had recordings with length 0
So there might be other reasons that stop vdr from recording without any notice / log entry
So if a tuner doesn't deliver any more data, VDR restarts and reloads the driver (provided you use a properly set up "runvdr" script).
Hm, I gues my runvdr might be ok, since my backend does timer-controlled wakeup and shuts down in idle state.
kind regards
Gero
Restarting when you have more then one recording screws up the working ones. The local broadcasters are morons about digital broadcast. Even with a good strong signal you can have broken up video which would trigger the restart making things even worse.
On 05.03.2012 19:54, Timothy D. Lenz wrote:
On 3/5/2012 2:52 AM, Gero wrote:
On Monday 05 March 2012 - 09:02:56, Klaus Schmidinger wrote:
On 05.03.2012 04:47, Gero wrote:
On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:
On 04.03.2012 19:04, Timothy D. Lenz wrote:
... A problem I have run into before is not that a channel is down, though that also happens, but that a tuner is down. I've had tuner crashes, but vdr just stayed with that tuner/chanel and recorded nothing. I currently have 5 ATA tuners. 2 Dual tuner cards and a single.
Didn't VDR report a "video data stream broken" and perform a restart?
That problem coincides with my problem of recordings with length 0 and filesize of few megabytes. Didn't know that it comes from a crashed tuner.
If I remember right, there was no "video data stream broken" message and after enabling the automatic shutdown I realized, that the vdr waits until no recording is active before initiating the restart.
So the automatic restart did not really help anything, especially in environments, where multiple parallel recordings are most probably to happen.
It doesn't matter whether there is only one or multiple recordings. Whenever a "video data stream broken" occurs, VDR performs an immediate "emergency exit" (unless you turned that off, but then you're on your own).
That might be true.
When I first reported recordings with length 0, the emergency exit was disabled. That time I had log-entries with "video data stream broken". According your advice, I enabled it, but since then I had no more log-entries with "video data stream broken", but had recordings with length 0
So there might be other reasons that stop vdr from recording without any notice / log entry
So if a tuner doesn't deliver any more data, VDR restarts and reloads the driver (provided you use a properly set up "runvdr" script).
Hm, I gues my runvdr might be ok, since my backend does timer-controlled wakeup and shuts down in idle state.
kind regards
Gero
Restarting when you have more then one recording screws up the working ones. The local broadcasters are morons about digital broadcast. Even with a good strong signal you can have broken up video which would trigger the restart making things even worse.
Well, then I guess you need to make your hardware/drivers work properly, so that you can turn off the emergency exit. VDR can only work with what it gets.
Klaus
No, but I have the auto shutdown thing turned off because when signal is bad on 1 channel, it would disrupt everything with frequent restarts and as I recall, it often didn't restart. Might have been xine or something that stopped with the restart, I don't recall. Plus, restarting VDR in this case wouldn't fix the problem because it's a hardware crash that requires the drivers be restarted. One card finally died and had to be replaced which helped, but I know I have to leave power save off on those cards because the tuners get flaky when it's used and seems to be what killed the card. Poor craftsmanship.
On 3/4/2012 2:51 PM, Klaus Schmidinger wrote:
On 04.03.2012 19:04, Timothy D. Lenz wrote:
... A problem I have run into before is not that a channel is down, though that also happens, but that a tuner is down. I've had tuner crashes, but vdr just stayed with that tuner/chanel and recorded nothing. I currently have 5 ATA tuners. 2 Dual tuner cards and a single.
Didn't VDR report a "video data stream broken" and perform a restart?
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 05.03.2012 19:50, Timothy D. Lenz wrote:
No, but I have the auto shutdown thing turned off because when signal is bad on 1 channel, it would disrupt everything with frequent restarts and as I recall, it often didn't restart. Might have been xine or something that stopped with the restart, I don't recall. Plus, restarting VDR in this case wouldn't fix the problem because it's a hardware crash that requires the drivers be restarted.
That's what a properly configured runvdr script does if you fill in its LoadDriver() and UnloadDriver() functions.
Klaus
One card finally died and had to be replaced which helped, but I know I have to leave power save off on those cards because the tuners get flaky when it's used and seems to be what killed the card. Poor craftsmanship.
On 3/4/2012 2:51 PM, Klaus Schmidinger wrote:
On 04.03.2012 19:04, Timothy D. Lenz wrote:
... A problem I have run into before is not that a channel is down, though that also happens, but that a tuner is down. I've had tuner crashes, but vdr just stayed with that tuner/chanel and recorded nothing. I currently have 5 ATA tuners. 2 Dual tuner cards and a single.
Didn't VDR report a "video data stream broken" and perform a restart?
Klaus
-
Anssi Hannula -
Dave -
Dominic Evans -
Eric Valette -
Frank Schmirler -
Gero -
Jarkko Kangas -
Joerg Riechardt -
Klaus Schmidinger -
Manuel Reimer -
Mika Laitio -
Pertti Kosunen -
Steffen Barszus -
syrius.ml＠no-log.org -
Timothy D. Lenz -
Tobi -
Tony Houghton -
Udo Richter -
VDR User -
Ville Skyttä