Unusual freeze in 5.0.005

  • Thread starter Thread starter Alexwilmac
  • Start date Start date
A

Alexwilmac

It has happened twice in 12 hours and then again after 10 minutes for a 3rd time a very strange fact, never happened before and, unfortunately, no crashlog was produced, simply because the box froze, with the picture still whilst the audio kept working.
Any attempts to zap or recall menus, vane.
I had to switch off or press 10sec power.
As said, no crashlog was produced. It's starting being worrying...
I know that no crashlog... no party, but maybe my post maybe useful in case other users are experiencing same crash.
Only common factor, in a sense, was that in each of the 3 cases, I was registering something or there was timeshift playing. But this is something I do so often that's might be really non relevant.
 
Last edited:
unfortunately to bring the image to the same level of stability and more of the 4.4 it takes years for this I use the 4.4 then one day we will see hopefully as soon as possible
 
It seems strange to me that it takes an hour or more hours for the image / the box froze,
in any case I haven't noticed anything like that on my Ultimo 4k.
 
It happened again...
To provide further details, when this happens, also FTP access becomes unusable.
The Solo4K is fallback server but I can't know if at that moment the client was using its tuners.
 
Telnet works ?
If yes report here the output of the command "free" and "df -h"
 
No: I can't do anything just because telnet (ssh, actually) doesn't work (and, as it is always open, each time it gives me the message "broken pipe".
I have no chance of, at least, performing a simple GUI restart because no "remote" tool is operative (OWIF, telnet, FTP).
 
I know: that's why (also) I called it "unusual": not only because is an issue different from any others I've ever experienced, but also because I can't have any crashlog.
The first time I was watching a recorded file. The other times, live TV. A possibility is that it happens when the fallback client (a Zero4K running OBH 4.4) switches off; but it's not very likely, as it is switched off several times in a day. I'll try to do it myself tomorrow or as soon as possible and I'll report.
But by instinct, after so many years in the IT field, tells me is a local issue.
 
Unfortunately the problem has gone on and on and on, changing also the effect.
And I was able to exclude any fallback influence from the client box.
Sometimes, the box doesn't freeze at all but keeps showing the current channel (or recording) but everything is stuck, from the clock to the menus to every telnet commands.
Now I decided to follow two steps: I flashed by an old 4.4 without using the latest personal configuration from 5.0.
The 2nd step will be changing the internal SSD where the OMB also resides, in case is a faulty SSD.
 
Yes, it's exactly what I fear and what would explain the freeze without crash. I'm just installing a new SSD, although I had already tried a checkdisk connected to a computer.
 
OK: completed the whole transfer to the new SSD... I really hope it was the old one the cause of those bizarre behaviours otherwise I'd be in a complete mess ;)
The fact that, each time I connected to my Mac to check disk integrity (I didn't succeed in doing this by command line) it found inodes errors and, even more, the fact it happened a fatal error to the system (something almost absurd for MacOS!) I hope it means it was really the SSD the problem. :-)
 
Just to let informed about this strange case... but unfortunately, no solution, yes, as I had hoped and I'm getting crazy.
It was not the SSD and it's not a box malfunction (tried OBH 4.4 and, this time, I did not restore personal backup from last 5.5 session).
In this case I used 4.4 for 3 days without any freeze.
So I decided to move the 5.5 to flash and I also installed it from scratch: only reused the fstab and the network files but everything else was added from scratch.
I also thought of... additional "components" (indispensable, unfortunately ;)) and I downloaded a most recent version, in case the old one was not suitable to Py3. Nothing.
It must be this extra... otherwise other people would have reported similar freezes.
 
Might be easier to look at the debug and see if the problem is identified?
You may manually start debug using telnet and have the output shown on your computer. Or you may insert a pen drive into the receiver and have the receiver write the debug information to the pen drive.
 
Can you please remind me the command line to enable debug (as there is no crash and, consequently, no crash log)? Thanks.
 
To see the debug output on your telnet console, enter these two commands:
init 4
enigma2

To make a debug.log file some where enter these two telnet commands:
init 4
enigma2 > /Path-To-File/debug.log 2>&1

For example, this will make a debug.log file in /tmp of receiver's files:
init 4
enigma2 > /tmp/debug.log 2>&1

To stop logging, enter init 3 in telnet console.

And it does not hurt to wait a few seconds after you enter the init 4 command so everything can properly stop.
 
Here it is the debug: the last lines, strangely... concern HDMIcec plugin.
I decided to reinstall 5.0 because I had a suspect about Advanced HDMI CEC plugin. I had tried it before I installed 5.0 (e used the recover from 4.4 personal backup). Then I decided to uninstall it but I had got an error message.
So, suspecting something had gone wrong, I installed from scratch 5.0, without importing my personal backup and without reinstalling Advanced HDMI CEC, only enabling (as always) HDMI CEC.
Maybe it's only a coincidence that the debug ends with it, but...
 

Attachments

And again, after a freeze, the last line in the debug log refers to eHDMICEC... One case might a coincidence; two are becoming very suspect.
I'm going to use exactly the same values and options I had in 4.4. and let's see what happens.
 

Attachments

I tried it, too, because I had again this problem. Unfortunately, it happened again. So I decided to reactivate it and do other tries.
 
You must log in or register to reply here.
Back
Top