[mythtv] DVB CI

[Ben Bucksch]

Ramon Roca wrote:

>>No! I didn't suggest that in the DB! In fact, I first had that split in
>>my first patches and then spent several hours to create the current,
>>general solution.
>>    
>>
>I misunderstood that?
>http://www.gossamer-threads.com/perl/mailarc/gforum.cgi?post=73416;search_st
>ring=pid%20bucksch;guest=934749&t=search_engine#73416
>
I don't think I misunderstood anything there. That post suggests to 
mainly use the program tables, not manually entering PIDs. It also 
mentions the idea to use a separate DB table for PIDs, not separate 
fields for audio and video only. I didn't particularily like the idea, 
but don't know a better one.

>All PIDS in a single line just separated by ',' is not safe (teletext,
>radio, ac3, etc...) without adding more codes to parse them. Much safer and cleaner separate them by columns..., also easier to add new pids as long as we support them...
>
That's exactly the problem, that "support". Maybe I want to record AC3, 
although MythTV's player doesn't support it yet, but because the files 
are in MPEG2 format, I can play them with AC3 with another player, if I 
wanted to. Same with subtitles or whatever else is available now or in 
the future. Simply put, I see no need at all for the recorder to have to 
restrict itself to certain types of PIDs, and it limits users to do so, 
so why should we? Also, I think it's silly to have 5 or more fields for 
PIDs: video, audio (maybe in several langages (how many?)), AC3 (maybe 
in several languages?), subtitles (in several langauges (how many?)), 
maybe program table, whatever else is available. If we have to add a 
generic field anyways, and it doesn't matter to the recorder at all what 
the function of the PID is, and the player can figure out the function 
of the PID without extra info, why should we separate the PIDs? It's 
just more code, without a function, apart from maybe offering a slighly 
nicer setup UI. Can't we find a better way to achieve the latter?

>less parsing
>
I think that separating the fields without limiting the functionality is 
*way* more complicated than the current solution.

>>I thought that with Kenneth's meta-info from the stream, the user
>>usually wouldn't need to enter the PIDs at all.
>>    
>>
>If it's already stored, we will have faster channel switch.
>
Yes, but you don't need to separate the DB fields for that.

>I'll keep prognum to keep synched with Kenneth devs.
>
*sigh*! I give up.