Jump to content


klosz007

Member Since 21 Jan 2020
Offline Last Active 16 Aug 2021 00:03
-----

Posts I've Made

In Topic: The new OpenPLi Release 8.0 is available for download.

10 August 2021 - 20:28

I suspect so as well bo very hard to guess how exactly this SSD was causing that. Wonders of modern electronics :-)


In Topic: The new OpenPLi Release 8.0 is available for download.

9 August 2021 - 21:46

@ klosz007

You are a little bit too argumentative about it.

Nobody denies your problems.
Nobody here denies that you do not have problems with 7.3.
Some of us have tried to actively recreate this problem.
Without success.
None of us have been able to produce such a log.
There is definitely a big difference between 7.3 and 8 and following versions.
mdev - udev
The current version should work much faster.
It is possible that something has changed here with regard to SSD access behavior.

Precisely because it is an SSD, I would leave such permanent read accesses on the part of picon in the internal memory.
So it is standard too. These standards already have their purpose.
There is absolutely no reason to outsource them.
I can't tell you whether this will fix all of the problems.
We're all just trying to help.

greetings

 

Hi,

 

It's been two months since then. I was too busy to return to this topic + there was Euro 2020, Olympic Games etc.

 

But finally I gave latest stable 8.0 build another chance and no issues at all now ! Exactly same steps but everything works fine, no 'spinner issue' every 2 minutes which I had previously.

 

So one of these two things must have helped:

- either something was fixed in OpenPLi 8.0 in the meantime

or

- replacement of SSD in the tray helped. Inm the meantime (between previous attempt to install 8.0 two months ago and now). I replaced GoodRAM CX200 960GB (which did not create any issues with 7.3) to much more common Crucial MX500 1TB

 

Thanks !


In Topic: The new OpenPLi Release 8.0 is available for download.

11 June 2021 - 19:57

Aaah, so easy, me stupid. Thanks.


In Topic: The new OpenPLi Release 8.0 is available for download.

11 June 2021 - 16:07

On top of that, 99,99% of cable networks customers (in Poland) use decoders provided by their operators (which I hate, used to have one from my operator until they introduced CAM modules, it was dramatically bad). People like me are rarity so very few Enigma users are interested in picon feeds for cable networks, even less in maintaining such feeds. Third party decoders are much more popular between sat networks customers here.

So another slider switch in backup options to enable backup of picons would be more than welcomed by me.


In Topic: The new OpenPLi Release 8.0 is available for download.

11 June 2021 - 15:45

99.99% of the people install picons from the feed, so there is no need to backup them, they will be reinstalled from the feed after a restore.

 

If you have manually created picons, you are most likely knowledgable enough to add them to the backup ;).

 

epg.dat is only used for EPG data persistence, as a backup file. It is written to when you stop Enigma, and it is read again when you start  Enigma, and otherwise not used.

 

Automatic picon feeds, at least here in Poland, are available only for sat networks. Cable customers, like me, are left alone and there's 'good' reason for that - each of the cable networks are inconsistent in their approach, they have different channel/service assignments in different regions of the country (!), even though it's still the same network operator ! So it would be impossible to create one list per operator, unlike with sat operators. Multiple feeds per operator would have to be maintained. Moreover, at least my cable operator is changing layout of the channels very frequently (a month without a change is lost).

So I have to download channel logos and assign them to services manually using dreamboxedit.

 

If I could edit a script or a config file to include additional directories in the config backups, then let me know how. It will simplify things albeit reflashing will require modifying this again.