475 replies to this topic

[klosz007]

Yes.
I am just amazed at the log.
And before that, something didn't seem ok either.
EPG.dat was probably not intact either.
Maybe it will be destroyed by this behavior?

For me, this is also a problem with EPG.dat in general.
Perhaps it should always be safely deleted with the new flash and also when changing multiboot.
Otherwise there is always the risk of defective epg.dat and consequential errors.

 

I forgot to mention that I deleted epg.dat after reflashing to latest pre-8.1 develop build.

[klosz007]

Long story short, freshly flashed box, either latest 8.0 build with latest updates or latest pre-8.1 develop with lates updates, with no single custom setting restored, just inital wizard executed and epg.dat deleted exhibits this every 2-minute short freeze with accompanying 'spinner' entry in debug log.

Since Euro 2021 is starting tomorrow and I need a healthy STB, I reflashed back to 7.3, restored settings from backup and it all went away....

[Dimitrij]

It looks like there is a big problem.

[WanWizard]

Yes, I've pinged Taapat to check the svg code.

[Huevos]

What is

[ePNG] loadSVG /usr/share/enigma2/skin_default/icons/cutting.svg 30x28 from 20x19

and why does it constantly load the same image? What skin is installed?
 

As far as I know we don't have SVG images in our skins yet, and SVG support in development is still expirimental, 7.3 and 8.0 doesn't have that at all.

That is just debug. The png images don't output the debug. That's all.

 

If it is loading the svg from skin-default that means the current skin has that icon missing.

 

The graphic is being loaded by MovieList.__init__() so that is where you need to start looking for the multiple reloads.

https://github.com/O...vieList.py#L205

Edited by Huevos, 10 June 2021 - 21:42.

[klosz007]

I could see those messages about loading svg file in debug log only in latest develop (pre-8.1) build. Sadly I have not saved entire debug log outside of STB before reflashing back to 7.3 so it's gone for good. I just pasted some lines from it to demontrate those gRC spinner messages every two minutes.

These 'svg' messages were not present in latest 8.0 build though. Yet, there is same problem with this 'spinner' messages every 23 minutes in stable 8.0 (as well as pre-8.1. develop) but not in 7.3.

 

When I'm reflashing from menu, I'm assuming entire "root" filesystem is wiped out, correct ? So the only things that are persistent across reflashes and survive are located on my external drives - SSD (/hdd) in internal slot (where I keep most recent recordings, backups, epg.dat and picons) and USB-attached HDD (archival recordings only).

So my personal feeling is that if I'm performing 'flash image' operation from Menu and choose not to restore from backup after reboot and then go thru initial setup wizard, them I'm in fact restoring tuner to factory defaults ? Only picons (/hdd/picon) and /hdd/epg.dat survive but then I deleted /hdd/epg.dat (via Telnet). And then ran 'software update' + reboot.

Yet 8.0/8.1 are affected by these spinner messages and short freezes. So I wonder what else I could do to make more 'fresh' (except removing internal SSD and disconnecting USB HDD).

 

What is gRC thread responsible for ? Isn't it for remote control ? It looks to me like STB does not freeze, it just stops responding to remote control commands and displays spinner, but A/V is still played back smoothly.

[rantanplan]

From my point of view, picon have no business on the HDD.
They belong in the internal memory.
I can't recreate the problem like that, even from the develop built image doesn't make any such entries.
I don't think it has anything to do with the svg either.
This is more of a coincidence.
The constant data access is surprising.

[WanWizard]

Most of us run develop on all boxes, I update virtually day myself, using my own build. I've never seen this issue either.

 

A quick search in the code shows it is only used in one place, in the movielist, for files that are in the process of being cut. So why it is constantly loaded?

[klosz007]

If I discovered some new bug, I wouldn't be surprised. In my professional IT life, I have luck for to discovering software bugs (in enterprise-class software) that were never spotted before by anyone else.

Possibly some folks have not even noticed those periodic freezes, some other noticed it but thought they were 'normal', some considered it to be annoying but were too lazy to report it and could live with it etc. etc. Nevermind.

 

