41 replies to this topic

[betacentauri]

The problem with the current builtin timeshift is that you cannot limit the size of the timeshift file.
For hdd users this might be no problem. For users who use USB sticks for the timeshift data it's not so good...

[SpaceRat]

These are the options for Timeshift I can adjust from OpenWebif alone in OpenATV:

- Activate automatic timeshift: yes/no
- Automatic timeshift start delay: 2, 3, 4, 5, 10, 20, 30, 60, 120, 300 seconds
- show warning on ending timeshift: yes/no
- Timeshift action on zap: Ask, Save and end, Save and record, Dump
- End Timeshift during recording: yes/no
- use timeshift seekbar during timeshift: yes/no
- Buffer timeshift for: 1 to 999 hours selectable
- Dump timeshift buffer on zap: yes/no

The options asked on timeshift end are:
- End and do not save
- End, save and continue recording
- End and save as recording
- Cancel (Do not end)
I think there are more options if the timeshift buffer already contains complete broadcasts.

That's probably the same in all oe-a images and as far as I remember that was one of the last actual enhancements to appear first in OpenPLi or at least it was backported to OpenPLi quite in time.
So what would the added benefit of a plugin be?


Oh, and last but not least:
Why do I have to tell you?
All I did for this post was looking at what the GUI tells me ... and it tells everybody the same ...

Edited by SpaceRat, 3 November 2014 - 04:14.

[betacentauri]

But you looked into OpenATV E2 GUI. Openatv has included PTS plugin(well, it's builtin and no installable plugin any more). Openpli does not. So in Openpli it's not possible to limit timeshift buffer.

Edited by betacentauri, 3 November 2014 - 08:11.

[SpaceRat]

Hm ...
Well, it's all open source, OpenPLi is free to merge ...

However, there must have been some reason why I switched all boxes from OpenPLi to OpenATV.

Anyways, even on OpenPLi those plugin based timeshift "solutions" aren't the way to go.
They barely worked at all and used ugly workarounds, because there was no TimeShift-API to E2 but only a Recording-API, so it was all done using ugly special recordings, keyboard intercepts and so on.

I remember sound gaps at the end of programmes and other quirks.

[littlesat]

The way pts is implemented is also ugly e.g. The way it requires a saperate binary file. I do not have any issues with pli's timeshift.... I suggest the 10sec zap delay is related to a different issue...

[betacentauri]

I guess the problem with the 10 seconds zap time is that in case of zapping old timeshift data is deleted. And if this is not done in background and the stick is slow it can take several seconds.

[Erik Slagter]

That sounds plausible. On an ext4 filesystem, deletion of large files is no problem, it's finished within a few tenths of a second. But on other file systems, like ext2, ext3 and fat, deletion of large files can take ages.

[Erik Slagter]

Littlesat, do think it's much work to implement the recording time limitation for timeshifting in enigma2? If we have that, I guess there is no longer any reason to use the external plugin?

[littlesat]

As far I know we already have that....
And deleting timeshifts is a background process...
I suggest this is not a general issue...

Edited by littlesat, 3 November 2014 - 15:35.

[Rob van der Does]

That's probably the same in all oe-a images and as far as I remember that was one of the last actual enhancements to appear first in OpenPLi or at least it was backported to OpenPLi quite in time.

Please be aware that there are no OE-A images.

 

As the name suggests all OE-A members do, is maintaining a common OE-environment.

There is no common E2 and all teams build their own images. Some are based on PLi, like XTA, and some are based on ViX, like ATV, although all indeed use the OE-A OE-GiT.

[Meega]

Littlesat, do think it's much work to implement the recording time limitation for timeshifting in enigma2? If we have that, I guess there is no longer any reason to use the external plugin?

 

 

As far I know we already have that....
 

Could you point me in the direction of where that setting is located in the menu?

 

thanks

[littlesat]

It is not within the menu... As far I know this is hardcoded... (default 40 MB or so should be kept free on e.g. a harddisk)...

[Meega]

Ah oke

Does that also applies on usb disks?

[littlesat]

Milo should know better here....

[betacentauri]

If this limit also works for timeshift?? Maybe, because is more or less a normal recording. Didn't test that. But nevertheless timeshift file can grow to several GB. 100-200 and bigger if you don't switch the channel and you have enough space free.
Implementing a limit would be possible, but what should happen when it is reached. Delete old file and start new one. Not nice, because timeshift starts at 0. Using 2 files make the problem with switching between the files when you seek back. And so on. So no simple and nice solution.
I have a solution in mind but no time to implement it ...

[Sjaaky]

One big file with a predetermined size implementing a circular buffer. only drawback is that it would require a copy action if it is saved as recording.
When you zap to a channel which is recorded, it should automatically become part of the timeshiftbuffer

[betacentauri]

Yep. And there are new features in ext4 to truncate files at the front. And to concat 2 files without copying. So no real time consuming copy action is needed.
But unfortunately it's only included in the latest kernel versions (I'm not quite sure whether it's really released. I saw these patches on ext4 dev list).

[littlesat]

When you save a timeshift now the file will be renamed and not deleted. Nothing is copied...

With pts that can "split" on events in some cases it starts two recordings at once... splittimg timeshift recordings on events is the only thing the timeshift build in openpli does not offer. Limiting timeshift on specific times is a limitation which I suggest we should not do...

Edited by littlesat, 4 November 2014 - 07:17.

[SpaceRat]

Please be aware that there are no OE-A images.
As the name suggests all OE-A members do, is maintaining a common OE-environment.
There is no common E2 and all teams build their own images. Some are based on PLi, like XTA, and some are based on ViX, like ATV, although all indeed use the OE-A OE-GiT.

Well, that common "oe-a" env and git makes them "oe-a images" (Note that images is the plural of image ).
Of course I was aware that they are not identical because else there could as well be just one common oe-a image.

But that there are actually images using the oe-a git while still using openpli-e2 is indeed new to me as well as good and interesting to know.

[ims]

 

...Some are based on PLi, like XTA, and some are based on ViX, like ATV

and ViIX taking a lot of things from PLi