Extended FEL info, TinyPPI

Unsupported/EOL HW/SW Community Projects
1

Would it be possible to add the code for PPI from the other sources in order to get extended PPI output? That would make the well-known skins possible again. If don’t have any objections to that, it could perhaps be ported at some point in the future? Of course, someone who submits a PR for it.

Example:

screenshot00000
screenshot000001920×1080 272 KB

I think it need the second and third commit?
Commits

or this?
Commits

18 Likes
FEL - Amlogic NO support
2

why don’t you submit upstream at Kodi, is the current playing information going to differ from the scanned information?
expand on these (if needed)

anything specific that can’t be loaded at scan time in the same manner?

3

That’s not what’s needed. I’m talking about DialogPlayerProcessInfo. The goal is to get the additional information shown in the image above.

1 Like
4

ugh
that’s also what i’m talking about, the dv metadata in the right upper corner of PPI can be scanned by Kodi, it doesn’t have to come from live player information
(just like the PRs you didn’t read and dismissed anyway)

5

@neqwdtkukwjaanti There’s no point putting this into upstream Kodi because many of these outputs are intended for FEL or Amlogic or can’t be used in standard builds.

1 Like
6

Disagree.
If the metadata is available you could use it in smart playlists for filtering or create an extended information dialog to show this metadata. Even on SDR only setups including linux and windows.
Limits code that CoreELEC has to maintain just for amlogic and can be used universally for windows, linux, libreelec etc.etc.
That’s why I asked “is there any information that is specific to only the Current player information”

7

I have no idea what you’re talking about. What you’re referring to is something completely different from what I want.

As I said, I’m talking about PlayerProcessInfo.

8

Sorry, I thought I was talking to a developer.
Disregard all responses and do whatever you want.

9

If you see me as a developer, that’s fine. I see myself as someone who does this on the side as a hobby.

I hope a developer will take a look at what I’ve described here.

2 Likes
10

I tried to port it now.
I don’t know if that would work…

3 Likes
11

It looks much better than before, but I can’t proceed any further because I lack the necessary knowledge.

What could be causing so many values to show up as 0 or empty?

Also, the VS10 status doesn’t seem to be correct. For example, it shows that the content is being converted from SDR to DV 8.1, even though it is P7 FEL material, the output is wrong here. Live Bitrate and Queue cache seems broken too.

I think there’s still something missing in the code…
I would really appreciate some help.

This is the commit:

Current status:

PXL_20260509_222850078
PXL_20260509_2228500781920×1446 529 KB

Thanks!

1 Like
12

I’ll continue trying today.
It’s turning out to be more difficult for me because I don’t have much experience with the code.

13

There are live metadata that needs to be read from current player info, such as RPUs or L5 Data.

These live data could change while the file is being played.

1 Like
14

I’ll give it up.
That’s beyond my knowledge.

15

Why you don’t ask such people…

And then the people asking themselves why CE don’t want to corporate…

2 Likes
16

to hell with those who say stuff like that, you’re doing great stuff. :trophy:

1 Like
17

@Portisch please dont ever reply to such people. CE is the best and you are a Maestro.

1 Like
18

Thanks for your efforts Jamal. Hope someone will continue…….

3 Likes
19

I don’t want anything to do with people who write things like that. Some people make a huge problem out of something that isn’t really a problem at all.

I’ll never understand it.

20

Thanks for acknowledging the question.

I still think the static data that is consistent per container/stream (the dolby vision labels in the top right corner) could be scanned in and stored in the HdrType (strHdrType) field of the streamdetails table in the database.
At least that would reduce some code needing to be specific.

At the same time if there’s a significant amount of HDR data about a file in the database:

  • it can be used to create more detailed icons in library displays (bottom right corner when highlighting a file).
  • it can be used in information screens
  • possible to create an entirely new detailed hdr information dialog in kodi where that information can be displayed
  • expand variables to playlist filtering so you can have a playlist that lists all DV Profile 7 titles in your library
  • expand to be used in custom library nodes to do the same

jamel just wanted to dismiss the entire thing because they didn’t understand it though
i was even messing around with using a base64 encoded bitfield to be stored in the “text” field strHdrType to pack as much information in as possible since Kodi won’t add fields between major releases