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 .
Audio Streams Limited To 16
KWORLD DVBS-100 - DUAL CORE 3.8Ghz - 4Gb RAM - NVIDIA 8500 GT - WINDOWS XP SP2
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.
... 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.
KWORLD DVBS-100 - DUAL CORE 3.8Ghz - 4Gb RAM - NVIDIA 8500 GT - WINDOWS XP SP2
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.
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.
DVB Dream - because I have to dream about having time to code it
It's seems to me that this could be problem with proper data normalization.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
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.
first versions of DD were using a DB as channel list (3 years ago),Why can't you use some db engine like SQLlite or something?
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)DVB Dream - because I have to dream about having time to code it
Who is online
Users browsing this forum: No registered users and 0 guests