21 replies to this topic

[ian1095]

There is a bug in Openpli whereby if a streams Audio is A_AC3 you cannot store the audio selection choice by service.

 

So in effect you cannot store and save a streams language, ie English when the stream offers dual audio. Everything works as it should when the streams audio type is AC3 and the audio selection is then stored and used upon every selection of a given channel.

 

How can I fix this ?

 

Ian.

Edited by ian1095, 11 February 2017 - 09:03.

[Erik Slagter]

Is this when two (or more) AC3 streams are present, or when one is AC3 and the others are MPEG?

[ian1095]

When two (or more)  A_AC3 streams are present.

 

For example, one being German and the other being English audio choices.

 

As stated above, if two (or more)  AC3 streams are present it will store as it should.

 

Ian.

Edited by ian1095, 11 February 2017 - 09:58.

[ian1095]

I'm guessing that A_AC3 is just a made up codec and somewhere in the code there is a replace def to replace A_AC3 with AC3, but if two or more A_AC3 streams are present then this has been overlooked ?

 

Ian.

[WanWizard]

I've never bumped into that problem, but I have defined language preferences for audio, so it will always prefer English over German. Perhaps that might be a workaround for you?

[ian1095]

No Ive tried that too.

 

It does work for everything else, just not when streams have the two  A_AC3 audio choices.

 

It is only a small bug, but its also one thats most annoying, because if the stream drops and the plugins auto reconnect is used to start it automatically again,it restarts using the German or Spanish or whatever audio option is available other than English and I have to manually change the audio again.

 

Ian.

[athoik]

Where is a channel available to see the behaviour?

[littlesat]

I cannot recognize this bug... But sometimes e.g. on sky germany channels audio channels disappear... And then of course it cannot choose the stored one, and it will switch when you zap to the once that are left over....

[ian1095]

Nope its not that either Littlesat, I too have seen what your saying in the past.

 

I will send Athoik a pm containing a link for an M3U which he can convert and add to his bouquets. The server I will send him contains many dual audio channels, all of which are using A_AC3 and he can then see for himself this occuring with every single available dual audio option.

 

Ian.

[athoik]

But there is no lamedb involved when using TS streams to store our selection, so setting always discarded after moving away from that TS stream.

Edited by athoik, 12 February 2017 - 09:10.

[Erik Slagter]

Okay, we need to take back a step. Apparently this service is not broadcast on satellite. So, is it a transport then, or is it "somewhat else"? In the latter case, I can imagine the mechanism doesn't work.

[ian1095]

Yes its a TS

 

However, the audio settings are indeed stored when AC3 is used by particular streams and English is always selected automatically from the TS.

 

So from whats been said, I can only assume this is because previously a matching English AC3 setting has been stored using Sat. ie AC3 English over AC3 German and once stored from Sat its also stored when used by a TS too ?

 

The trouble is though, is that I believe A_AC3 to be a made up codec, therefore not used anywhere on Sat, so impossible to store from Sat. So presently impossible to store at all.

 

This is why I was hoping it would be possible to update the Store Service code to also be able to store from TS as well as from Sat ?

 

After all audio is audio regardless of where it originates ?

 

Ian.

Edited by ian1095, 12 February 2017 - 10:35.

[Jan Gruuthuse]

Perhaps could be a dvb-t2 terrestrial. These transmissions allow/use channel switching within one audio stream going from ac3 2.0 -> ac3 5.1. vlc (player) does not have issues with this. Other software (de/trans) coders could have issues with this.

[athoik]

When we are using Sat/Ter/Cable on our boxes, the lamedb is storing our audio selection.

Once we open the same channel again, Enigma2 reads our selection from lamedb.


When we are using TS Streams on our boxes (usually we do not map the TS stream with a lamedb, we use 1:0:1:0:0:0:0 and there no such entry in lamedb), the lamedb doesn't remeber our selection, is not stored somewhere.

So If there was a fake entry in lamedb for each TS Stream, Enigma2 could store our selection from TS Streams and restore it once we open again the same TS stream.

Edited by athoik, 12 February 2017 - 11:20.

[ian1095]

Ah Thank You Athoik

 

I will investigate my lamedb and see if I can add a fake entry for A_AC3 then.

 

Ian.

[Erik Slagter]

The problem is that preferences are stored as being "stream", this preference is used for all streams. This contrary to real services that have their own entry in the lamedb.

[ian1095]

Thats a shame Eric.

 

It seems that most streams apply the A_ to the real audio codec.

 

As to why they do this I'm unsure, but the fact that they do means that English as an audio option stored via a Sat channel wont work when a stream is selected.

 

If the A_ is not used in the stream,then previous audio selections stored via Sat will indeed work on streams too (this has been tested and proven to be the case by me myself) So I suppose the ideal solution would be to get the image to ignore the A_

 

But I dont know where to begin to look to make it do this in the image code.

 

Ian.

Edited by ian1095, 12 February 2017 - 15:50.

[ian1095]

In case I have not made myself clear as you can say with one picture what it may take a thousand words.

 

As you can see from the attached screenshot, most streams add the A_ and when added stored audio selection even when the image is set to use English wont work.

 

But when streams do not add the A_ stored audio settings to work.

 

Ian.

Attached Files

•  4097_0_0_0_0_0_0_0_0_0.jpg   142.1KB   3 downloads

[Erik Slagter]

The A_AC3 is an internally used symbolic constant. I do not understand how it would show up in this menu.

 

Also, transport stream do not have a concept of "ascii based" codec identifiers (like avi does, with "DIVX" etc.), they can only contain a certain set of codecs that have assigned numbers.

 

I hope someone that is familiar with this code can react.

[athoik]

See the screenshot name: 4097_0_0_0_0_0_0_0_0_0.jpg