64 replies to this topic

[Freon]

Great!

[mimoun01]

TAKE YOU 

[theparasol]

Should be most likely solved tomorrow....

 

Seeing all the recent changes it started with this: "dvbci: clean up some parts, use proper C++ semantics."

Seeing the result it adds and improves zero to nothing.

Even the code itself is harder to read.

 

I vote for: Just revert it all

[athoik]

There is bigger mess over there, some boxes still use input2 in a special way.

Initializing all inputs to the correct tuner, input2 -> C was causing problems to VU+ solo2.

Not initializing the input2 -> C, input3 -> D was causing problem to VU+ duo2.

Some manufactures used a fake ci1 node, in order to use "dm8000" CI handling.

Some manufactures although they have one CI node, their choices announce CI0, CI1 as valid input, we send just CI (dm7025)!

Some manufactures do not have choices! (inputX_choices).

Anyway the dm7025 code should be dropped, is just confusing manufactures, we have non CI boxes with three tuners, where input2 should be used normally.

But that is not going to happen in a night, especially when drivers expect X,Y.


Additionaly DMM has dropped the old dm7025 way for their latest boxes with one CI. Now they use dm8000 (CI >= 1 instead CI > 1).

[Piraya]

Today's update fixes the error
Thank you very much

[Svedba]

[Ageir]

It's working here aswell after todays update!

 

Thanks a lot! Great job!

[Erik Slagter]

Seeing all the recent changes it started with this: "dvbci: clean up some parts, use proper C++ semantics."
Seeing the result it adds and improves zero to nothing.
Even the code itself is harder to read
I vote for: Just revert it all

If the code is harder to read - for you - then that might mean TWO things. I've seen some commits from you and I have hunch...

 

Trust me, the code is better (as in: no longer vulnurable to array overflows -> stack corruption). The "proper C++ semantics" patch had nothing to do with the fact some things broke. The reason it broke is that some manufacturers (!) drivers export a /dev/ci1 device node, but when opened, return an error: "no such device". I call that a bug, or a least not conforming. As the original code uses access() the node is never opened and the bug->error isn't triggered. There is no portable access() equivalent in C++ (STL or BOOST), we'd have to fall back to opening the file for input, which would have been perfectly fine if not these drivers had this bug.

 

So once again we're workarounding driver bugs, it has nothing to do with quality of code.

 

It's a bit of a "spuit 11" remark At least make sure you know what you're talking about first.

[theparasol]

If the code is harder to read - for you - then that might mean TWO things. I've seen some commits from you and I have hunch...

.....

It's a bit of a "spuit 11" remark At least make sure you know what you're talking about first.

 

Why attack my coding skills. It doesnt make your code any better

[Erik Slagter]

No, but it does place the (your) assessment in context. Something with pot and kettle and black .

Edited by Erik Slagter, 18 March 2017 - 12:20.

[MortenB]

I have a VU++ UNO and got the same problem after an update on 15.3.2017.  I fixed it with backupsuite, and since information here indicates that this was fixed I did a online update now, but with same result, the tuner got stuck again.  Have tried all nightly downloads from 20170310 to 20170315 and they only work if selecting NO on restore of setting, if settings is restored, hang.  Build 20170310 and 20170315 was not tested as tuner did not detect it on startup !

 

What happens:

- After online update and tuner boots with startup picture, when wait circle gets small (upper left alive circle) it disappears and comes back about 8 times before total hang.

- File share is working fine

- SSH/Telnet is working

- WEB gui is NOT working

 

Just to inform developers that there still is issues.  My VU++ UNO is unmodified except for a larger HDD about 2 years ago.

My tuner works fine and is happy with last online backup, 20170227, absolutely no urgent need for a fix !

 

Thanks for a great OS for my VU++

Edited by MortenB, 18 March 2017 - 14:36.

[mimisiku]

Hmmmm. The main reason why I left OpenPli. Too many errors and internal bickering who's to blame. Even devs blaming each other... Many will disagree, but OpenSource is not really wholesome for STB's.. Too many fooling around with it, not all with the best experience in the matter. The catchphrase "before upgrading, make full backup first" is beginning to get a bit corney..

OpenPli has become the Windows ME for STB's and personally I don't think that's a plus.

Deep in their heart the devs seem to agree with this. Offering OpenPli 5.0 next master in two variants. One stable (much less frequently updated) and one unstable nighly build.

I would opt for just the stable release as Peter Lindemann intended...

[Taykun345]

This thread is not the place for such comments. OpenPli is in constant development, thats a fact. Solution: do not update often and check forum first