The issue with epg.dat is closed for me - you explained already that epg.dat format changed from 7.x to 8.x, it was located on SSD in the tray so it survived reflash and 8.0 did not like epg.dat format from 7.3, hence it was displaying these error messages ([eDVBPESReader] ERROR reading PES (fd=50): Value too large for defined data type). Once I deleted epg.dat, these errors were gone for good.

Now I'm only concerned about these peridoc short freezes/spinners every 2 minutes in 8.0 and pre-8.1 which are not present in 7.3. They are sufficiently annoying for me to make me return to 7.3 :-( 

[rantanplan]

in the other debuglog I would conclude that there is permanent timeshift.
Which is not closed and then causes errors by switching to ip stream.
Will this lead to further errors?

From my point of view, hdparm and sdparm only start repeatedly when something is wrong with the hdd

 

and picon better with internal ram.
This receiver has enough memory

Edited by rantanplan, 10 June 2021 - 23:10.

[WanWizard]

If the freezing also happens in 8.0, than the svg file isn't the issue, as 8.0 doesn't support svg files.

 

If the disk isn't 100%, and there is permanent timeshift active to that disk, I can imagine it freezes while waiting for disk timeouts...

[klosz007]

If SSD in the internal tray is an issue then why is this working 100% fine with 7.3 ?

As I said, these periodic spinners every 2 minutes happen also on completely cleanly flashed box. If this was a hardware issue, then I cannot imagine that it would happen at exact intervals and 7.3 be not affected.

 

This SSD is of Polish brand (GoodRAM 960GB, Phison-based) and it is a bit weird to be honest - my SATA to USB 3.0 adapter do not detect it at all. But it was used previously in my wife's Lenovo laptop with zero issues. And ever since I owned Vu+, it has become the "primary" disk for recordings, worked with no issues with 7.x.

External Seagate Backup Plus USB 3.0 5TB HDD - even harder to blame.

I can try to replace SSD with something else (like 2TB QLC, they are becoming cheap) but after Euro 2021. By that time you will have 8.1 finalized and I can give 8.x another try.

 

For the moment I'm testing first-ever DVB-T2 HEVC/4K/HDR/Dolby Atmos channel that Polish public TV (TVP) launched recently to broadcast Euro 2021 so I'm holding back with further experiments for now. Everything works fine with this channel so far on 7.3.

[ccs]

I'd be tempted to switch off picons and see if that had any effect.

[betacentauri]

As I said, these periodic spinners every 2 minutes happen also on completely cleanly flashed box.

 

Without restoring any configuration and plugins?

[rantanplan]

@ 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

[klosz007]

Ah, OK :-) Sorry for that.

 

Maybe I'm a bit too biased by challenges that I have in my professional IT life, where I report software problems that I'm certain I am having and first I have to go through firewall of questions, like:

- have you rebooted your server ?

- does your server meet minimum HW requirements ?

- have you reinstalled your OS/software ?

- have you disabled antivirus ?

- are you certain the errors you are seeing really exist ?

etc. etc.

So basically I feel guilty for opening service case and I have to prove I am not an elephant first to these first level of support folks which is located you know where (big country in middle-far east) :-)

 

There was no such intent here to think about you like about these support guys :-). It's just "professional deviation". I'm just trying to dissolve the issue into basic elements and find out where the fault is and everything tells me it's something in 8.x but I cannot find myself where.

 

 

 

Actually I had picons in /usr/share/enigma2/picon since day one and I moved them to /hdd/picon only recently during these 8.x tests just because I noticed that they were not backed up or restored if located in /usr/share/enigma2/picon (-> improvement request: why not make this directory part of the backup ?). So after I reflashed (which I did 10+ times in recent few days) they were all gone each time. And I had to recreate /usr/share/enigma2/picon directory (it does not exist by default) and copy them back again (using dreamboxedit).

When they are kept in /hdd/picon, enigma2 picks them up too and they survive reflashing so not even a need to backup/restore.

 

Keeping epg.dat in /hdd is the default setting and makes sense to me - it is written frequently (I guess ?) so does good to internal eMMC durability.

[WanWizard]

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.

[klosz007]

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.

[klosz007]

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.

[blzr]

Menu > Setup > Autobackup > Menu button > Select file to backup > browse to /usr/share/ > mark picon directory with yellow button > save with green