Audio Streams Limited To 16

manar · Postby **manar** » Fri Dec 21, 2007 12:46 pm

Hello , I just installed DVBDream for the first time and so far I'm liking it .

There is a problem though , maybe it's just me not getting the hang of it but it looks like the audio streams are limited to 16 per channel , adding manually additional pids don't help , you can check with CSAT Mosaique in Astra or any TV Radios that have a lot of audio streams in them ... BTW I have all the streams working very well when using ProgDVB .

Postby **rel** » Sun Dec 23, 2007 1:09 am

it is not a bug, limited to 16. (due to performance requirements)
You can delete the pids that you dont use, and add the ones you need.

manar · Postby **manar** » Sun Dec 23, 2007 3:07 am

Well uuh , thank you for your reply rel , I appreciate

... NOW sorry to say this but what you suggested is no good for me , I'm used to working in my computer all day long and while I don't look at the images , I DO zap between the sounds alot , all of them with no preferences , progdvb does this for me so I'll stick with it ... dvbdream has a lot of qualities over progdvb from the little test I've done but failing to implement a simple feature as enough audio pids is a big drawback .

As for this feature being hard on the performance you know certainly better than me , but I'm skeptical you see , I mean 90% of channels have only 1 audio stream , 5% might have 2 pids in them and another 3% might have between 3 and 16 audio pids ... so you're left with maybe 2% of channels that have over 16 pids , now mind you I don't know any channel that has over 32 audio pids so why don't you just set the maximum pids at that (at least as a workaround for real number of pids) ... I fail to see how this can hit the performance as statistically (even if you have a poor implementation) if ALL channels that are above 16 pids were actually channels that have 32 pids (which is not true) you will end up with 2% more processor units consumed . THAT is hardly a performance hit .

Besides programmatically 16 is a "bastardized" number if you ask me , I mean how do you get your 16 ? that's 4bits of data (2^4=16) , 4bits of data is a nybble and there is no such definition in high languages , so unless you're using ASM or bit shifting to make you calculations which I highly doubt , whether you're using a for loop to get the pids and whether you're storing them in arrays, collections, linked lists, classes or whatever ... YOU HAD to set all these at least as a byte (though many would disregard optimization and set it as an int or uint) and certainly not a nybble which you can't , so again whether you're doing a [for (byte i=0, i<=16,i++)] or a [for (byte i=0, i<=32,i++)] the performance hit is so small , it's negligeable ... unless you're targeting the PC-IBM 286Mhz

... I'm not even going to go in the muddy terrain of 32bits and 64bits registers which is what we all have now as I'm getting very off-topic here .

AGAIN you know better than me the implementation you're using , I'm only stating the obvious non sense of saying that you can't double the processor ticks in 2% of the overall processor use because of performance requirements and my point is that 16 is no magical number , 32 is better suited as it covers almost all channels (without the need to delete anything) and at a very very very very low performance cost ... Other than that : MERRY CHRISTMAS TO YOU

ETA : The reason I went looking for other alternatives to progdvb in the first place is that the new version LIMITS the audio pids unless you buy the pro version

ETA : So meanwhile I'm sticking with an old version of progdvb which works just fine.

Postby **rel** » Sun Dec 23, 2007 5:38 am

you wrote a lot for this, so I think you really need it

actually I was even planning to reduce audio pids to 8 or 4 . Ch list is a huge array and should be reduced more in size. (still a lot of unnecessarry space) i.e. it can hold hold 8000 channel so, you can simply multiply it. for every bit of data stored for a channel

I guess you are already aware of that 16 audio pid is more than enough for 99% of channels. maybe I would like to reduce this to 75% (size and performance efficiency) , because it still won't change anything for 99% of the users.

Sorry, good luck with any app which will work better for you.

czarny · Postby **czarny** » Sun Dec 23, 2007 9:13 am

Ch list is a huge array and should be reduced more in size. (still a lot of unnecessarry space) i.e. it can hold hold 8000 channel so, you can simply multiply it. for every bit of data stored for a channel

It's seems to me that this could be problem with proper data normalization.
Why can't you use some db engine like SQLlite or something?

To me channel list is something like this:
transponders table
names table (maybe packet strings list: "first str\0second str\0")
ECM pids table
Audio pids table

Of course this doesn't mean that these tables have to be in separate files.

Favorites lists only point to channel list items.

Postby **rel** » Sun Dec 23, 2007 11:13 am

Why can't you use some db engine like SQLlite or something?

first versions of DD were using a DB as channel list (3 years ago),
but channel list is just a simple array.

no need for a DB at all. (anything else than native processing of an array would make it slower)

Audio Streams Limited To 16

Who is online