Huevos

Startup wizard likely also needs the new rc template.

Something like this:

https://github.com/O...xml#L1380-L1403

There should be. If not it is a skin issue.

It should look like:

https://github.com/O...igma2/pull/4113

That is the missing code.

After adding that patch DimitarCC's skin immediately displays correctly.

Fixed here:

https://github.com/O...igma2/pull/4106

But this series thing looks like someone's personal IPTV code has somehow entered the public image because no real channels are named like that. Why would a channel name contain "Season" and "Episode"? And of course it only works for English, and only in that one format. So, "picon not found" == "another unnecessary lookup".

Are these images public domain? What license?

Ok, fixed with this:

https://github.com/O...ugins/pull/1008

Up until now the only Service Name Picons (SNP) possible were ones named based on an algorithm and only using ASCII numbers and letters.

Now it is possible for picons to have UTF8 SNP filenames. The only requirement is to use lower case. For example:

Channel: БНТ 1

Picon filename: бнт 1.png

Channel: 日本テレビ

Picon filename: 日本テレビ.png

Available in develop build.

Sounds we need a different recipe here… at least I think you understand having renderers and converters dedicated in skins should be avoided. Or maybe put them in a different recipe so the others install that extra package?

As the Renderer goes with the logos it should be packaged with the logos. That way downloading the logos makes the Renderer available. And without the logos the Renderer is not needed so should not be embedded in enigma core code.

Or maybe first letter capitalized and the rest lower case… at least for parsing SVGs or pngs

The capitalization in OE-A is already set. Abu's point was that doesn't matter if we do comparison against lower.

 

Please not! better find a solution (when possible)....Or I'm afraid get rid of svg.... I understand you tried but I know from experience in the past it does not really work for a lot of boxes due to driver/hardware issues. At least I'm convinced... and maybe this is also the reason why the movieplayer icons do not really work. And I agree also blend is a topic here...

 

Can we do some root-cause analysis first, before resorting to drastic measures?

1. what is exactly causing the issues?
2. can we fix it?
3. can we work around it?

Don't start with 3 if 1 and 2 haven't been looked at.

 

1. Blending on HiSi. Nothing to do with svg because that is not used on InfoBar.
2. Well maybe rewrite c++ to take advantage of any hardware acceleration that may be available.
3. Switch "blend" to "on" in HiSi boxes. That will speed things up, but will also not render images correctly.
4. Throw the box in the garbage.

To simplify skin.xml there is now a patch so all colour buttons (graphics and text) can be created by one single widget once in the whole skin. No need for all those silly templates. Fully automatic. And backwards compatible. Is PLi interested?

Pull request https://github.com/O...igma2/pull/3789

Includes fixes for potential BSoD from the UI commit which is already merged.

 

Here's an enigma with Simon's method of signal handing:

 

enigma2_3.9+git20839+854d615-r0.0_vuduo4kse.ipk

 

I see another difference, which is that in VIX kill() is always and directly executed on stop(), while we have a timeout look which sends the signal up to 100 times, and doesn't kill if the loop ends before the signal is acted upon.

was away yesterday. DId now install.

 

So I think the next step really should be debugging this. I'd like to ask anyone who has a frozen enigma, to login to the box, start strace on enigma, and check if any thread is blocking on a read(). If that turns out to be difficult, I could add some debugging code to show this.

will do if this happens again
 

 

opkg install strace

So you need to attach strace to the running process that is frozen. To do that you have to start it using the enigma pid.

strace -p `pidof enigma2`

But nobody seems to know why? So chances are the root cause isn't fixed, just covered up?

So just for your information the problem with Broadcom and efilepush started here: https://github.com/O... 6575c1d5a985d9 which was useful at least in highlighting other problems with the record threading.

Simon confirmed that the recording (and playback) signalling setup didn't work, which leaves the recording thread vulnerable to deadlocks should it ever empty the read buffer. Maybe it worked 5 years ago, but running some tests where he disabled the DMX input into the file used as the source, he observed ::read in eFilePushThreadRecorder::thread() blocking pending some data to read and not responding to SIGUSR1 raised by the main thread.

PR to fix this here: https://github.com/O...nigma2/pull/593

If problems like this take 3 years to get looked at properly it is not surprising people that already fixed them elsewhere don't remember the minutiae.

Intelsat 901 is very old and completely out of fuel. It was put in graveyard orbit in 2019. Later, an MEV was launched and went and retrieved it and brought it back to geostationary. So now the MEV, not the satellite, is responsible for station keeping. And, in another couple of years it is going to be sent back to the graveyard.