braice
commented
5 years ago Hello
It looks like an issue on the client side that does not see the new stream. As you said it is fixed by a manual zap, meaning the new descrambled flux is sent (as MuMuDVB have no information about zaps).
VLC have a code that is more tolerant to bad streams, so it might be that oscam sends something weird during the transition or that the MuMuDVB rewrites are messing up a bit.
I would try to disable the PMT/SDT rewrite and see if it changes anything.
Brice
On Sun, Aug 4, 2019 at 2:58 AM fgt67 notifications@github.com wrote:
I've been having an issue with MumuDVB not descrambling the channel after one of the audio tracks is removed from the broadcast stream. Many channels have dynamic audio tracks (Example: Track 1 , Track 2 <Secondary Language/Narrator/Auxiliary>) where Track 2 is disabled on some programming. Once the change occurs the MPEG-TS will remain encrypted until Track 2 is enabled again in the stream or a manual channel zap. MumuDVB reports no errors or warnings and OSCam only reports this in its log.
2019/07/14 15:18:39 48BD88A5 c (ecm) anonymous (098C@000000/00F5/008B/9F:4429566A302C88550147882ACD859810): found 2019/07/14 15:18:39 48BD88A5 c (ecm) anonymous (098C@000000/01AB/008C/9F:30DBD936411A47EA7577C01BAB3AE562): found 2019/07/14 15:18:46 48BD88A5 c (ecm) anonymous (098C@000000/00F5/008B/9F:B7C449EAAA4955DE2C775CD6496F80B5): found 2019/07/14 15:18:46 48BD88A5 c (ecm) anonymous (098C@000000/01AB/008C/9F:AFB0E26465344A9AC882D73AFA0E0AA8): found 2019/07/14 15:18:49 48BD88A5 c (dvbapi) Demuxer 1 continue decoding of SRVID 008B 2019/07/14 15:18:49 48BD88A5 c (dvbapi) Demuxer 1 found 3 ECMpids and 2 STREAMpids in caPMT 2019/07/14 15:18:53 48BD88A5 c (ecm) anonymous (098C@000000/00F5/008B/9F:81F3D4C4B578D61D17F4B31DDD8CAD46): found 2019/07/14 15:18:53 48BD88A5 c (ecm) anonymous (098C@000000/01AB/008C/9F:18CA45E7CF0F6DA774CB1A7E84F94579): found 2019/07/14 15:19:00 48BD88A5 c (ecm) anonymous (098C@000000/00F5/008B/9F:3FF2E96FCC12FE0CE1C4D1285AB91888): found
My config file for MumuDVB:
freq=11758.50 pol=h srate=27500 delivery_system=DVBS2 card=0 dvr_thread=1 scam_support=1 multicast_ipv4=0 unicast=1 port_http=100 autoconfiguration=full autoconf_sid_list=139
I have extracted part of the MPEG-TS where this track change occurs to help illustrate the problem. At 0:08 the stream will become encrypted and available audio tracks will change from 2 to 1. VLC is the only media player I've found that will play and show this correctly.
audiotrackchange.zip https://github.com/braice/MuMuDVB/files/3464605/audiotrackchange.zip
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/braice/MuMuDVB/issues/251?email_source=notifications&email_token=AACRID6MDKURBAJW6MPT3NTQCZ4ZRA5CNFSM4IJETP42YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HDHE3BA, or mute the thread https://github.com/notifications/unsubscribe-auth/AACRID3V4I2BKZU2QJRAXVLQCZ4ZRANCNFSM4IJETP4Q .
fgt67
I've been having an issue with MumuDVB not descrambling the channel after one of the audio tracks is removed from the broadcast stream. Many channels have dynamic audio tracks (Example: Track 1, Track 2 <Secondary Language/Narrator/Auxiliary>) where Track 2 is disabled on some programming. Once the change occurs the MPEG-TS will remain encrypted until Track 2 is enabled again in the stream or a manual channel zap. MumuDVB reports no errors or warnings and OSCam only reports this in its log.
My config file for MumuDVB:
I have extracted part of the MPEG-TS where this track change occurs to help illustrate the problem. At 0:08 the stream will become encrypted and available audio tracks will change from 2 to 1. VLC is the only media player I've found that will play and show this correctly.
audiotrackchange.zip