747 replies to this topic

[malakudi]

As a Permanent Timeshift (PTS) user myself, I have to add that even this is not optimal. A real permanent timeshift should never be cleared on zap. Something like Live Buffer that some boxes have. Then you can rewind even if you changed channel.

About the numeric keys, I personally don't care. I never zap with numeric keys. But when changing a behaviour that was a standard for many years, please make it optional for people that need the old behaviour (unless ofcourse it breaks something).

Edited by malakudi, 20 February 2013 - 00:17.

[mik9]

This live buffer is nice feature, it would mean there is no need to protect timeshift against unwanted zapping as even if you zap by accident, you loose only few seconds until you zap back but not e.g. 20 minutes of the recent delay.

On the other hand, I like some specific features of Permanent Timeshift, like easy possibility to record timeshifted part of program and even choose from list of timeshifted events (this supposes EPG to be precise at least to some extent). Moreover, once you select timeshift to be recorded, you can zap and it will still record previously watched event until the end together with already timeshifted part.

One thing I do not like with PTS is that you cannot skip across the events, you must FF/RWD from one event to another and only then you can skip again. Also, there is small break between single events, even after I changed respective value in plugin to 0, it still takes about 0,5 sec of audio & video drop between events.

[SpaceRat]

I would call that feature "Follow TV".
Though I still prefer a warning when zapping, offering these options:
1 - Delete Timeshift and zap
2 - Turn timeshift into a recording (current program) and zap
3 - Turn timeshift into a recording (for a specific time) and zap
4 - Cancel

The following should happen when you press REC during timeshift (I do not use PTS, due to the gaps mentioned before, so I do not know if it has party been implemented there):
1 - Record current program from the beginning (=> Actually cutting the current program out of the timeshift buffer, obeying the pre-recording time set in the box! and turning that into a recording, ending T+post-recording-time set in the box)
2 - Record previous program (Assuming it is within the timeshift buffer, of course. Actually cutting the previous program out of the timeshift buffer, obeying the pre-recording and post-recording times set in the box!)
... - the other actions currently being offered

Of course instead of cutting out the previous/current program, permanent timeshift could as well buffer into seperate files for each program, but still obeying the pre- and post-recording times, resulting in overlapping recordings. This could also work around the audio gap problem by opening this || that recording for the overlapping time, depending on the direction of FFWD/RWND used to get to this point:
PAUSE/UNPAUSE within the overlapping time should always switch to the later recording.

[littlesat]

One thing I do not like with PTS is that you cannot skip across the events, you must FF/RWD from one event to another and only then you can skip again. Also, there is small break between single events, even after I changed respective value in plugin to 0, it still takes about 0,5 sec of audio & video drop between events.

Isn't it better then that we have one big timeshift recording and if you really want a specific event that you "cut" it out?

[maigais]

TimeShift examined the userbouquet.iptv,
Work break and then play does not start
DM 800HD ,OpenPLi-2.1

Edited by maigais, 20 February 2013 - 09:02.

[littlesat]

iptv cannot be timeshifted at the current time...
I just committed a fix when you come from timeshift and zap to a webstream...

[josjansen]

Isn't it better then that we have one big timeshift recording and if you really want a specific event that you "cut" it out?

Yes this I would really like to, PTS without events. http://openpli.org/f...-timeshift-pts/

Edited by josjansen, 20 February 2013 - 09:15.

[maigais]

I just checked on the image dreamboxupdate.com
and kept working perfectly userbouquet.iptv,

[littlesat]

@maigais,
What do you mean.....? does DMM do timeshift on IPTV (streams)? As far I know you should get a popup that identifies that this is not possible.

@josjansen.
Yesterday pieterg committed a suggestion from betacentauri that prepare to make it possible to store timeshift recordings. Probably we are close to integrate some kind of PTS in OpenPLi in short future.

Edited by littlesat, 20 February 2013 - 09:22.

