747 replies to this topic

[betacentauri]

And for me switch to live tv don't always work while fast forwarding.

probably because I limited the file offset to end-of-file + 1MB

http://openpli.git.s...c7ac638011fc887

when the distance between end of file samples is more than 1MB, it might happen that skipping to end-of-file + 1MB does not cause a switch to the live point.

This is what I found out: When fast forward reaches file end (it must be > 8x fast forward!) this happens:[list]
[*]In eDVBChannel::getNextSourceSpan m_tstools.findNextPicture fails and "frame skipping failed, reverting to byte-skipping" is visible in the logs.
[*]m_tstools.findFrame (also in getNextSpan) is then executed with offset = current_offset + align(m_skipmode_m, , blocksize);
New offset is bigger than filesize!
[*]In findFrame a frame is found with offset < _offset(function parameter)
[/list]
So a frame is found, but the found offset is smaller than the given offset. (I hope you understand it. Here is how it looks in the logs):

we are at 210397192, and we try to skip 32+0 frames from here				  
trying to move 32 frames at 210397192										  
trying to find iFrame at 210397192
result: offset=210548384, len: 43044											
we moved 10, 22 to go frames (now at 210548384)
result: offset=210548734, len: 42694											
we moved 0, 22 to go frames (now at 210548734)
trying to find iFrame at 210548734
result: offset=210739392, len: 45300											
we moved 10, 12 to go frames (now at 210739392)								
trying to find iFrame at 210739392
result: offset=210739554, len: 45138											
we moved 0, 12 to go frames (now at 210739554)								  
trying to find iFrame at 210739554
result: offset=210925700, len: 46804											
we moved 10, 2 to go frames (now at 210925700)								  
trying to find iFrame at 210925700
result: offset=210925862, len: 46642											
we moved 0, 2 to go frames (now at 210925862)								  
trying to find iFrame at 210925862  
[eMPEGStreamInformation] index 12078 is past EOF								
getStructureEntryNext failed, no data					  
findFrame failed!  
frame skipping failed, reverting to byte-skipping							  
we are at 212197104, and we try to find the iframe here:						
trying to find iFrame at 212197104
result: offset=210328210, len: 69014

