Forums

That would have to be treated specially as following scenario can happen:
User have pre- 10 minutes and post- 20 minutes. Current TV channel has now e.g. 4 consecutive events by 5 minutes. That means you started 4 recordings just because of time shift. Imagine that you record something at the same time and you already achieved I/O limits on most machines.

As far as I know is it not possible to make more than one timeshift recording at a time with the current implementation. You'll have to change C++ part for it... And mik9 suggestions are right. It would be difficult to implement.
I would prefer one big timeshift file and bookmarks
Edited by betacentauri, 21 February 2013 - 00:19.

Hi all I think that there may be a problem with user expectation with the number keys. If you look at the two basic operations
1 Watching TV number keys zap
2 Watching a movie number keys skip

From my point of view watching Timeshifted TV is an extension of Watching TV so I would expect the number keys to zap with the warning of exit to live TV etc

One big enough file with proper kind of marking would be fine. There is only one problem, that you have to ensure somehow that it will be buffering (and still keep markers in correct positions), i.e. once it exceeds pre-set time (e.g. 4 hours) it must move the content like in the buffer. As this is huge amount of data I do not know if this will be reasonably achievable. Of course, several smaller files could be employed instead of one big and just the oldest would be deleted, so rotation could be used. However, more files mean that you need to solve problem with exact continuation from one file to another, to avoid any gaps like the one in PTS.

guys rewinding with multiple speeds in timeshift mode is working again. Many thanks for that.

VU+ Uno
Internal HDD

Hi all I think that there may be a problem with user expectation with the number keys. If you look at the two basic operations
1 Watching TV number keys zap
2 Watching a movie number keys skip

From my point of view watching Timeshifted TV is an extension of Watching TV so I would expect the number keys to zap with the warning of exit to live TV etc

My point exactly.
I find it most annoying when elementary buttons change their behaviour on context.
Except from the original dreambox I suppose all receivers have proper dedicated buttons for basic play, skip and (re-wind). I realy don't see the necessity to skip with the number keys.
It only confuses the user. (I realize that an enigma receiver is nearly unusable for a noop, though)
The UI is always the hardest part on a programming project but its always getting the lowest priority. This thread is a good example for that.
Edited by umtauscher, 21 February 2013 - 15:16.

The skip with the number keys is much much more easier than fast forward and (fast) rewinding.... That is why this feature was added...
When I implemented it on E1 years years ago I used the <> keys next to the 0 key for that... Later in E2 it became at the numberkeys in the movieplayer and timeshift mode (as in the movie player the number keys are not used at all)...
Once used to the step skip you see the advantaged and you do never fast forward and fast rewind anymore ....
I think it does not confuse at all.... It is part of the added value of E2
Edited by littlesat, 21 February 2013 - 15:40.

Skipping with numbers is very useful! Thanks for keeping it that way.

Just to make myself clear, I have nothing against skipping. In fact I use it all the time.
What I pledge against is using the number keys.

I agree that when skipping with a fixed distance, 2 buttons are not enough.
But if you use an iteration skip which reduces skipping distance when changing the direction, you can skip to a certain point much faster, even faster than using the number keys.

Let me explain:
You start with an initial skiiping distance, e.g. 5 Minutes. ( you could use the skipping distance of 7 and 9 for that). As long as you skip in the same direction, the skip would remain that distance.
Once you see, that you skipped too far, you skip in the opposite direction, but with that direction change the distance ist reduced to half. So you skip half the distance, until you have skipped too far. So you change direction again while the distance is reduced again.
That way, you find your target position very fast. I know, in theory its quite hard to follow, but when using it, its really great.
That way, you would only use 2 button, the < and > would be perfect for that.
Just think about it.
Cheers
Umtauscher
Edited by umtauscher, 21 February 2013 - 20:28.

That idea i tried here... But is really a nightmare. As user you need to expect and control the skip sizes...

Hmm, I don't understand. I was using it for years and it worked great.

Anyone who wants to try a "simulation" just start with skipping with the number 9 and press 4 when you've skipped too far. If the back skip is too far, press 3 until you get near the position.

You cannot reduce further than 3 so the simulation ends here, but you could see what I mean.

When you want to skip to a new position start with 7 or 9 again and iterate to the target position.

I suspect the implementation of your testing was not quite orrect.

Btw. the user always starts with the biggest step, so the distance is always known. Pressing once forward and twice backwards always returns to the start position.
Cheers
Umtauscher.

If I had any python and enigma skills I would program it myself.
Edited by umtauscher, 21 February 2013 - 21:13.

the user always starts with the biggest step, so the distance is always known. Pressing once forward and twice backwards always returns to the start position.

Not to me.... here the steps are going well....
Edited by littlesat, 21 February 2013 - 22:23.

For this iteration (or binary) skipping you not only need 2 buttons but at least one more. As sometimes you can mess with skipping and get too short interval in incorrect place so that you would not be able to quickly achieve correct point unless you reset current skip length to some higher number. So you need something like reset to 1 or 2 minutes or simple menu that will let you choose what interval you want for next skip.

But it still takes performance...

It SHOULD not. When handled properly, the recording will take place in background, and there is no impact on "zap speed" or whatever. If it has any impact on performance, I would consider that a bug.

You never owned a Topfield I guess. The good old TF4000 had an excellent permanent timeshift function which demonstrated this feature perfectly (with a 150MHz PPC CPU and 9MB RAM). The only reason to disable the timeshift on that receiver was to reduce power consumption.

For this iteration (or binary) skipping you not only need 2 buttons but at least one more

The plugin I used had a timeout, after which the step was reset to the initial value. So I only had to wait a few seconds to begin again.
That timeout was adjustable in the menue.
I never used more that those 2 skip buttons. (Software developers tend to complicate things more than necessary) ;-)

Where would I start to develop a plugin that implements skipping?
Edited by umtauscher, 22 February 2013 - 13:28.

All this number skip blah is overcomplicated ...

Well, as long as the common controls FFWD and RWD work, I don't care about it as the number keys are useless anyways ... I guess nobody continues to number zap after being confronted with >30 channels

I offered an easy option.
Live TV will never be = no number zap
or
long key stop = Live TV

Long key stuff should be avoided...

I would like to add marks(for skipping) to timeshift file. I can do it in 2 ways:[list=1]
[*]Like in eDVBServiceRecord: Storing unmodified pts from now/next events in memory and when timeshift stops, store it in .cuts file (Assume that timeshift file won't be deleted after timeshift stop! This is in work...). Problem is that you can't use marks while timeshifting only afterwards.
[*]In eDVBServicePlay store pts values from now/next events in m_cue_entries. Then you can theoretical use them while timeshifting. Problem is that I need to fixup pts values in order to use them (fixup: PTS values in cuts are zero-based). While watching timeshift file this is no problem. But in live TV I have no pvrChannel and can't call getCurrentPosition(this calls fixupPTS).
What can I do? Can I create a tstools instance and call fixupPTS? But then timeshift file and .sc are opened while other thread is writing to these files. Sounds not very good.
Another idea is to store pts value from start of timeshift file and to fixup pts in eDVBServicePlay without calling tstools.
Has anybody another idea how to get it working?
[/list]

I'm confused, what is going on with the actual PTS?
Yesterday I updated and all warnings for zapping from timeshift are gone. Even the arrow keys on the nummber pad zap now and kill the timeshift buffer without warning. Is this a regression bug or is the behaviour changed again?