Jump to content


Photo

Annoying Audio Bug


  • Please log in to reply
21 replies to this topic

#1 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 11 February 2017 - 09:01

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.


Re: Annoying Audio Bug #2 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 11 February 2017 - 09:15

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


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Annoying Audio Bug #3 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 11 February 2017 - 09:55

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.


Re: Annoying Audio Bug #4 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 11 February 2017 - 10:02

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.



Re: Annoying Audio Bug #5 WanWizard

  • PLi® Core member
  • 70,223 posts

+1,798
Excellent

Posted 11 February 2017 - 14:24

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?


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: Annoying Audio Bug #6 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 11 February 2017 - 16:21

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.



Re: Annoying Audio Bug #7 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 11 February 2017 - 19:52

Where is a channel available to see the behaviour?
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Annoying Audio Bug #8 littlesat

  • PLi® Core member
  • 57,063 posts

+698
Excellent

Posted 12 February 2017 - 08:16

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....

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Annoying Audio Bug #9 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 12 February 2017 - 09:03

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.



Re: Annoying Audio Bug #10 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 12 February 2017 - 09:09

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.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Annoying Audio Bug #11 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 12 February 2017 - 10:23

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.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Annoying Audio Bug #12 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 12 February 2017 - 10:33

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.


Re: Annoying Audio Bug #13 Jan Gruuthuse

  • Senior Member
  • 985 posts

+20
Neutral

Posted 12 February 2017 - 10:52

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.


Sf8HD, sf8008, OpenPli 9.0, fixed lnb 28.2E, 19.2E

Re: Annoying Audio Bug #14 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 12 February 2017 - 11:19

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.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Annoying Audio Bug #15 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 12 February 2017 - 11:22

Ah Thank You Athoik

 

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

 

Ian.



Re: Annoying Audio Bug #16 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 12 February 2017 - 13:48

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.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Annoying Audio Bug #17 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 12 February 2017 - 15:48

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.


Re: Annoying Audio Bug #18 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 12 February 2017 - 18:21

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



Re: Annoying Audio Bug #19 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 13 February 2017 - 15:55

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.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Annoying Audio Bug #20 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 13 February 2017 - 15:59

See the screenshot name: 4097_0_0_0_0_0_0_0_0_0.jpg

;)
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916


2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users