Sent from my HTC 10 using Tapatalk

[Erik Slagter]

I would opt for just the stable release as Peter Lindemann intended...

This reminds me of the LPF, where everybody claimed to have grasped the ideas of Pim Fortuyn (either correctly or not, we'll never know)

 

I also find it interesting that openness is not valued. I guess you'd rather have the half-yearly release, without any information, comments, participation or feedback. That's good to know, I'd gladly move to that scheme.

 

Even more interesting that you keep coming back here to mention you don't OpenPLi. What's the goal? You know what a troll is?

Edited by Erik Slagter, 18 March 2017 - 17:11.

[athoik]

Can you provide the output of commands?

grep -r "" /proc/stb/tsmux

ls -ls /dev/c*

In order to compare? Make sure that comparing with latest version (confirmed that works ok on solo2).

Edited by athoik, 18 March 2017 - 17:41.

[MortenB]

Here is my output of suggested commands: 

root@vuuno:~# grep -r "" /proc/stb/tsmux

/proc/stb/tsmux/input1_choices:CI0 CI1 A B

/proc/stb/tsmux/input0_choices:CI0 CI1 A B

/proc/stb/tsmux/input1:B

/proc/stb/tsmux/input0:A

/proc/stb/tsmux/ci1_tsclk_choices:normal high

/proc/stb/tsmux/ci0_tsclk_choices:normal high

/proc/stb/tsmux/ci1_tsclk:high

/proc/stb/tsmux/ci0_tsclk:high

/proc/stb/tsmux/ci1_input_choices:CI0 A B

/proc/stb/tsmux/ci0_input_choices:CI1 A B

/proc/stb/tsmux/ci1_input:A

/proc/stb/tsmux/ci0_input:A

 

root@vuuno:~# ls -ls /dev/c*

     0 crw-rw----    1 root     root       83,   0 Jan  1  1970 /dev/ci0

     0 crw-rw----    1 root     root       84,   0 Jan  1  1970 /dev/ci1

     0 crw-------    1 root     root        5,   1 Mar 19 15:21 /dev/console

     0 crw-rw----    1 root     root       10,  62 Jan  1  1970 /dev/cpu_dma_latency

root@vuuno:~#

 

Note that this is on FW 20170227, not latest that hangs on boot.

 

Since tuner seems to work on a clean install (not reading my existing settings) I would suggest that the problem is with the script that reads existing setting and convert them into new format for the new FW.

Edited by MortenB, 19 March 2017 - 15:42.

[MortenB]

My suggestion to the developers is to add a new settings for "number days behind latest firmware" you want to be.  If then default = 30 days, then only experienced users that set it = 0 days and could easily handle a failing firmware will get the last compiled firmware.

[WanWizard]

As of OpenPLi 5, we will start releasing stable images that are only updated in a normal release cycle, with the strong suggestion to the users to use these images, unless you know what you are doing.

[MortenB]

I did a new online update now and here is output after reboot (still hanging) :

root@vuuno:~# grep -r "" /proc/stb/tsmux

/proc/stb/tsmux/input1_choices:CI0 CI1 A B

/proc/stb/tsmux/input0_choices:CI0 CI1 A B

/proc/stb/tsmux/input1:B

/proc/stb/tsmux/input0:A

/proc/stb/tsmux/ci1_tsclk_choices:normal high

/proc/stb/tsmux/ci0_tsclk_choices:normal high

/proc/stb/tsmux/ci1_tsclk:normal

/proc/stb/tsmux/ci0_tsclk:normal

/proc/stb/tsmux/ci1_input_choices:CI0 A B

/proc/stb/tsmux/ci0_input_choices:CI1 A B

/proc/stb/tsmux/ci1_input:A

/proc/stb/tsmux/ci0_input:A

 

root@vuuno:~# ls -ls /dev/c*

     0 crw-rw----    1 root     root       83,   0 Jan  1 01:00 /dev/ci0

     0 crw-rw----    1 root     root       84,   0 Jan  1 01:00 /dev/ci1

     0 crw-------    1 root     root        5,   1 Jan  1 01:01 /dev/console

     0 crw-rw----    1 root     root       10,  62 Jan  1 01:00 /dev/cpu_dma_latency

root@vuuno:~#

 

Difference is /proc/stb/tsmux/ci1_tsclk and /proc/stb/tsmux/ci0_tsclk that was "high" and now is "normal"

[athoik]

Not related, the tsclk handling is not touched.

Something else is hanging your box most probably.

Can you start Enigma2 from telnet with extra debug and paste output here?

init 4
ENIGMA_DEBUG_LVL=4 enigma2