116 replies to this topic

[betacentauri]

And in this particular case it might be that french producers set french audiostream to 1 and german producers the german one. I haven't checked it, but it's a quite big chance that it's not deterministic for all channels.

[anudanan]

yes, your´re right. It is only a workaround with no garanty, but today if the wrong audio stream is in the transcodes stream, you can´t change it

[Erik Slagter]

 

Arte has german from my knowlegde as the first stream, on my box it is the first one

 

I think Erik mentioned before that the order in which you see them on the box has little to do with the order in which they are broadcasted?

Plus that there is no guarantee at all in which order they're presented by OWIF (from enigma code). It's converted from a C++ struct into a Python dict and as far as I know, that may shuffle the elements around any time.

 

So if you'd want to do it that way, you'd have to specify PID's, per service. Not really great.

 

I have an idea how to solve this, just be patient.

Edited by Erik Slagter, 11 January 2019 - 19:30.

[anudanan]

Yes I will be patient ;-)

[Erik Slagter]

It just got delayed because of samsamsam removing all of his stuff from github and now we need to worjaround it in four evironments...

[anudanan]

who is samsamsam?

[WanWizard]

The author of iptvplayer and some other tools. Deleted his entire github account and all repo's without any warning.

[anudanan]

ups, that´s not nice and not the mind of opensource policy to work together in an open structure

[Erik Slagter]

The problem is that in such cases not only "their" packages can't be built anymore, instead, the whole build run fails, for all machines, so it creates an emergency that needs to be worked around.

[anudanan]

So you mean since deleting this repros all openpli buildruns fails because iptvplayer is a part of your image and not only a plugin?

[littlesat]

Yep.... someone did simply just plug it off....

Edited by littlesat, 12 January 2019 - 15:15.

[WanWizard]

So you mean since deleting this repros all openpli buildruns fails because iptvplayer is a part of your image and not only a plugin?

 

Even if it is an optional plugin, bitbake stops on build errors, it doesn't matter what the final result of a recipe is. Which is why we are reluncant to include source from "unreliable" sources.

 

In the mean time, three of the four have been fixed by switching repo's, and the forth by adding the source in a tarball in our repo (only a single .c file).

[anudanan]

Much work for the great openpli team, many thanks for doing that

Edited by anudanan, 12 January 2019 - 15:30.

[Erik Slagter]

The reason is that bitbake starts with a stage where it checks which packages need to be build again, e.g. because their source has had updates. When a package has a source that's unreachable, bitbake gives in and stops altogether. Even when you're not using that package at all or only optionally.

Edited by Erik Slagter, 12 January 2019 - 16:01.

[anudanan]

today I´ve found in mpegts.cpp of the streamproxy source the codelines which can identify the language. I´ve made a codechange which preferred now deu language and if it not found it takes the first audio stream. Actually it is not switchable with a parameter but I think I will add a parameter to streamproxy.conf for that later.

 

It works fine for file streaming. 

[anudanan]

The reason why streamproxy use not the first audio track in all situations is that it preffered AC3 audio and use then the last one.

 

My movies from sky has the deu und eng tracks and both are AC3. That is the reason why I get english

 

Now my changed streamproxy use the first german track and preferred deu AC3 and if not found it uses the first audio track which is not "nar"

 

In the next days I will implement a parameter for streamproxy.conf

 

I know that it doesn´t work with the  transcoding_enigma model and only with transcoding broadcom and not for live TV, because for live TV OWIF provides only on audio I think..

 

But that solve the main problem for recorded movies.

[littlesat]

As far I understood we're using the prefered one/cached one from E2

[anudanan]

Now I´ve implemented the language switch into streamproxy process and transcodingsetup and OWIF can do it also

 

All changings from setup or OWIF now writes the changes directly into streamproxy.conf and streamproxy gets a notify to read the new values

 

audiotrack prio ist now

 

 audiostream prio now:

                            1. first AC3 with selected language

                            2. first selected language

                            3. first AC3 if selected language is not found

                            4. first if selected language is not found

 

 

For me it works now perfect for movies stored on the harddisks

 

 

Attached Files

•  language_OWIF.PNG   16.46KB   4 downloads
•  language_setup.PNG   190.51KB   4 downloads

[anudanan]

Here my commit for streamproxy language selection for filetranscoding. I can make a pulluprequest if you want

 

https://github.com/a...ea60b0ca1243e4a

Edited by anudanan, 21 February 2019 - 17:56.

[Pr2]

Hi,

 

Did you set the default transcoding language balue to the one defined in OpenPLi? 

This is nice to be able to select another language but for 99% of the users they will use the same default language as the one defined into there OpenPLi setup, so transcoding should use this value by default.

And the possible language should match the current list provided in OpenPLi.

 

Pr2