[maigais]

I compared and verified oe2.0
everything works userbouquet.iptv,

enigma2 20130114 (master) -> 20130216 (master)
----------------------------------------------

- Mediaplayer: add possibility to clear the playlist from within playlist and filebrowser
- Hdmi CEC: Send Source Inactive when going into standby (not system standby which usually causes a total mess)
- SEC: dont use increased voltage for unicable by default.. .. always use 13V as low voltage.. but 18/19 by user config
- Teletext Subtitles: fixed wrongly displayed czech/slovak LATIN SMALL
LETTER T WITH CEDILLA instead of LATIN SMALL LETTER T WITH CARON
- UPnP: properly shut down the controlpoint with all devices WE (server,
renderer, etc) registered so they disappear from all clients
- fixed now/next query for services without entry in lamedb (e.g. IPTV services)
- added automatic inactivity shutdown timer after choosable time (by EU rule default 3 hours)
- added possibilty to skin listbox scrollbars
- fixed recording problems with enabled linux swap
- some twisted fixes (fixes some not working plugins without installed webif)
- changed stopTimeshift function a bit to allow switching to live ts but dont stop timeshift (can be used by external plugins)
- dont jump past end of file when do relative jumps in recordings
- add possibility to disable gstreamer subtitle support because of gstreamer memory leak

Edited by maigais, 20 February 2013 - 09:30.

[littlesat]

This is about timeshift and not about iptv stuff... As far I know now/next stuff should perform good already for a long time in our image... En even when DMM make a fix it is closed source and it has a licence... But still in this thread IPTV is offtopic... Please start a new thread on that one.

Edited by littlesat, 20 February 2013 - 09:36.

[maigais]

Well, I made ​​a screen with IPTV
present everywhere 0:00
and nothing happens

Attached Files

•  1.jpg   50.24KB   34 downloads
•  2.jpg   50.28KB   35 downloads

Edited by maigais, 20 February 2013 - 10:17.

[littlesat]

With IPTV you cannot do a timeshift!!! (but the EPG you see)

Edited by littlesat, 20 February 2013 - 10:37.

[betacentauri]

@josjansen.
Yesterday pieterg committed a suggestion from betacentauri that prepare to make it possible to store timeshift recordings. Probably we are close to integrate some kind of PTS in OpenPLi in short future.

Oh, great. I have almost finished the python changes. But I still need some hours to test and to merge the changes from the last days. When will your the image build process work again(the last 2 days there were no new images)?

[mik9]

Of course instead of cutting out the previous/current program, permanent timeshift could as well buffer into seperate files for each program, but still obeying the pre- and post-recording times, resulting in overlapping recordings. This could also work around the audio gap problem by opening this || that recording for the overlapping time, depending on the direction of FFWD/RWND used to get to this point:
PAUSE/UNPAUSE within the overlapping time should always switch to the later recording.

This could be potentially dangerous and definitely very often limiting. At the end of each event it would need to do 2 recordings at once and thus consuming twice as much resources. In case current events are short and pre- and post- times long enough, you can end up by even more than 2 recordings at the same time.

Isn't it better then that we have one big timeshift recording and if you really want a specific event that you "cut" it out?

It is also a possibility, I had this on DVB-T Topfield. It is only matter of convenience as it takes much longer time to cut out the proper part comparing to just choosing event from menu. But if you put markers for events, then it could be good compromise solution.

Edited by mik9, 20 February 2013 - 11:23.

[Dimitrij]

Plugin PTS patch for future updates(number zap) .

