Jump to content


Photo

Timeshifting problems with OpenPLi 3.0


  • Please log in to reply
747 replies to this topic

Re: Timeshifting problems with OpenPLi 3.0 #121 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 24 January 2013 - 19:38

Mhmm. I don't think that the jump back is the problem. Because the problem is still there when I wait 1-2 minutes
after unpause. So the step back can't reach begin of file. Or do you jump back several minutes when you only want to
jump back 15 seconds?


I have to correct me. I tested it again. This time I have waited 10 minutes after unpause. Now rewind works.
@littlesat: Can't you add something like this?
if timeshift_enabled and step_back < filestart
then use filestart+1
Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: Timeshifting problems with OpenPLi 3.0 #122 greatred

  • Senior Member
  • 268 posts

+2
Neutral

Posted 24 January 2013 - 19:38

Glad to see some interest in this problem ;)

Reinventing of the Timeshift function sound great but I think the amount of work needed will be extraordinary.

As a workaround can I propose following:
While opening the Movielist, always a file should be marked that is currently being recorded.
(don`t ask me how what the behavior should be when multiple recordings are running).

The reason I find it reasonable is following:
starting an instant record and going to playback mode again would take only 2 buttons (3rd one if we want to pause the playback and let the timeshift file grow).

What the guys with coding skills think of this?

EDIT:

@littlesat: Can't you add something like this?
if timeshift_enabled and step_back < filestart

then use filestart+1


This sound way better than my workaround :P

Edited by greatred, 24 January 2013 - 19:41.


Re: Timeshifting problems with OpenPLi 3.0 #123 littlesat

  • PLi® Core member
  • 56,306 posts

+691
Excellent

Posted 24 January 2013 - 19:40

I think stepseeking with the number keys is more easy then fast forward and reverse....

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Timeshifting problems with OpenPLi 3.0 #124 SpaceRat

  • Senior Member
  • 1,030 posts

+65
Good

Posted 24 January 2013 - 19:42

I don't need to use the 1,3 .. keys to seek, but everybody uses them and it would be difficult to change it without riot. On my old topfield stb was a nice binary search, which was really quite good.

Then obviously I'm not everybody.
I use the most natural way, the FFWD and RWND buttons. Well, I use the number keys when I have to, that is, when playing files from the server and seeking is broken (=works only with number keys).
1st box: Vu+ Ultimo 4k 4xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
2nd box: Gigablue Quad 4k 2xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
testing boxes: Vu+ Duo² + AX Quadbox HD2400 + 2x Vu+ Solo² + Octagon SF4008
Sats & Pay-TV: Astra 19.2°E + Hotbird 13°E with Redlight / SCT HD / SES Astra HD- / Sky V14 / 4th empire propaganda TV
Card-Server: Raspberry Pi + IPv6-capable oscam
Router: Linksys WRT1900ACS w/ LEDE + Fritz!Box 7390

Re: Timeshifting problems with OpenPLi 3.0 #125 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 24 January 2013 - 19:52

I think stepseeking with the number keys is more easy then fast forward and reverse....


The binary seeking worked like this (only an example):
1. start seek
2. press left -> rewind 2 minutes (repeat pressing left as long as you want -> each time rewinding 2 minutes)
3. press right -> move 1 minute forward
4. press right or left and rewind or move forward 30 seconds
and so on
So it worked like a binary search and you could also use different step widths, but it works with only 3 buttons (one for de-/activation)

Edited by betacentauri, 24 January 2013 - 19:54.

Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: Timeshifting problems with OpenPLi 3.0 #126 SpaceRat

  • Senior Member
  • 1,030 posts

+65
Good

Posted 24 January 2013 - 20:01


I think stepseeking with the number keys is more easy then fast forward and reverse....


The binary seeking worked like this (only an example):

Why not simply use normal seeking like people are used to on any other device?
1st box: Vu+ Ultimo 4k 4xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
2nd box: Gigablue Quad 4k 2xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
testing boxes: Vu+ Duo² + AX Quadbox HD2400 + 2x Vu+ Solo² + Octagon SF4008
Sats & Pay-TV: Astra 19.2°E + Hotbird 13°E with Redlight / SCT HD / SES Astra HD- / Sky V14 / 4th empire propaganda TV
Card-Server: Raspberry Pi + IPv6-capable oscam
Router: Linksys WRT1900ACS w/ LEDE + Fritz!Box 7390

Re: Timeshifting problems with OpenPLi 3.0 #127 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 24 January 2013 - 20:13

Well, I like it :rolleyes: And it's quicker.
But we don't have the new timeshift, so it makes no sense to discuss it here very long...

Currently we have other problems. I hope littlesat can fix the problem. Otherwise I'll look at it.
Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: Timeshifting problems with OpenPLi 3.0 #128 SpaceRat

  • Senior Member
  • 1,030 posts

+65
Good

Posted 24 January 2013 - 20:47

Well, I like it :rolleyes: And it's quicker.

How would it be quicker?

But we don't have the new timeshift, so it makes no sense to discuss it here very long...

Indeed. Especially as I doubt it will ever come ... seems to me E2 is based on the work of the same usability lab as Lunix.
See how everybody expects things to work and make it vice versa ... which also explains the huge success of Lunix on the desktop and the more or less missing "woman acceptance factor" of E2-based boxes being the main topic in any E2-box rating on Amazon.

I as an IT guy can handle it, but it's unusable to normal people.
And as there is no benefit from being complicated, so my next sat box will be a box from some vendor WITH concern about usability again.
1st box: Vu+ Ultimo 4k 4xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
2nd box: Gigablue Quad 4k 2xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
testing boxes: Vu+ Duo² + AX Quadbox HD2400 + 2x Vu+ Solo² + Octagon SF4008
Sats & Pay-TV: Astra 19.2°E + Hotbird 13°E with Redlight / SCT HD / SES Astra HD- / Sky V14 / 4th empire propaganda TV
Card-Server: Raspberry Pi + IPv6-capable oscam
Router: Linksys WRT1900ACS w/ LEDE + Fritz!Box 7390

Re: Timeshifting problems with OpenPLi 3.0 #129 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 24 January 2013 - 21:12


Well, I like it :rolleyes: And it's quicker.

How would it be quicker?


To each man his own ;)

Indeed. Especially as I doubt it will ever come ... seems to me E2 is based on the work of the same usability lab as Lunix.
See how everybody expects things to work and make it vice versa ... which also explains the huge success of Lunix on the desktop and the more or less missing "woman acceptance factor" of E2-based boxes being the main topic in any E2-box rating on Amazon.

I as an IT guy can handle it, but it's unusable to normal people.
And as there is no benefit from being complicated, so my next sat box will be a box from some vendor WITH concern about usability again.

I think it's a choose between devil and the deep blue sea. I'm also an IT guy and I haven't much problems with e2 (except timeshift could be better). "Normal" STB have often limitations I don't like (bad or not configurable EPG, no PC channel editor, recordings are crypted,...)
Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: Timeshifting problems with OpenPLi 3.0 #130 littlesat

  • PLi® Core member
  • 56,306 posts

+691
Excellent

Posted 24 January 2013 - 21:40

Then filestep before length of bufffer criterea will not work.... What could be tried is post a backstap go not to livemode... But find a way to go to the begin of the timeshift. Currently i have no idea how to do that with the existing timeshift in place... As in cpp it is forced to go to live....

Who are using fast forward and revert should try stepskip once.... As this is really more easy...

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Timeshifting problems with OpenPLi 3.0 #131 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 24 January 2013 - 21:55

I hope that I have time this weekend to look at it. I have looked at timeshift mechanism some months ago and know that it is not very simple to understand...and testing/debugging is also very difficult because of c++ part and cross compiling...
How do you guys test changes in c++ part?
Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: Timeshifting problems with OpenPLi 3.0 #132 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 24 January 2013 - 22:33

How do you guys test changes in c++ part?


build a new binary with the in-source enigma2.bb:

bitbake -f -c compile -b <path-to-your-e2-sources>/enigma2.bb

and copy it to the box

Re: Timeshifting problems with OpenPLi 3.0 #133 mik9

  • Senior Member
  • 67 posts

0
Neutral

Posted 25 January 2013 - 02:26

Hi, just my two cents:
1. If you want to use playback mode for new timeshift or for some kind of workaround (the proposed two-button solution) instead of live TV, you will get into troubles with all screens/plugins that work only in TV mode (even timeshifted), e.g. basic info about programs, EPG (CoolTVGuide will not work, I know just about Merlin that supports EPG in playback mode) and many more. This would need much work and probably leaving some plugins or creating lots of various hacks to get them working.

2. Permanent Timeshift is not a bad plugin and it could probably be used with not so big changes even if built-in timeshift would be removed. This plugin is independent on enigma timeshift, it only had to deal with the fact that standard timeshift is here and the author tries some hacks to overcome it.

3. Skip buttons are definitely much quicker and more handy than FF and REW. Regarding binary search: I also had it on Topfield DVB-T STB and missed it. So I invented workaround that I built into Permanent Timeshift + Infobar + key definitions. I have following modifications:
If I press button LEFT when in live TV, it skips 15 secs back and starts playing. This is good if you missed something just few seconds ago. Moreover, from this time on I can use any number (skip) buttons if I want. As the replacement of binary search I use this LEFT button (defined in playback/timeshifting mode as skip 15 seconds back) and RIGHT button (defined in playback mode as skip one minute forwards).

So imagine, you need to skip advertising 5 minutes and 50 seconds log. I use 6 times right button (or once number 9 and then RIGHT button if I know the ad will be really long); I see the ad is over and use LEFT button to skip back a bit to see that this is end of the ad. I can do this in less than 5 seconds plus I have to wait another 10 seconds for ad to finish. It is only slightly slower than binary search. I almost never (except for sports) watch TV in real time, just recorded or timeshifted so that I can skip all annoying ads.

Re: Timeshifting problems with OpenPLi 3.0 #134 MiLo

  • PLi® Core member
  • 14,045 posts

+298
Excellent

Posted 25 January 2013 - 12:04

I would also start a recording but in c++ part. The user won't see live tv, he always sees the recording (this avoids the damn switching between live tv and recorded file)


That will make "zapping" horribly slow, it will take about 1..5 seconds before you get a moving picture. Zapping is so fast because the CPU isn't involved.

There isn't much "wrong" with a "switch", it's the implementation that's completely borked.
Real musicians never die - they just decompose

Re: Timeshifting problems with OpenPLi 3.0 #135 MiLo

  • PLi® Core member
  • 14,045 posts

+298
Excellent

Posted 25 January 2013 - 12:06

Afaik ring buffers are a pain in the *ss on any Lunix compatible file-system


Nonsense. The filesystem isn't involved. A "ring buffer" is just a file that gets written and read in "round robin" style.
Real musicians never die - they just decompose

Re: Timeshifting problems with OpenPLi 3.0 #136 SpaceRat

  • Senior Member
  • 1,030 posts

+65
Good

Posted 25 January 2013 - 12:07

3. Skip buttons are definitely much quicker and more handy than FF and REW.

No.

I set the initial FFWD speed to 16x, that means it's just 2 key presses to ffwd at 32x speed. We got commercial breaks of about 8 min length, so if 32x is the proper factor, it takes 15 sec to reach the end. The initial rwnd speed is set to 2, so going back if you ffwd too far int he first place is more precise.

The advantage over skipping: I have a chance to notice that THIS commercial break was just 4 min long. With skip, you would just blindly jump around. This also leads to the possibility to at least notice a movie preview (Usually at the end of the commercial break) and rewind back to it.

And as TV is supposed to be entertaining, even a possible time advantage of skipping in the dimension of µs is by far outweighted by the lack of comfort (That is, the ability to get a glance on what I skipped) in this mode. It's not a race I'm participating in.

There has to be a reason why makers of VHS tape recorders spent time on thinking about how to make seek produce a clear picture and why one left the head right on the tape just to get a picture while seeking if you could have avoided other problems (e.g. tape wear) by lifting them off and just blindy using the counter time to find a point on the tape.
1st box: Vu+ Ultimo 4k 4xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
2nd box: Gigablue Quad 4k 2xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
testing boxes: Vu+ Duo² + AX Quadbox HD2400 + 2x Vu+ Solo² + Octagon SF4008
Sats & Pay-TV: Astra 19.2°E + Hotbird 13°E with Redlight / SCT HD / SES Astra HD- / Sky V14 / 4th empire propaganda TV
Card-Server: Raspberry Pi + IPv6-capable oscam
Router: Linksys WRT1900ACS w/ LEDE + Fritz!Box 7390

Re: Timeshifting problems with OpenPLi 3.0 #137 SpaceRat

  • Senior Member
  • 1,030 posts

+65
Good

Posted 25 January 2013 - 12:12

A proper implementation of permanent timeshift would still wait for some time (LIke 10 to 60s, user selectable to comply with the user's zapping style) before it starts recording to keep zapping fast ...
1st box: Vu+ Ultimo 4k 4xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
2nd box: Gigablue Quad 4k 2xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
testing boxes: Vu+ Duo² + AX Quadbox HD2400 + 2x Vu+ Solo² + Octagon SF4008
Sats & Pay-TV: Astra 19.2°E + Hotbird 13°E with Redlight / SCT HD / SES Astra HD- / Sky V14 / 4th empire propaganda TV
Card-Server: Raspberry Pi + IPv6-capable oscam
Router: Linksys WRT1900ACS w/ LEDE + Fritz!Box 7390

Re: Timeshifting problems with OpenPLi 3.0 #138 littlesat

  • PLi® Core member
  • 56,306 posts

+691
Excellent

Posted 25 January 2013 - 14:03

Timeshift was never implemented in a good an easy structured way... that was also the fact with E1...

in between I think it is already creasy that we have two different timeshift_enable statusses... one is kept in cpp and the other in python.... What if they go off sync....??? Python can only get the active state (that is timeshift enabled but not in livemode).... This are just first observations...

And still stepskip is easy.... with fast forward you really don't make it in a short time... As you guarenteed will get overtimed... And fast reverse back again..

In the Netherlands most commercial breaks are 8 minutes long... Standard wize that is 9, 6, 6, 6, and sometimes you need an additional one 1....

When the commercial break is 4 min instead then... 9, 4 ... (done :D)....

Edited by littlesat, 25 January 2013 - 14:05.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Timeshifting problems with OpenPLi 3.0 #139 SpaceRat

  • Senior Member
  • 1,030 posts

+65
Good

Posted 25 January 2013 - 14:11

In the Netherlands most commercial breaks are 8 minutes long... Standard wize that is 9, 6, 6, 6, and sometimes you need an additional one 1....

When the commercial break is 4 min instead then... 9, 4 ... (done :D)....

You know how long the commercial break is, BEFORE you skipped it?
Congrats.
Now tell me this saturday's lottery numbers ...
1st box: Vu+ Ultimo 4k 4xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
2nd box: Gigablue Quad 4k 2xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
testing boxes: Vu+ Duo² + AX Quadbox HD2400 + 2x Vu+ Solo² + Octagon SF4008
Sats & Pay-TV: Astra 19.2°E + Hotbird 13°E with Redlight / SCT HD / SES Astra HD- / Sky V14 / 4th empire propaganda TV
Card-Server: Raspberry Pi + IPv6-capable oscam
Router: Linksys WRT1900ACS w/ LEDE + Fritz!Box 7390

Re: Timeshifting problems with OpenPLi 3.0 #140 MiLo

  • PLi® Core member
  • 14,045 posts

+298
Excellent

Posted 25 January 2013 - 15:07

A proper implementation of permanent timeshift would still wait for some time (LIke 10 to 60s, user selectable to comply with the user's zapping style) before it starts recording to keep zapping fast ...


Why? As a user, you never want to see the first 10 seconds?

The current "permanent" timeshift plugins have this recording delay as a sort of hack to work around the horrible implementation, but there's absolutely no technical reason either why the recording should be delayed.
Real musicians never die - they just decompose


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users