71 replies to this topic

[kota]

No. Just changed my lamedb with the new entries on my bh image which weren't present anyway.

 

Going to try your binary with the openpli 4.0 image in my box. I'll report back ...

 

Cheers

Edited by kota, 20 January 2014 - 23:05.

[Robinson]

Yes, right. Perhaps instead of 10 0a (hex value for 10) is used.

 

Betacentauri, I have just installed 4.0 and here is the result:

 

01b1:005a0000:170c:009e:1:0
EbS+
p:Eutelsat,c:000190,c:030190,c:050001,c:100191,f:40

 

00e9:005a0000:170c:009e:1:0
EbS
p:Eutelsat,c:0000c8,c:0300c8,c:050001,c:1000c9,f:40

 

I will try to do the real test (27.5W) tomorrow.

Thank you.

[betacentauri]

Thanks for the test! Looks good. I hope the final test also works!

[Robinson]

It works!

After a long battle I finally succeeded.

Thank you so much, betacentauri.

Do you think you can now push this modification to be integrated into OpenPLi 4.0 enigma2?

[betacentauri]

Thanks for the test!
I'll try to post the patch in the next days. Then Pli guys have to check and commit it.

[Robinson]

By the way, is it safe for me to just replace the original enigma2 binary with the one you compiled without waiting for the official release?

Thank you once again,  betacentauri , and thank you, doublet, for your invaluable contribution .

[betacentauri]

It should be safe, but if there are other changes the enigma2 binary might be overwritten.

[doublet]

I'm happy to see your progress guys.

Just small note: this E2 change will introduce little incompatibility of lamedb created by OpenPLI. But I think it shouldn't be a big issue. I think even latest dreamboxedit is not able to process DMM way of HE-AAC pid caching in lamedb.

[BBC-Hörer]

Thank you betacentauri and doublet. I highly appreciate your work. The HD-Channels of BBC-Satback now appear with sound on my ET9000.

 

Andreas 

[betacentauri]

Here is the patch.

@Doublet: Yes, this introduce an incompability with dreams lamedb. Problem is that dream source code is closed. So I don't know how they have implemented it. In my opinion it makes no sense to add 2 entries for a pid. One with c:10<type> and the second c:11<pid>. The first 2 digits are already the type. So why add an extra type entry. And with 2 entries you have problems that the order is important. You cannot add the fields in every order. So this don't work for dreams (I guess)

p:BBC,c:0017d5,c:0317d5,c:100004,c:050001,c:1117d6,f:4

But perhaps somebody has an idea why it could make sense. Then please tell us why.

 

@Pli guys: Please take a look at the patch. Feel free to adapt it, if you say that there is a better implementation...

Attached Files

•  0001-Cache-HE-AAC-pid-in-lamedb.patch.txt   7.93KB   89 downloads

[littlesat]

For me this patch looks good... But this is something i prefer pieterg and/or milo should evaluate as well...

[Robinson]

It should be safe, but if there are other changes the enigma2 binary might be overwritten.

 

Maybe I'm doing something wrong but after complete replacement of the original enigma2 file I can only see winter bootlogo and "Booting" on the LCD of my ET9000.

[betacentauri]

What did you exactly do?

Is the file executable?

 

Connect via telnet. Then execute

enigma2

without path. Does it work? If yes, what is the output? If no, what does

ls -la /usr/bin/eni* show. It should look like this (not the sizes and dates but the rights and filenames):

root@et9x00:/usr/bin# ls -la /usr/bin/eni*
-rwxr-xr-x    1 root     root       2948560 Dec 14 03:03 /usr/bin/enigma2
-rwxr-xr-x    1 root     root          1211 Dec 14 03:03 /usr/bin/enigma2.sh

 

 

Edited by betacentauri, 24 January 2014 - 18:32.

[Robinson]

Oh stupid me!

I didn't notice the rights somehow changed back to 644. Sorry, on 755 it works.

[dhwz]

Here is the patch.

@Doublet: Yes, this introduce an incompability with dreams lamedb. Problem is that dream source code is closed. So I don't know how they have implemented it. In my opinion it makes no sense to add 2 entries for a pid. One with c:10<type> and the second c:11<pid>. The first 2 digits are already the type. So why add an extra type entry. And with 2 entries you have problems that the order is important. You cannot add the fields in every order. So this don't work for dreams (I guess)

p:BBC,c:0017d5,c:0317d5,c:100004,c:050001,c:1117d6,f:4

But perhaps somebody has an idea why it could make sense. Then please tell us why.

 

@Pli guys: Please take a look at the patch. Feel free to adapt it, if you say that there is a better implementation...

 

Sorry but this patch is bad, the DMM PID cache is not only caching HE-AAC, thats why both parameters are required. c:10 which is the streamtype e.g. 3 = AAC, 4 = HE-AAC, 7 = AC3+ the c:11 is the pid cache itself. The first 2 digits, I think you are talking about the 10? This is not telling you anything about the streamtype. 

Sorry but you patch is now breaking everthing, and for you information dreamboxEDIT is already handling this properly, and the next major release WILL ONLY support the DMM pidcache format also for direct editing.

 

So please think about changing your patch. 

 

PS: the order of the entries is not relevant.

Edited by dhwz, 25 January 2014 - 18:52.

[dhwz]

Oh and I forgot to say the new pidcache is a replacement for all Audio-PIDs. But for compatibility reasons the MPEG and AC3 PIDs are still written to c:01 and c:04 in lamedb, so compatibilty with other software (dreamboxEDIT, dreamset...) is still present.

But the PIDs can also be cached with the new fields c:10 and c:11, DMMs E2 does accept both.

 

aMPEG = 0, aAC3 = 1, aAAC = 3, aAACHE = 4, aDDP = 7 (I removed the other valid fields as they are currently not used for satellite broadcasts)

Edited by dhwz, 25 January 2014 - 19:01.

[dhwz]

So my request please KEEP compatibility. 

 

        enum { atMPEG, atAC3, atDTS, atAAC, atAACHE, atLPCM, atDTSHD, atDDP };

Edited by dhwz, 25 January 2014 - 19:09.

[littlesat]

Compatible regards closed source -or- open source.... that's the question????

[dhwz]

the relevant files are not closed source 

 

http://git.opendream...enigma2/lib/dvb

Edited by dhwz, 25 January 2014 - 19:37.

[betacentauri]

Hi,

 

thanks for the explanation! That explains some things.

But still the order is relevant! If you say no, then please say which pid has which type in this example: c:111234, c:100004, c:100007, c:100001, c:113456, c:115678

And I mean that in c:xxyyyy the xx is already the type. So why add an extra field for the type? Only because you don't want to add values to the enum?? Where is the big advantage of this solution?