#InfoBarNumberZap Hack#
#######################
InfoBarNumberZap_keyNumberGlobal = InfoBarNumberZap.keyNumberGlobal
def keyNumberGlobal(self, number):
if self.pts_pvrStateDialog == "PTSTimeshiftState" and self.timeshift_enabled and self.isSeekable() and number == 0:
  InfoBarTimeshiftState._mayShow(self)
  self.pvrStateDialog["PTSSeekPointer"].setPosition(self.pts_seekpointer_MaxX/2, self.pvrStateDialog["PTSSeekPointer"].position[1])
  if self.seekstate != self.SEEK_STATE_PLAY:
   self.setSeekState(self.SEEK_STATE_PLAY)
  self.ptsSeekPointerOK()
  return
if self.pts_blockZap_timer.isActive():
  return
if self.save_current_timeshift and self.timeshift_enabled:
  InfoBar.saveTimeshiftActions(self)
  return
InfoBarNumberZap_keyNumberGlobal(self, number)
if number and config.plugins.pts.enabled.value and self.timeshift_enabled and not self.isSeekable():
-  self.session.openWithCallback(self.numberEntered, NumberZap, number, self.searchNumber)
+  self.check_timeshift = False
InfoBarNumberZap.keyNumberGlobal = keyNumberGlobal

[SpaceRat]

Of course instead of cutting out the previous/current program, permanent timeshift could as well buffer into seperate files for each program, but still obeying the pre- and post-recording times, resulting in overlapping recordings. This could also work around the audio gap problem by opening this || that recording for the overlapping time, depending on the direction of FFWD/RWND used to get to this point:
PAUSE/UNPAUSE within the overlapping time should always switch to the later recording.

This could be potentially dangerous and definitely very often limiting. At the end of each event it would need to do 2 recordings at once and thus consuming twice as much resources. In case current events are short and pre- and post- times long enough, you can end up by even more than 2 recordings at the same time.

It was just a suggestion and is potentially easier to accomplish than "on-the-fly" cutting.
However, it's the result that matters and that should be the possibility to create proper recordings of programs that have already started or even ended from timeshift.
Proper means, the recordings must still have the pre- and post-recording times obeyed as you would hardly ever get a complete program without them.

However, the first step would still be a working timeshift. PTS cannot be considered working due to the audio gaps in between programs, because they do not really occur in between programs as they are actually broadcasted but at the time they should have ended and the next program should have started, which never ever matches that exactly.
It works somewhat for movies when the end credits are fully broadcasted and/or a commercial break follows (audio gap occurs within the commercial break or during the end credits), but is useless for programs ending rather "hard" with the next one following instantly (audio gap within the program).

As German private stations tend to
- remove end credits
and
- have no or just a very short commercial break between programs (They would make it easier to zap away, so they put the breaks inside the program instead)
the likeliness is near 100% you will have the audio gap at some annoying place.

I stopped using PTS when I had to get a whole movie elsewhere, just to be able to listen to the last sentence that I missed on TV due to PTS silencing it.

[mik9]

If you want to minimize above mentioned gap, just edit one number in the following section. There must be zero in the last line, as you see:

   # (Re)Start TimeShift
   if not self.pts_delay_timer.isActive():
	if not self.timeshift_enabled or old_begin_time != self.pts_begintime or old_begin_time == 0:
	 if self.pts_service_changed:
	  self.pts_service_changed = False
	  self.pts_delay_timer.start(config.plugins.pts.startdelay.value*1000, True)
	 else:
	  print "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! pts_delay_timer.start(1000, True) !!!!!!!!!!!!!!!!!!!!!!!!"
	  self.pts_delay_timer.start(0, True)

Thus, you will shorten the gap by 1 second and you will only get very short gap caused by closing one file and starting file for next event, i.e. cca 0,5 sec. This modification does not cause any side effect for me on Vu+ Duo.

[malakudi]

Can you record the same program twice? If yes, then this could be solved by starting new timeshift buffer for the new event and then close the previous buffer.

[SpaceRat]

Can you record the same program twice? If yes, then this could be solved by starting new timeshift buffer for the new event and then close the previous buffer.

That was my suggestion. Remove the gap by making it overlap.Program code would just have to decide which recording to open. In most cases, that would be the later one.