The last 4 lines are important. We start with offset 212197104 and find a frame with offset 210328210 (it's a fast forward!!!).
According to tstools.h "findFrame will look for the specified frame type starting at the given position, moving forward (when direction is >0) or backward (when direction is <0)" I would say that the result is not correct.
I would add at the end of findFrame something like this:

if ((direction >= 0 && start < _offset) || (direction < 0 && start > _offset)) then return -1;

A very short test, worked here.

Edited by betacentauri, 18 February 2013 - 23:34.

[adri]

I would prefer skip back.... in live mode... As I usually never use rewind...

With backskip I meant the 1, 4 and 7 button that is usually default 15 sec, 1 min and 5 min skip back...

As live mode is not seekable now the keybuttons do nothing. What in fact should be done is when in live mode (so timeshift enabled) and backskip (negative value)... then turn on timeshift again in the recording and do the backskip in the timeshift file....

I would also prefer the 'backskip' mode using the 1,4,7 buttons working just like in a normal recording.

[daddelfalk]

Hi folks,

and here comes another refresh.

- more work on "dont seek past end of file stuff" when skipping with number buttons

http://git.opendream...264fd06fa389b66


and

- fixed broken live to timeshift transition

http://git.opendream...19c1f0f744dc51f

Edited by daddelfalk, 19 February 2013 - 12:13.

[Dimitrij]

So 'backskip' works:

def __seekableStatusChanged(self):
  self["TimeshiftActivateActions"].setEnabled(not self.isSeekable() and self.timeshift_enabled)
  state = self.getSeek() is not None and self.timeshift_enabled
  self["SeekActions"].setEnabled(state)
  if not state:
+   if self.timeshift_enabled:
+    ts = self.getTimeshift()
+    if ts is None:
+	 return
+    if ts.isTimeshiftActive():
+	 self.pauseService()
+    else:
+	 ts.activateTimeshift()
+	 self.setSeekState(self.SEEK_STATE_PAUSE)
   self.setSeekState(self.SEEK_STATE_PLAY)

But I want to enable number zap(only switch back to live).
To switch back to live point the user has to press a specific button (e.g. |> for ET).
For this you need something like this patch:
http://git.opendream...5484b0c8e20a080

P.S.For VU+ fast forwarding->switch to live tv is much more stable.
I guess it depends on the drivers.

[littlesat]

But I want to enable number zap(only switch back to live).

Please not!!! Timeshift is timeshift... use stop timeshift to get back to numberzap..... I suggest this is more logical... During timeshift the numbers are assigned to the stepskip stuff and not NumerZap and we should keep that. Even with live... as this is still timeshift.

And why do you need the DMM feature? Just jump beyond the live point should be enough I suggest.... A stepskip forwarded (just) beyond the end of the file should do the same.

The patch you described above I do not fully understand....

def __seekableStatusChanged(self):  
  self["TimeshiftActivateActions"].setEnabled(not self.isSeekable() and self.timeshift_enabled)  
  state = self.getSeek() is not None and self.timeshift_enabled  
  self["SeekActions"].setEnabled(state)  
  if not state:  
+   if self.timeshift_enabled:  
+	ts = self.getTimeshift()  
+	if ts is None:  
+		return  
+	if ts.isTimeshiftActive():  
+		self.pauseService()  
+	else:  
+		ts.activateTimeshift()  
+		self.setSeekState(self.SEEK_STATE_PAUSE)  
   self.setSeekState(self.SEEK_STATE_PLAY)

It is about the last part.... should we set the state to pause and play just after eachother???

P.S.For VU+ fast forwarding->switch to live tv is much more stable.
I guess it depends on the drivers.

Likely....

Edited by littlesat, 19 February 2013 - 15:27.

[Dimitrij]

As live mode is not seekable now the keybuttons do nothing. What in fact should be done is when in live mode (so timeshift enabled) and backskip (negative value)... then turn on timeshift again in the recording and do the backskip in the timeshift file....

... then turn on timeshift again=patch
Just check for the interest ...

[littlesat]

??? Sorry I do not understand you... with turn on timeshift again I meant here stop with live mode and go back with timeshift...

Edited by littlesat, 19 February 2013 - 17:02.

[Dimitrij]

with turn on timeshift again I meant here stop with live mode and go back with timeshift...

this is it

[littlesat]

That patch does stop stop the livemode... and put the timeshift into a ~ 1 sec "slopstream" so that indeed stepskip is always alowed.... Still not a bad idea....

[umtauscher]

Hi,

as I said before, I am a PTS user. So timeshift is "kind of always" on.
This means a pressing a number key should zap.
I understand you don't use PTS but I think PLI should behave like other receivers concerning the PTS.

So I would strongly suggest leaving the behaviour as ist is.

A sidenote: Using the number buttons to skip during timeshift basically is a bad idea from the UI's point of view. Once you accidentally skip past the live point the buttons instantly change their function without the user knowing.

If I had to design it, I would cancel skipping with the number keys all together. There are better ways to skip, for example with 2 buttons which change the skipping distance when the direction is changed. A good example is the "fastskip" plugin found on Topfield receivers.

Just my 2 cts.
Umtauscher

Edited by umtauscher, 19 February 2013 - 20:08.

[Meega]

Please not!!! Timeshift is timeshift... use stop timeshift to get back to numberzap..... I suggest this is more logical... During timeshift the numbers are assigned to the stepskip stuff and not NumerZap and we should keep that. Even with live... as this is still timeshift.

i am also using pts because in my opinion timeshift shut be always on ,otherwise you can press the record button.
So the numberzap must be present when timeshifting.
If you're watching timeshift ,then you can use stepskip.

Timeshifting is not only to skip adds or something but also to look things back, thats why i use timeshifting (pts) and when you use stepskip instead of numberzap then i can't zap with numbers anymore.

[littlesat]

I'm thinking timeshift should not always be ON... Only ON on demand... so it does not eat al those performance....

[Meega]

I'm thinking timeshift should not always be ON... Only ON on demand... so it does not eat al those performance....

What do you mean by performances?
There is not a problem with my box when timeshifting.

[atilaks]

I am also a pts user, but I really love stepskipping and I zap via channel list

so my question is... would it be possible to make number zapping / stepskipping (while in timeshift) a configuration parameter in enigma2 and let users decide what they want?

Edited by atilaks, 19 February 2013 - 21:04.

[littlesat]

What do you mean by performances?
There is not a problem with my box when timeshifting.

The recording must be constantly done -> performance... (the stream you're watching is recorded)
During zapping the timeshift must be stopped... and a new one started -> performance...

???

And when do you really -be honest- step back?

[Meega]

What do you mean by performances?
There is not a problem with my box when timeshifting.

The recording must be constantly done -> performance... (the stream you're watching is recorded)
During zapping the timeshift must be stopped... and a new one started -> performance...

???

And when do you really -be honest- step back?

Quite often if i didn't understand something ,because of noise (kids) in the room.
But that's not the point,the point is that if you change the behavior of the number keys when pressing them during timeshift ,the plugins pts and autotimeshift become useless (for people who use the number keys for zapping do)
And i think there are a lot of people using those plugins.(including me)

But why not a configurable something ( i know, again configurable).

[Sjaaky]

@littlesat: but it shouldn't be a problem. And if it proves to be a problem, than the implementation is faulty. Of course the box has to work harder, but it is just a machine. If zapping slows because of it, it just means the implementation should be optimized.

Edited by Sjaaky, 19 February 2013 - 21:39.

[littlesat]

But it still takes performance... it uses a harddisk or USB stick or other media... so still it user performance... and extra power and energy... etc.... Indeed it is just a machine and indeed when it was good implemented at the beginning it works optimal... and still it is everyone own desician to turn it on or off... and when it is available we should try to get it perform good...

Based on zapping it is always slower... As first we need to stop the timeshift before we can stop the currently playing service what should be done before we can select the new service... .... but who'll notify that?

Edited by littlesat, 19 February 2013 - 21:50.

[mik9]

To be honest - I very rarely use timeshift a planned way (on demand), i.e. when I expect some longer disturbance and press pause. But at least several times a day I use short skip back to watch something because of short disturbance or just because I want to see some part again (esp. in documents and sports). So I support the idea that timeshift should run all time, just except when there is no media or too low free space. Timeshift on demand is in fact just recording, for this no special function would even be necessary.

Edited by mik9, 19 February 2013 - 22:56.

[SpaceRat]

I agree there should be at least an option to have real and working permanent timeshift.
Whining about the performance it uses is like whining about the electrical energy my oven consumes when heating my food. I won't eat it cold anyways.

A timeshift that needs manual activation is quite useless when unexpected interruptions occur. Sure, you can activate timeshift when the phone or the door bell rings. But then you can't get back to what you missed due to the bell.

My opinion: Don't get a HDD receiver if all you want to do is to keep the channel up or down key pressed and stop the time the receiver needs for switching channels. I really do watch TV. That means, I switch to the channel I want to watch and then ... uhm ... just watch it.
Yes, really, I do.