[mythtv] Fw: DVB Big PATCH, Part I - for CVS pls

[Ben Bucksch]

Ramon Roca wrote:

>>   * pids_subtitles
>>    
>>
>I haven't seen them
>
They are there (unless I misunderstood something) and are important for 
e.g. scandinavia.

>   * pids_other
>  
>
>What else? Well if something else appear, no problem on adding them. Now I do just create the PIDs that I know that exists. All of them.
>
You never know what comes in the future or what you missed (subtitles, 
for example ;-) ), and it doesn't hurt to add it.

>>>Right now we still need at least audio/video.
>>>
>>I have yet to hear a good reason why, but I give up trying to get one.
>>    
>>
>The page at the nokia site certainly has no sound so you can not hear it,
>but you can always read it:
>Anyway for you conveninece, I'll cut&paste:
>
>16. What is "manual PID input" and how does it work?
>[...] The required information is published in the latest issues of satellite program listings magazines such as TeleSatellite
>
I can read, yes, and I did read that. But that's no reason to *separate* 
the pids, which is what you are proposing. As I understand the text, it 
says (eh, writes) that the automatic selection of the PIDs using the 
program map table (what Kenneth is working on) doesn't always work, and 
that users have to manually enter the PIDs in that case. Fine, that's 
the current state of MythTV, and it works fine. There is no automatic 
selection of PIDs at all, nor are the PID fields separated into video 
and audio, but you can still enter the PIDs manually and it pays just 
fine. Why? Because the recorder doesn't care *at all* what type of 
stream the PID represents, and the player can figure out the type of the 
stream by itself. In other words, currently, we don't separate the PID 
field, and it works. So, why change it? Why do you want to separate the 
existing "pids" field into one for video, one for audio, one for 
teletext etc.? I see no advantage in it, only slightly more code. If we 
have the automatic selection, we can still store all the PIDs we 
selected in that one, generic field that we have right now, no matter, 
if audio, video or whatever.

But, if it's important to you, then change it, the code is less than I 
typed as text here in the last parapraph, but if you do so, then please 
don't limit the current functionality. I.e. allow several audio PIDs 
(for several languages) and allow PIDs of types which you are unaware of.

All clear now?

>>My point. But *if* you add them, you *have to* use them at least in
>>dvbchannels, or you'll fool users who try to use them and wonder why it
>>doesn't work. That's maybe 2 lines of code.
>>    
>>
>Really is that simple to add support for teletext and pcr? please do so! :-)
>
For recording, it is. Not for plalyback. But we can support it during 
record, even if we don't support it during playback. (I am *sure* that I 
wrote that a few days ago already.) Or, Isaac said that the frontend has 
AC3 support, but you don't use the designated AC3 field. So, a user 
would try to use the AC3 PID field and AC3 support would appear 
broken/unimplemented, only because you didn't add this half line of 
code. So, could you please stop arguing and just add these **** 2 lines?

(No, I won't, because the current code works just fine in that regard, 
it's your patch which *breaks* AC3 support, from the user perspective.)

(I am close to going insane here, so no garantees about what I write in 
the next post.)

>That's not necessary have to be 1:1 in this case, Channels lists are user
>defined categories (i.e. "Spanish". "Sports", "Cinema").
>It's nice to have the hability to have same channel on many lists.
>
Ah! OK.