44 replies to this topic

[Rob van der Does]

So waiting for a fix for a plugin that isn't needed and leave it crashing in the mean time? Not my idea of maintaining feeds.

[littlesat]

When you remove it, it is forgotten for ever ....

[Pr2]

Suggestion:

- create a new feed with plugins that are reported to make crash OpenPLi so if people install them anyway they have been warmed and if developper(s) or any other member(s) want to fix them they will know that those plugins get troubles with OpenPLi.

So plugin are not lost forever (people looking for them will know that they exist but doesn't work properly) and this gives a chance to fix them and 6 month later if the plugin is not fixed then it can be removed from this "buggy feed".

[Rob van der Does]

When you remove it, it is forgotten for ever ....

You can leave the plugin in the repos, just not build it.

[littlesat]

But then nobody notifies us that it does not work anymore.... .... (LOL)

By the way... and this is a lot of work... actually the complete timeshift stuff needs a big/huge revision... by making it a really timeshift..

 

e.g. by a defined buffer (e.g. 2 hours)...

it continue recording while you zap... it starts recording the next channel (when you want to keep the current program you need to start an instant recording e.g. via a popup it can remember what was in that timeshift).

 

etc... etc...

 

But nobody of the "Timeshift' bodies tries to make this really great...

 

The complete timeshift stuff made years ago is not what it should be... And a plugin like PTS makes it even worser... (as it works-a-round what was wrong in E2 - because as far I understood DMM was not willing to adapt suggested improvements - that is also the reason why it needs an additional binary - which is wierdness)....

 

Rewrite it from scratch is the best option and as I'm not really using it, and also c++ code needs to be completely revised, it has not my priority....

 

Hopefully someone stands up and is willing to make (permanent)time shift really as it should be... (I'm willing to adapt the UI)....

Edited by littlesat, 12 December 2016 - 09:59.

[Beaving1]

Yes, the core issue is that the core PLi developers don't use this feature and hence don't care for a proper implementation. OpenATV's timeshift integration was just perfect for me and it felt very natural and intuitively, I used it very often. 

 

I want timeshift to record what I'm watching at the moment and automatically start recording the next show after zapping, without having to interact with the recordings menu (and let that be configurable via default action). I wan't to see all timeshift files just like regular recordings in the recordings view, including the current live timeshift file, not just when I press Save on the menu, then switch the channel to be able to see the file (why was this done???). Timeshift recordings should show EPG and also be seperated per broadcast/show. And when you start recording after you've been watching a show for 20 minutes already, it will copy the timeshift data into the new recording as well.

 

There is a timeshift system that already does all of that, in OpenATV, and its open source for 5 years+: https://github.com/o...ts/Timeshift.py

 

Many more people would use timeshift with OpenPLi it if it worked in a good way, but the current implementation is very rudimentary and not user friendly, very burdensome. As a person that tried all images I can say that those images have far more other fundamental problems and timeshift is a necessary sacrifice to have an up2date system like OpenPLi, at least driver and package wise.

 

If this is integrated into PLi, I'd be willing to chime in a 100$ donation for the good cause, either to the organization or to the person responsible for coding it. Right now even, if you promise you will get this done

[littlesat]

Openatv’s timeshift function is made kind of hacky... it adds an extra so file instead of fixing it in e2 where it belongs... because it was hacky we never accepted it. Their hack is based on a timeshift plugin and it was hacky because at that time dmm was also not willing to do it properly... for making the recordings for different shows they also do two recordings at once during the ‘overlap’...(instead of e.g. put a ‘link with marker’ where to start in one recording) Personally I do not use timeshift at all (why is that a real need to record everything you see????) so for me there is no personal need to improve it as it is now...
Also copy (we do this also now) is something you should not need when you change it to instant auto recording plus arrange timeshift user interface when you watch a channel that is currently recorded, and add ‘markers’ that can play a recording at a start of a show...

Edited by littlesat, 19 December 2018 - 07:19.

[betacentauri]

For me PLi timeshift functionality misses only one thing. The timeshift file grows indefinitely. That’s not nice for the guys using an USB stick for timeshift data.
Why do you need to see the timeshift files?
Problem is that everyone wants it in a different way. You can’t make everyone happy.

[arn354]

Openatv’s timeshift function is made kind of hacky... it adds an extra so file

 

 

There is no extra so file.

[Pr2]

 

.. timeshift is a necessary sacrifice to have an up2date system like OpenPLi, at least driver and package wise.

 

 

Sorry but with the new OpenPLi approach based on stable release, you won't have the very latest driver on it, since now the driver used to build a stable image are freezed.

Only the develop image still follow the latest manufacturer driver, but you need to compile it yourself.

 

Moreover this is the strong point of Enigma2 based STB, you have multiple images so you can choose the one that best fit your wishes.

[littlesat]

There is no extra so file.

 

 

Actually I mean this... 

 

https://github.com/o...ateapscfiles.cc

+ why using the "job" thing work-a-round to execute a shell command?

 

But still the timeshift needs a full redesign to let it do what everyone wants.... And this starts by removing a lot code... And the need for a lot of free time.... And it really starts with a good design (just start an instant recording + add in the UI a way to instantly play that instant recording - then nothing really special in cpp for timeshift is needed) + people working together (who also want to use "permanent" timeshift.

Edited by littlesat, 19 December 2018 - 11:08.

[WanWizard]

All of Enigma needs a redesign, it is the result of 15 years of bolting on work without a proper design and architecture. That always ends in unmaintainable spaghetti...

[betacentauri]

I started implementing new timeshift mechanism with instant recording, but I’m not very happy with it.
I think we need more discussion about it.

[littlesat]

What are you not happy about? I can help when we have eg an brench for it...

[betacentauri]

Using an instant recording is on the one hand nice. You can set length and have less code and so on.
But on the other hand you create a new session which eg for iptv streams means you open 2 connections.

If you would ask me how to implement it without knowing e2 code I would say just write the already received data also to a file. And that’s what the current implementation does. So is it really so bad??

[littlesat]

The current timeshift cannot shift streams (as far I know) don’t worry (if the as far I know is correct)

[Beaving1]

The current timeshift cannot shift streams (as far I know) don’t worry (if the as far I know is correct)

 

It works, but its very buggy and if you go back 5 minutes and play back, its very choppy/laggy, even though the recording itself is fine. This test was done last week on my VU Solo SE v2, so maybe it was only bugged because I use the pau extension to allow recordings.

[Erik Slagter]

 

Openatv’s timeshift function is made kind of hacky... it adds an extra so file

 

There is no extra so file.

There is, but it's not related to this. It redirects open() and socket() so they always get the "close-on-exec" flag, it's very ugly, but required because plugins can open files and sockets outside of enigma, so enigma can't control it otherwise.

[Erik Slagter]

 

The current timeshift cannot shift streams (as far I know) don’t worry (if the as far I know is correct)

It works, but its very buggy and if you go back 5 minutes and play back, its very choppy/laggy, even though the recording itself is fine. This test was done last week on my VU Solo SE v2, so maybe it was only bugged because I use the pau extension to allow recordings.

That is probably due to the hardware or drivers, because the timeshift file is just a recording just like any other recording.

[Erik Slagter]

@betacentauri, I see a couple of approaches to doing this properly. I only lack the knowledge of how to implement this properly in enigma.

 

- set up a (additional) recording, I guess that's what we're doing now, not so great

- only setup up a (additional) tap on the demuxer; advantage is that you get descrambling for free, it's already done for the other, original tap or decoding. I think this is the most elegant way, but may be limited by some drivers

- if there is a recording running: use the data written to disk and split it there, if only viewing, we'll still have to add a tap (#2)