WanWizard

No, the =? means "use this if no value is already set".

That is why it is there, to make sure there is a default value. I can only assume it is supposed to be updated on release, but whoever came up with it forgot to document it...

edit: I've added a note about this to the wiki.

Ok. So we need to do something about this, I'll have a look.

The timezone thing is a typical example of a dependency problem, as handling timezones has changed in develop, but it requires a new tzdata setup which the release OE doesn't have.

 

2.4GHz RF Wireless Tastatur

So it is not an IR remote.

So far i saw that if i disable the workaround by setting the boolean "m_remote_control" to false the qwerty keyboard work but the initial issue is back, the one with numerical input text.

 
That is the issue at hand, yes.
  

I wonder if there was any other issue reported at that time, or if there exists any extra infos which can help me to fix this?

No, this is exactly the problem. How to make a standard remote use the SMS-style input, while the qwerty remote use the alphanumeric input?

You still ignore the fact that the VU+ drivers reports the remote has an "A" key, when it hasn't. It has nothing to do with "blame", but with pointing out what the root cause of the problem is. Addressing the root cause is a fix, the rest is a workaround.

If you can fix it and provide a pull request, I'm all for it, I hate workarounds of any sort.

It doesn't help that afaik nobody in the team has one of these remotes, which makes development and testing very difficult.

But what I don't want it to bother users with a question that isn't relevant for 99.99999% of all users. If there is no way to reliably detect the remote, it should then be an override in the keyboard/remote setup menu (autodetect/numeric/alphanumeric), with autodetect being the default.

hmm can't find it on feed, have installed the last 7.2 release from date 04.05.2020 on vu ultimo 4k.

I've backported it to 7.2-release for the build of Sunday night.

Für den Xtrend ET9x00, OpenPLi 4-release.

That is a sentence I hope not to see too often...

Any app is able to emulate a CPU.

For my end-work decades ago I had to write a parser and compiler in Pascal, running on a Motorola 6800, which was fed a Z80 assembler file by the prof to validate it worked.

The main question is would it run the application has it would run on the original hardware?

Pushed a fix to develop, after testing I'll backport it to 7.2-release.

Can you reproduce the issue? If so, I can run a 7.2-release update build for the Duo2, so you can test the fix too.

Hmm... Will have to dive into it again... I've added it to the todo list.

I will not cover here how to create your own build environment for OpenPli as there exists a lot of info on that matter.

For those who need is, there is a small howto: https://wiki.openpli..._for_Developers

Hij heeft een et10k met 2 dvb-c tuners. Dan heeft "Doorgelust" of " Gelijk aan" er weinig mee te maken dacht ik zo.

Oops. Even niet verder gekeken dan de spreekwoordelijke neus...