Hi,
Sometimes when you want to pause live video you are already recording the current channel. In such case it is not practical to start a new instant recording but it would be more practical to start replaying the recording already being made, jump to correct position in the recording and then pause. So I have implemented this for VDR-1.7.16 as a patch which adds two new options to "Pause kay handling" menu item to enable this behavior with or without confirmation.
Any improvements or suggestions are welcome.
Sometimes when you want to pause live video you are already recording the current channel. In such case it is not practical to start a new instant recording but it would be more practical to start replaying the recording already being made, jump to correct position in the recording and then pause. So I have implemented this for VDR-1.7.16 as a patch which adds two new options to "Pause kay handling" menu item to enable this behavior with or without confirmation.
I've always wondered myself why vdr behaves like that. Thanks for this patch, hopefully it gets included.
On 1.12.2010 17.44, Matti Lehtimäki wrote:
Hi,
Sometimes when you want to pause live video you are already recording the current channel. In such case it is not practical to start a new instant recording but it would be more practical to start replaying the recording already being made, jump to correct position in the recording and then pause. So I have implemented this for VDR-1.7.16 as a patch which adds two new options to "Pause kay handling" menu item to enable this behavior with or without confirmation.
Any improvements or suggestions are welcome.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Addition to that would be that (in same situation where there is recording ongoing) if user presses backward (<<) button or press "jump backward little" (1) or "jump backward big" (green) it would work as expected... Jumping to right place of recording.
2010/12/1 JJussi vdr@jjussi.com
Addition to that would be that (in same situation where there is recording ongoing) if user presses backward (<<) button or press "jump backward little" (1) or "jump backward big" (green) it would work as expected... Jumping to right place of recording.
This is not possible easily since those buttons have different use when watching live tv compared to watching a recording and therefore normal usage would be changed too much. But you could do this even with the current patch, you just have to press pause first and when replay mode is enabled press the desired button.
Am 01.12.2010 16:44, schrieb Matti Lehtimäki:
Sometimes when you want to pause live video you are already recording the current channel. In such case it is not practical to start a new instant recording but it would be more practical to start replaying the recording already being made[...]
Any improvements or suggestions are welcome.
Nice idea, however I see one small drawback: Until now, a 'pause' instant recording lasts 3 hours (or whatever was set up). With your patch, this time shortens to the time of the recording, which might be rather short, for example if the timer actually records the previous show and overlaps for a few minutes.
This, together with the fact that this is probably unexpected by the user, can lead to disaster: If he's time-shifting later on, he'll be quite surprised that the recording has stopped minutes ago and the in-between show is gone.
A probable solution would be to extend the ongoing recording to the minimum time shift time, eg. Setup.InstantRecordTime.
However, I have no problem with the fact that the same show is recorded twice. This doesn't cause too much system load, and with today's disk sizes, it really doesn't hurt.
Cheers,
Udo
2010/12/1 Udo Richter udo_richter@gmx.de:
Nice idea, however I see one small drawback: Until now, a 'pause' instant recording lasts 3 hours (or whatever was set up). With your patch, this time shortens to the time of the recording, which might be rather short, for example if the timer actually records the previous show and overlaps for a few minutes.
I also thought about this problem and I now might have a solution which I'll try tonight. This would add a check if the time left in timer is longer than the margin at stop defined in setup and would start replaying only if this is true. Otherwise it would start a new instant recording as usual.
This, together with the fact that this is probably unexpected by the user, can lead to disaster: If he's time-shifting later on, he'll be quite surprised that the recording has stopped minutes ago and the in-between show is gone.
This is one reason why I added this as optional feature.
A probable solution would be to extend the ongoing recording to the minimum time shift time, eg. Setup.InstantRecordTime.
This is one possible solution and I will consider this also. This could be another way of solving the problem if time left in the timer is too short.
However, I have no problem with the fact that the same show is recorded twice. This doesn't cause too much system load, and with today's disk sizes, it really doesn't hurt.
This is quite true, but it seems some people like the new feature and I would give it as an option.
On 12/02/10 11:55, Matti Lehtimäki wrote:
2010/12/1 Udo Richter udo_richter@gmx.de:
Nice idea, however I see one small drawback: Until now, a 'pause' instant recording lasts 3 hours (or whatever was set up). With your patch, this time shortens to the time of the recording, which might be rather short, for example if the timer actually records the previous show and overlaps for a few minutes.
I also thought about this problem and I now might have a solution which I'll try tonight. This would add a check if the time left in timer is longer than the margin at stop defined in setup and would start replaying only if this is true. Otherwise it would start a new instant recording as usual.
This, together with the fact that this is probably unexpected by the user, can lead to disaster: If he's time-shifting later on, he'll be quite surprised that the recording has stopped minutes ago and the in-between show is gone.
This is one reason why I added this as optional feature.
A probable solution would be to extend the ongoing recording to the minimum time shift time, eg. Setup.InstantRecordTime.
This is one possible solution and I will consider this also. This could be another way of solving the problem if time left in the timer is too short.
However, I have no problem with the fact that the same show is recorded twice. This doesn't cause too much system load, and with today's disk sizes, it really doesn't hurt.
This is quite true, but it seems some people like the new feature and I would give it as an option.
At any rate, it's not going to be included in the original VDR source. It complicates things without having a real advantage. As Udo already noted, with today's huge disks it doesn't matter if a show is recorded twice. The benefit of keeping things simple outweighs this by far.
Klaus
-
Christopher Reimer -
Jan Willies -
JJussi -
Klaus Schmidinger -
Matti Lehtimäki -
Udo Richter