Hi,
A nice new patch arrived at VDR-Portal: http://www.vdr-portal.de/board/thread.php?threadid=37309&sid=&hiligh... With this Patch VDR can do permanent timeshift, so you can see the last scene again whenever you want :-) I know Klaus, you won't like the question, but do you see a chance of integrating it in 1.3. x ? It would be great to see this feature in a stable 1.4. release.
--------- Helmut Auer
Hello,
On Thu, 18 Aug 2005 14:07:49 +0200 (CEST) vdr@helmutauer.de wrote:
| With this Patch VDR can do permanent timeshift, so you can see the last scene again whenever you want :-)
Sorry, i'm not sure to fully understand what new functionality this patch brings. Can you elaborate what you mean by "permanent timeshift" ?
How does it differ from current behavior ?
Thanks,
Philippe
On Thu, 18 Aug 2005, Philippe Gramoullé (PG) wrote:
Hello,
On Thu, 18 Aug 2005 14:07:49 +0200 (CEST) vdr@helmutauer.de wrote:
| With this Patch VDR can do permanent timeshift, so you can see the | last scene again whenever you want :-)
Sorry, i'm not sure to fully understand what new functionality this patch brings. Can you elaborate what you mean by "permanent timeshift" ?
How does it differ from current behavior ?
I didn't see the patch but guess that without explicitly recording/timeshifting you can alwayss rewind the live view.
c ya Sergei
Philippe Gramoulle wrote:
Hello,
On Thu, 18 Aug 2005 14:07:49 +0200 (CEST) vdr@helmutauer.de wrote:
| With this Patch VDR can do permanent timeshift, so you can see the last scene again whenever you want :-)
Sorry, i'm not sure to fully understand what new functionality this patch brings. Can you elaborate what you mean by "permanent timeshift" ?
How does it differ from current behavior ?
The patch does following: - it always records the channel you are watching, when you switch channel a new recording starts and the old will be deleted - so you are able to repeat a scene if for example you didn't understand something - or when you are watching a film, and you decide during the film, that you want to record it, you can do so, if the beginning is in the livebuffer (new timer -> LiveBuffer: yes) - you can turn on/off this functionality in menu -> setup -> recording -> LiveBuffer there you can also set the size for the livebuffer (in MB)
But I want to WARN you: This patch is not yet really stable! (Of course, it would nice if some of you test it and report bugs)
Thomas
Thomas Bergwinkl wrote:
Philippe Gramoulle wrote:
Hello,
On Thu, 18 Aug 2005 14:07:49 +0200 (CEST) vdr@helmutauer.de wrote:
| With this Patch VDR can do permanent timeshift, so you can see the last scene again whenever you want :-)
Sorry, i'm not sure to fully understand what new functionality this patch brings. Can you elaborate what you mean by "permanent timeshift" ?
How does it differ from current behavior ?
The patch does following:
- it always records the channel you are watching, when you switch
channel a new recording starts and the old will be deleted
- so you are able to repeat a scene if for example you didn't understand
something
- or when you are watching a film, and you decide during the film, that
you want to record it, you can do so, if the beginning is in the livebuffer (new timer -> LiveBuffer: yes)
- you can turn on/off this functionality in menu -> setup ->
recording -> LiveBuffer there you can also set the size for the livebuffer (in MB)
But I want to WARN you: This patch is not yet really stable! (Of course, it would nice if some of you test it and report bugs)
Thanks for the great additional patch! Of course modifications are required to the patch if you use enAIO and the jumpplay patches. But, besides vdr, I found 5 common plugins that also required changes when using this LiveBuffer patch.
Best Regards.
C.Y.M wrote:
Thomas Bergwinkl wrote:
Philippe Gramoulle wrote:
Hello,
On Thu, 18 Aug 2005 14:07:49 +0200 (CEST) vdr@helmutauer.de wrote:
| With this Patch VDR can do permanent timeshift, so you can see the last scene again whenever you want :-)
Sorry, i'm not sure to fully understand what new functionality this patch brings. Can you elaborate what you mean by "permanent timeshift" ?
How does it differ from current behavior ?
The patch does following:
- it always records the channel you are watching, when you switch
channel a new recording starts and the old will be deleted
- so you are able to repeat a scene if for example you didn't understand
something
- or when you are watching a film, and you decide during the film, that
you want to record it, you can do so, if the beginning is in the livebuffer (new timer -> LiveBuffer: yes)
- you can turn on/off this functionality in menu -> setup ->
recording -> LiveBuffer there you can also set the size for the livebuffer (in MB)
But I want to WARN you: This patch is not yet really stable! (Of course, it would nice if some of you test it and report bugs)
Thanks for the great additional patch! Of course modifications are required to the patch if you use enAIO and the jumpplay patches. But, besides vdr, I found 5 common plugins that also required changes when using this LiveBuffer patch.
I find it very bad if a patch modifies interfaces that require plugins to be specially adapted to that patch. Plugins should _always_ run with plain vanilla VDR and never require a "specially patched" version of VDR!
Klaus
C.Y.M wrote:
Thomas Bergwinkl wrote:
Philippe Gramoulle wrote:
Hello,
On Thu, 18 Aug 2005 14:07:49 +0200 (CEST) vdr@helmutauer.de wrote:
| With this Patch VDR can do permanent timeshift, so you can see the last scene again whenever you want :-)
Sorry, i'm not sure to fully understand what new functionality this patch brings. Can you elaborate what you mean by "permanent timeshift" ?
How does it differ from current behavior ?
The patch does following:
- it always records the channel you are watching, when you switch
channel a new recording starts and the old will be deleted
- so you are able to repeat a scene if for example you
didn't understand
something
- or when you are watching a film, and you decide during
the film, that
you want to record it, you can do so, if the beginning is in the livebuffer (new timer -> LiveBuffer: yes)
- you can turn on/off this functionality in menu -> setup ->
recording -> LiveBuffer there you can also set the size for the livebuffer (in MB)
But I want to WARN you: This patch is not yet really stable! (Of course, it would
nice if some
of you test it and report bugs)
Thanks for the great additional patch! Of course modifications are required to the patch if you use enAIO and the jumpplay patches. But, besides vdr, I found 5 common plugins that also required changes when using this LiveBuffer patch.
Best Regards.
Which plugins are these 5?
Klaus Schmidinger wrote:
C.Y.M wrote:
Thomas Bergwinkl wrote:
Philippe Gramoulle wrote:
Hello,
On Thu, 18 Aug 2005 14:07:49 +0200 (CEST) vdr@helmutauer.de wrote:
| With this Patch VDR can do permanent timeshift, so you can see the last scene again whenever you want :-)
Sorry, i'm not sure to fully understand what new functionality this patch brings. Can you elaborate what you mean by "permanent timeshift" ?
How does it differ from current behavior ?
The patch does following:
- it always records the channel you are watching, when you switch
channel a new recording starts and the old will be deleted
- so you are able to repeat a scene if for example you
didn't understand
something
- or when you are watching a film, and you decide during
the film, that
you want to record it, you can do so, if the beginning is in the livebuffer (new timer -> LiveBuffer: yes)
- you can turn on/off this functionality in menu -> setup ->
recording -> LiveBuffer there you can also set the size for the livebuffer (in MB)
But I want to WARN you: This patch is not yet really stable! (Of course, it would
nice if some
of you test it and report bugs)
Thanks for the great additional patch! Of course
modifications are required to
the patch if you use enAIO and the jumpplay patches. But,
besides vdr, I found
5 common plugins that also required changes when using this
LiveBuffer patch.
I find it very bad if a patch modifies interfaces that require plugins to be specially adapted to that patch. Plugins should _always_ run with plain vanilla VDR and never require a "specially patched" version of VDR!
You are right Klaus. It wasn't my intention to modify any interface that require plugins.
Which plugins are these 5?
dvd (cvs) mp3 streamdev sky vcd
The patches in my previous post should provide more info. But, after these few modifications, it seems to be working really well :)
Also, merging the jumpplay changes into the LiveBuffer patch was also required since jumpplay makes the following change:
-cDvbPlayer::cDvbPlayer(const char *FileName) +cDvbPlayer::cDvbPlayer(const char *FileName, cMarks *Marks)
so, we finally have
-cDvbPlayer::cDvbPlayer(const char *FileName) +cDvbPlayerControl(const char *FileName, cMarks *Marks, bool IsLiveRec = false);
Of course there are several other changes needed if you want to integrate enAIO as well. Overall though, I would have to say you did a great job. Thanks again.
Regards.
C.Y.M wrote:
Which plugins are these 5?
dvd (cvs) mp3 streamdev sky vcd
The patches in my previous post should provide more info. But, after these few modifications, it seems to be working really well :)
I didn't see that you attached the diff-files :-) Now I know that it was no good idea to change virtual functions ;-) I will think about how to avoid changing these virtual functions.
Thomas
C.Y.M schrieb:
But, besides vdr, I found 5 common plugins that also required changes when using this LiveBuffer patch.
I tried to solve the plugin conflicts. Use this patch after LiveBuffer patch.
Tom
#!/bin/sh /usr/share/dpatch/dpatch-run
## opt-43_LiveBufferE.dpatch by Thomas Günther tom@toms-cafe.de ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: This patch solves conflicts of lifebuffer patch (0.0.7) with the plugin ## DP: interfaces regarding dvd, mp3, sky, streamdev and vcs plugins.
@DPATCH@ diff -Naur vdr-1.3.29-LiveBuffer-0.0.7/device.c vdr-1.3.29-LiveBuffer-0.0.7E/device.c --- vdr-1.3.29-LiveBuffer-0.0.7/device.c 2005-08-18 20:29:07.000000000 +0200 +++ vdr-1.3.29-LiveBuffer-0.0.7E/device.c 2005-08-18 19:31:06.000000000 +0200 @@ -513,7 +513,12 @@ return true; }
-bool cDevice::ProvidesChannel(const cChannel *Channel, int Priority, bool *NeedsDetachReceivers, bool LiveRec) const +bool cDevice::ProvidesChannel(const cChannel *Channel, int Priority, bool *NeedsDetachReceivers) const +{ + return false; +} + +bool cDevice::ProvidesChannelE(const cChannel *Channel, int Priority, bool *NeedsDetachReceivers, bool LiveRec) const { return false; } @@ -579,7 +584,7 @@ // If this card can't receive this channel, we must not actually switch // the channel here, because that would irritate the driver when we // start replaying in Transfer Mode immediately after switching the channel: - bool NeedsTransferMode = (LiveView && IsPrimaryDevice() && !ProvidesChannel(Channel, Setup.PrimaryLimit, NULL, Setup.LiveBuffer)); + bool NeedsTransferMode = (LiveView && IsPrimaryDevice() && !ProvidesChannelE(Channel, Setup.PrimaryLimit, NULL, Setup.LiveBuffer));
eSetChannelResult Result = scrOk;
diff -Naur vdr-1.3.29-LiveBuffer-0.0.7/device.h vdr-1.3.29-LiveBuffer-0.0.7E/device.h --- vdr-1.3.29-LiveBuffer-0.0.7/device.h 2005-08-18 20:29:07.000000000 +0200 +++ vdr-1.3.29-LiveBuffer-0.0.7E/device.h 2005-08-18 19:17:03.000000000 +0200 @@ -189,7 +189,8 @@ virtual bool ProvidesTransponderExclusively(const cChannel *Channel) const; ///< Returns true if this is the only device that is able to provide ///< the given channel's transponder. - virtual bool ProvidesChannel(const cChannel *Channel, int Priority = -1, bool *NeedsDetachReceivers = NULL, bool LiveRec = false) const; + virtual bool ProvidesChannel(const cChannel *Channel, int Priority = -1, bool *NeedsDetachReceivers = NULL) const; + virtual bool ProvidesChannelE(const cChannel *Channel, int Priority = -1, bool *NeedsDetachReceivers = NULL, bool LiveRec = false) const; ///< Returns true if this device can provide the given channel. ///< In case the device has cReceivers attached to it or it is the primary ///< device, Priority is used to decide whether the caller's request can diff -Naur vdr-1.3.29-LiveBuffer-0.0.7/dvbdevice.c vdr-1.3.29-LiveBuffer-0.0.7E/dvbdevice.c --- vdr-1.3.29-LiveBuffer-0.0.7/dvbdevice.c 2005-08-18 20:29:07.000000000 +0200 +++ vdr-1.3.29-LiveBuffer-0.0.7E/dvbdevice.c 2005-08-18 19:36:32.000000000 +0200 @@ -745,7 +745,12 @@ return ProvidesSource(Channel->Source()) && (!cSource::IsSat(Channel->Source()) || !Setup.DiSEqC || Diseqcs.Get(Channel->Source(), Channel->Frequency(), Channel->Polarization())); }
-bool cDvbDevice::ProvidesChannel(const cChannel *Channel, int Priority, bool *NeedsDetachReceivers, bool LiveRec) const +bool cDvbDevice::ProvidesChannel(const cChannel *Channel, int Priority, bool *NeedsDetachReceivers) const +{ + return ProvidesChannelE(Channel, Priority, NeedsDetachReceivers); +} + +bool cDvbDevice::ProvidesChannelE(const cChannel *Channel, int Priority, bool *NeedsDetachReceivers, bool LiveRec) const { bool result = false; bool hasPriority = Priority < 0 || Priority > this->Priority(); diff -Naur vdr-1.3.29-LiveBuffer-0.0.7/dvbdevice.h vdr-1.3.29-LiveBuffer-0.0.7E/dvbdevice.h --- vdr-1.3.29-LiveBuffer-0.0.7/dvbdevice.h 2005-08-18 20:29:07.000000000 +0200 +++ vdr-1.3.29-LiveBuffer-0.0.7E/dvbdevice.h 2005-08-18 20:14:03.000000000 +0200 @@ -60,7 +60,8 @@ public: virtual bool ProvidesSource(int Source) const; virtual bool ProvidesTransponder(const cChannel *Channel) const; - virtual bool ProvidesChannel(const cChannel *Channel, int Priority = -1, bool *NeedsDetachReceivers = NULL, bool LiveRec = NULL) const; + virtual bool ProvidesChannel(const cChannel *Channel, int Priority = -1, bool *NeedsDetachReceivers = NULL) const; + virtual bool ProvidesChannelE(const cChannel *Channel, int Priority = -1, bool *NeedsDetachReceivers = NULL, bool LiveRec = false) const; protected: virtual bool SetChannelDevice(const cChannel *Channel, bool LiveView); public: diff -Naur vdr-1.3.29-LiveBuffer-0.0.7/dvbplayer.c vdr-1.3.29-LiveBuffer-0.0.7E/dvbplayer.c --- vdr-1.3.29-LiveBuffer-0.0.7/dvbplayer.c 2005-08-18 20:29:07.000000000 +0200 +++ vdr-1.3.29-LiveBuffer-0.0.7E/dvbplayer.c 2005-08-18 19:49:22.000000000 +0200 @@ -211,7 +211,8 @@ int SkipFrames(int Frames); void SkipSeconds(int Seconds); void Goto(int Position, bool Still = false); - virtual bool GetIndex(int &Current, int &Total, bool SnapToIFrame = false, bool onlyExisting = false); + virtual bool GetIndex(int &Current, int &Total, bool SnapToIFrame = false); + virtual bool GetIndexE(int &Current, int &Total, bool SnapToIFrame = false, bool onlyExisting = false); virtual bool GetReplayMode(bool &Play, bool &Forward, int &Speed); void Rew(bool On); }; @@ -741,7 +742,12 @@ } }
-bool cDvbPlayer::GetIndex(int &Current, int &Total, bool SnapToIFrame, bool onlyExisting) +bool cDvbPlayer::GetIndex(int &Current, int &Total, bool SnapToIFrame) +{ + return GetIndexE(Current, Total, SnapToIFrame); +} + +bool cDvbPlayer::GetIndexE(int &Current, int &Total, bool SnapToIFrame, bool onlyExisting) { if (index) { if (playMode == pmStill) @@ -843,10 +849,15 @@ return -1; }
-bool cDvbPlayerControl::GetIndex(int &Current, int &Total, bool SnapToIFrame, bool onlyExisting) +bool cDvbPlayerControl::GetIndex(int &Current, int &Total, bool SnapToIFrame) +{ + return GetIndexE(Current, Total, SnapToIFrame); +} + +bool cDvbPlayerControl::GetIndexE(int &Current, int &Total, bool SnapToIFrame, bool onlyExisting) { if (player) { - player->GetIndex(Current, Total, SnapToIFrame, onlyExisting); + player->GetIndexE(Current, Total, SnapToIFrame, onlyExisting); return true; } return false; diff -Naur vdr-1.3.29-LiveBuffer-0.0.7/dvbplayer.h vdr-1.3.29-LiveBuffer-0.0.7E/dvbplayer.h --- vdr-1.3.29-LiveBuffer-0.0.7/dvbplayer.h 2005-08-18 20:29:07.000000000 +0200 +++ vdr-1.3.29-LiveBuffer-0.0.7E/dvbplayer.h 2005-08-18 19:03:44.000000000 +0200 @@ -42,7 +42,8 @@ // The sign of 'Seconds' determines the direction in which to skip. // Use a very large negative value to go all the way back to the // beginning of the recording. - bool GetIndex(int &Current, int &Total, bool SnapToIFrame = false, bool onlyExisting = false); + bool GetIndex(int &Current, int &Total, bool SnapToIFrame = false); + bool GetIndexE(int &Current, int &Total, bool SnapToIFrame = false, bool onlyExisting = false); // Returns the current and total frame index, optionally snapped to the // nearest I-frame. bool GetReplayMode(bool &Play, bool &Forward, int &Speed); diff -Naur vdr-1.3.29-LiveBuffer-0.0.7/menu.c vdr-1.3.29-LiveBuffer-0.0.7E/menu.c --- vdr-1.3.29-LiveBuffer-0.0.7/menu.c 2005-08-18 20:29:07.000000000 +0200 +++ vdr-1.3.29-LiveBuffer-0.0.7E/menu.c 2005-08-18 19:08:31.000000000 +0200 @@ -3569,7 +3569,7 @@ { int Current, Total;
- if (GetIndex(Current, Total, false, true) && Total > 0) { + if (GetIndexE(Current, Total, false, true) && Total > 0) { if (!visible) { displayReplay = Skins.Current()->DisplayReplay(modeOnly); displayReplay->SetMarks(&marks); diff -Naur vdr-1.3.29-LiveBuffer-0.0.7/player.h vdr-1.3.29-LiveBuffer-0.0.7E/player.h --- vdr-1.3.29-LiveBuffer-0.0.7/player.h 2005-08-18 20:29:07.000000000 +0200 +++ vdr-1.3.29-LiveBuffer-0.0.7E/player.h 2005-08-18 19:10:50.000000000 +0200 @@ -44,7 +44,8 @@ cPlayer(ePlayMode PlayMode = pmAudioVideo); virtual ~cPlayer(); bool IsAttached(void) { return device != NULL; } - virtual bool GetIndex(int &Current, int &Total, bool SnapToIFrame = false, bool onlyExisting = false) { return false; } + virtual bool GetIndex(int &Current, int &Total, bool SnapToIFrame = false) { return false; } + virtual bool GetIndexE(int &Current, int &Total, bool SnapToIFrame = false, bool onlyExisting = false) { return false; } // Returns the current and total frame index, optionally snapped to the // nearest I-frame. virtual bool GetReplayMode(bool &Play, bool &Forward, int &Speed) { return false; }
vdr@helmutauer.de wrote:
Hi,
A nice new patch arrived at VDR-Portal: http://www.vdr-portal.de/board/thread.php?threadid=37309&sid=&hiligh... With this Patch VDR can do permanent timeshift, so you can see the last scene again whenever you want :-) I know Klaus, you won't like the question, but do you see a chance of integrating it in 1.3. x ? It would be great to see this feature in a stable 1.4. release.
I'm in the process of making a stable version 1.4. At this stage I can't accept such a large modification - otherwise we would never get to 1.4.
Besides, I've stated my opinion on this matter on several occasions ;-)
Klaus
bergwinkl.thomas@vr-web.de(Thomas Bergwinkl) 18.08.05 14:40
Philippe Gramoulle wrote:
Hello,
On Thu, 18 Aug 2005 14:07:49 +0200 (CEST) vdr@helmutauer.de wrote:
| With this Patch VDR can do permanent timeshift, so you can see the last scene again whenever you want :-)
Sorry, i'm not sure to fully understand what new functionality this patch brings. Can you elaborate what you mean by "permanent timeshift" ?
How does it differ from current behavior ?
The patch does following:
- it always records the channel you are watching,
Super!
when you switch channel a new recording starts and the old will be deleted
"immediately" because it would be too complicate to let the "mainly viewed stream" continue being recorded while zapping, so after zapping back i can see the timeshifted record starting at the moment of the first "zapp". ;-) OK, the next step would be: record always all available transponders in a 2h ringbuffer... let's call it "predictive timeshift(c)". But i assume that's already patented, at least in USA.
- so you are able to repeat a scene if for example you didn't
understand something
Great!
If would be good if the replay could drop frames so it will -slowly- catchup to the real time stream. (I the user want's to).
- or when you are watching a film, and you decide during the film,
that you want to record it, you can do so, if the beginning is in the livebuffer (new timer -> LiveBuffer: yes)
How big is the buffer?
- you can turn on/off this functionality in menu -> setup ->
recording -> LiveBuffer
Important ;-)
there you can also set the size for the livebuffer (in MB)
Ah.
Thanks for making the patch!
Lauri Tischler wrote:
Klaus Schmidinger wrote:
Plugins should _always_ run with plain vanilla VDR and never require a "specially patched" version of VDR!
subtitles and ttxtsub _need_ patched VDR.
I was referring to a patch that changed VDR in a way that (other) plugins don't work any more _without_ that patch. If a plugin thinks it has to patch VDR, and that patch has no implications for other plugins, that's not the problem.
Klaus
Rainer Zocholl a écrit :
bergwinkl.thomas@vr-web.de(Thomas Bergwinkl) 18.08.05 14:40
when you switch channel a new recording starts and the old will be deleted
"immediately" because it would be too complicate to let the "mainly viewed stream" continue being recorded while zapping, so after zapping back i can see the timeshifted record starting at the moment of the first "zapp". ;-) OK, the next step would be: record always all available transponders in a 2h ringbuffer... let's call it "predictive timeshift(c)". But i assume that's already patented, at least in USA.
See recent thread "BBC To Open Source This Project" : this one stores all data from all available transponders for 7 days... We're a little VDR patch away from this...
If would be good if the replay could drop frames so it will -slowly- catchup to the real time stream. (I the user want's to).
Not slowly catching up allows to drop ads and recover from your 15' start delay when reaching the end of the program.
Rainer Zocholl wrote:
Sent: Thursday, August 18, 2005 11:02 PM To: vdr@linuxtv.org Subject: Re: [vdr] VDR LiveBuffer Patch
bergwinkl.thomas@vr-web.de(Thomas Bergwinkl) 18.08.05 14:40
Philippe Gramoulle wrote:
Hello,
On Thu, 18 Aug 2005 14:07:49 +0200 (CEST) vdr@helmutauer.de wrote:
| With this Patch VDR can do permanent timeshift, so you can see the last scene again whenever you want :-)
Sorry, i'm not sure to fully understand what new functionality this patch brings. Can you elaborate what you mean by "permanent timeshift" ?
How does it differ from current behavior ?
The patch does following:
- it always records the channel you are watching,
Super!
when you switch channel a new recording starts and the old will be deleted
"immediately" because it would be too complicate to let the "mainly viewed stream" continue being recorded while zapping, so after zapping back i can see the timeshifted record starting at the moment of the first "zapp". ;-)
If you want to keep a channel in the buffer you have to do following: Activate Keep paused LiveBuffer Then when you watch a channel and press e.g pause or rewind, and switch channel, the buffer won't be deleted and you can watch the film, starting at the momement of the first "zapp", when you switch back zu that channel.
OK, the next step would be: record always all available transponders in a 2h ringbuffer... let's call it "predictive timeshift(c)". But i assume that's already patented, at least in USA
- so you are able to repeat a scene if for example you didn't
understand something
Great!
If would be good if the replay could drop frames so it will -slowly- catchup to the real time stream. (I the user want's to).
I don't understand what you exactly want.
Thomas
"Thomas Bergwinkl" bergwinkl.thomas@vr-web.de wrote:
If would be good if the replay could drop frames so it will -slowly- catchup to the real time stream. (I the user want's to).
I don't understand what you exactly want.
i think, the OP is refering to a feature some commercial set top boxen do have. they allow a previously paused live view to catch up with the ongoing program after "unpaused" by doing a slightly fast forward, not really noticable.
clemens
Clemens Kirchgatterer wrote:
"Thomas Bergwinkl" bergwinkl.thomas@vr-web.de wrote:
If would be good if the replay could drop frames so it will -slowly- catchup to the real time stream. (I the user want's to).
I don't understand what you exactly want.
i think, the OP is refering to a feature some commercial set top boxen do have. they allow a previously paused live view to catch up with the ongoing program after "unpaused" by doing a slightly fast forward, not really noticable.
Just droping frames would probably no good idea, I think. Somethink more complex would be neccessary. At the moment I don't see, which advantage you have, if you catchup with the live video. In my opinion it is better not to do so. When the next commercial break starts you can jump to the end and mustn't watch it.
So, when you know a simply way to implement this, I could make a setup option for this. But if there is no simple way, I won't add this "feature".
Thomas
Thomas Bergwinkl wrote: ...
At the moment I don't see, which advantage you have, if you catchup with the live video. In my opinion it is better not to do so. When the next commercial break starts you can jump to the end and mustn't watch it.
I totally agree.
Gee, I prepared my dinner later than other people on the other end of the world, so now I have to eat only half of the appetizer and only half of the main course in order to catch up with them? ;-)
And: I do not see what this has to do with the LiveBuffer Patch. If many people are in a hurry and want to watch a recording in half the time, why would that only be useful for recordings that happen to originate from the LiveBuffer Patch? If there really is a majority out there that would like to watch a recording faster than in real time, maybe the feature should be a general playback feature of VDR.
Seriously: I guess it might be nice to be able to do FF and SF (within limits) *with* audio. That's what the feature described by Rainer really is.
Carsten.
After just testing vdr-1.3.29-LiveBuffer-0.0.8.diff, I started to notice that if I rewind the live buffer, then change channels, I get this error:
ERROR: attempt to use cPlayer::PlayPes() without attaching to a cDevice!
My system has only a single FF card. Perhaps this would not be noticable if there is more than one tuner.
Best Regards.
C.Y.M wrote:
After just testing vdr-1.3.29-LiveBuffer-0.0.8.diff, I started to notice that if I rewind the live buffer, then change channels, I get this error:
ERROR: attempt to use cPlayer::PlayPes() without attaching to a cDevice!
My system has only a single FF card. Perhaps this would not be noticable if there is more than one tuner.
Actually, I don't think rewinding the buffer and switching channels is what is triggering this. Now I'm not quite sure what is causing it. Does anyone else see this?
Regards.
C.Y.M wrote:
C.Y.M wrote:
After just testing vdr-1.3.29-LiveBuffer-0.0.8.diff, I
started to notice that if
I rewind the live buffer, then change channels, I get this error:
ERROR: attempt to use cPlayer::PlayPes() without attaching
to a cDevice!
My system has only a single FF card. Perhaps this would
not be noticable if
there is more than one tuner.
Actually, I don't think rewinding the buffer and switching channels is what is triggering this. Now I'm not quite sure what is causing it. Does anyone else see this?
Yes, I also get this error sometimes. But it's nothing to worry about. It could happen when the dvbplayer is deleted. When you add Cancel(3); in cDvbPlayer::~cDvbPlayer() before Detach(); this error should no longer occur.
Thomas
Yes, I also get this error sometimes. But it's nothing to worry about. It could happen when the dvbplayer is deleted. When you add Cancel(3); in cDvbPlayer::~cDvbPlayer() before Detach(); this error should no longer occur.
Thanks, Thomas. That seems to have fixed it. :)
Best Regards.
C.Y.M wrote:
Yes, I also get this error sometimes. But it's nothing to worry about. It could happen when the dvbplayer is deleted. When you add Cancel(3); in cDvbPlayer::~cDvbPlayer() before Detach(); this error should no longer occur.
Thanks, Thomas. That seems to have fixed it. :)
Have you considered using a RAM drive for the buffer? What were the problems? I noticed some comments about it in the patch.
Best Regards.
C.Y.M wrote:
C.Y.M wrote:
Yes, I also get this error sometimes. But it's nothing to
worry about.
It could happen when the dvbplayer is deleted. When you add
Cancel(3);
in cDvbPlayer::~cDvbPlayer() before Detach(); this error should no longer occur.
Thanks, Thomas. That seems to have fixed it. :)
Have you considered using a RAM drive for the buffer? What were the problems? I noticed some comments about it in the patch.
There should be no problem. You can specify the directory, where the livebuffer should be written to, with option -b. The LiveBufferSize should be a few MB smaller than the size of the ramdisk (because of index.vdr and the 001.vdr gets a little bit larger than LiveBufferSize) and 'Keep paused LiveBuffer" should be no.
Thomas
There should be no problem. You can specify the directory, where the livebuffer should be written to, with option -b. The LiveBufferSize should be a few MB smaller than the size of the ramdisk (because of index.vdr and the 001.vdr gets a little bit larger than LiveBufferSize) and 'Keep paused LiveBuffer" should be no.
Since Reinhard Nissl just released a fix for cvideorepacker, I have removed the portion of the livebuffer patch which disabled it. It seems to be working well now with cvideorepacker enabled. :)
Best Regards.
Carsten.Koch@icem.com(Carsten Koch) 19.08.05 17:37
And: I do not see what this has to do with the LiveBuffer Patch.
Because the OP mentioned, the "Instand Replay" would be good if one did not understand what was said.
If many people are in a hurry and want to watch a recording in half the time, why would that only be useful for recordings that happen to originate from the LiveBuffer Patch?
ACK.
If there really is a majority out there that would like to watch a recording faster than in real time, maybe the feature should be a general playback feature of VDR.
Seriously: I guess it might be nice to be able to do FF and SF (within limits) *with* audio. That's what the feature described by Rainer really is.
ACK. I have such an analog(!) VCR and found it VERY convinient to "fast forward with sound" without having to watch all the time! VDR "skip 1 minute" is not a real replacement of that, because i often miss the right point where to continue. As the "FF speed with sound" was selectabel it was possible to "slow fast forward" over uninteressting parts of a discussion or a report. Watching a movie this way would be waste of time, dacore.
It was 'simply' implemented by dropping/duplicateing(*) "frames" ("probes" or "samples"), in sound too. So the tune (sound frequency) was not effected (in limits)! Sometimes an entire word was dropped, but i assume in digital world it would be possible to drop smaler samples and to do that if sound level is low, adding sone "error corrections"/interpolation.
(*) Of cause it was possible to have "slow motion with sound". Very convienient to learn foreign languages, ideally if the sound could be kept lipp sync (the analog device couldn't).
Rainer
On Sunday 21 August 2005 14:09, Rainer Zocholl wrote:
I have such an analog(!) VCR and found it VERY convinient to "fast forward with sound" without having to watch all the time! VDR "skip 1 minute" is not a real replacement of that, because i often miss the right point where to continue.
As an aside, it is very easy to add remote keys for skip forwards and backwards by 10 s using, e.g. '1' and '3' on the remote. Just add a few extra lines near the end of menu, similar to the entries for kYellow and kGreen.c.
I've done so and it makes skipping short bits so much easier, especially with the dxr3 or xine output devices I have which don't always do trickspeed very well!
Cheers,
Laz
-
C.Y.M -
Carsten Koch -
Clemens Kirchgatterer -
Klaus Schmidinger -
Lauri Tischler -
Laz -
Nicolas Huillard -
Philippe Gramoullé -
Rainer Zocholl -
Sergei Haller -
Thomas Bergwinkl -
Thomas Günther -
vdr＠helmutauer.de