Mailing List Archive: MythTV: Dev

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

Index | Next | Previous | View Threaded

ramon.roca at xcombo

Aug 4, 2003, 5:53 AM

Post #1 of 23 (3235 views)
Permalink

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

I've just missed to attach the file ;-)

----- Original Message -----
From: Ramon Roca
To: Development of mythtv
Sent: Monday, August 04, 2003 2:51 PM
Subject: DVB Big PATCH, Part I - for CVS pls

Umm, seems that someone didn't sleep tonight ;-)

Here is the first patch.. It's zipped because of it's size.
Contains a single diff of everything:

-Updates some catalan translations
-Does all the DB schema changes for new DVB functions (0.10-to-0.11/cvs/mc) (Only thing I'm missing here is to setup a DBSchemaver to some value). Adds a few tables for DVB. The unique change to common tables is at channel, to avoid the 4 table join (channel, cardinputs, capturecards and videosources) to get the type of channel. Defaults to analog, so zero impact to existing users.
-Includes the changes to the code to support that (all DVB related, nothing to do with the rest of mythtv).
-Includes the button to call mythchannels (if present).

Having this will be a lot easier to come after with the rest.
That's been checked and tested with today's CVS. So that's now ready for CVS.

Attachments:

dvb.diff.gz (7.88 KB)

linux.news at bucksch

Aug 4, 2003, 8:36 AM

Post #2 of 23 (3209 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

This looks pretty good. Esp. the extensive comments in the DB scheme are
helpful.

Comments/review:

* enum('Analog','DVB-s','DVB-c','DVB-t','Personal') DEFAULT 'Analog'
NOT NULL;
I'd use uppercase for DVB-S etc., that's the common notation.
Please define "Personal".
* PIDs
o Please use more descriptive names for the PID fields. vpids,
apids, adpids, tpids, ppids, what? Which one is the generic
one for things that we don't support yet?
o As discussed: Why do we need that separation at all, if the
PIDs are usually chosen automatically anyways? I don't
totally oppose the separation, but it makes things a bit
more complicated.
o If you separate them, you must read/use them all in dvbchannels.
* I already rejected that freq conversion in the backend.
* Do you need a primary key for the conditional access table? It
only lists 1:n properties for providers, it doesn't have an
"identity" itself.
* "Deutsch", not "Deustch" ;-)
* You are adding a terrible lot of tables. Do you really need them
all? For example
o Can't you completely include the disecq settings into the
sat table?
o Why do you need the sat table at all? It seems you only need
it for disecq, so why is the current solution (one diseqc
int in the channel_dvb table) not sufficient? Does anybody
have a motor dish which accepts sat positions? Or do you
just want to have a name, for a nicer UI (would be a
reason)? Do you really need to prefill all the values, or
can you fetch it from some imported channel config file?
o What's that channellists? Nothing uses it, and I can't see
how it would be used. Why do you need channellistsmembers
and don't just add a single channellistid field to the
channel table?

ramon.roca at xcombo

Aug 4, 2003, 9:33 AM

Post #3 of 23 (3185 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

> * enum('Analog','DVB-s','DVB-c','DVB-t','Personal') DEFAULT 'Analog'
> NOT NULL;
> I'd use uppercase for DVB-S etc., that's the common notation.
good idea, maybe on next? ;)
> Please define "Personal".
take a look for the definitition at mythchannels/channelstree.cpp. Anwyay
it's reserved still for future use.
> * PIDs
> o Please use more descriptive names for the PID fields. vpids,
> apids, adpids, tpids, ppids, what? Which one is the generic
> one for things that we don't support yet?
vpids= videopids
apids=audio pids
adpids=audio dolby pids
tpids=teletext pids
ppids=pcr pids
We don't support some all of them, but I'm already able to fill them. Nice
to have them already uploaded, harder if we do have to do it later once the
user have already worked on customizing his channels
> o As discussed: Why do we need that separation at all, if the
> PIDs are usually chosen automatically anyways? I don't
> totally oppose the separation, but it makes things a bit
> more complicated.
Yes. Discussed theoretically. Right now we still need at least audio/video.
Sure will be nice to update them, but thats not done. Once we have it done,
maybe we will still need them, i.e. to force an specific audio pid for a
given channel in a distinct criteria than the general preferences... anyway
now Is how it works.
You'll find also a good reason to store them here:
http://www.nokia.com/nokia/0,8764,19329,00.html#16
I do find them more readable in that way instead of something like
"V:1234,567;A:567;AC3"...
> o If you separate them, you must read/use them all in
dvbchannels.
Unless the code gets magic, we will have to read them everywhere we want to
use them =)
> * I already rejected that freq conversion in the backend.
You are feel to reject/improve whatever you want. I'm sure that having coded
more than 7,000 lines of C++/Qt without many prior experience on that,
you'll find things to be improved.
> * Do you need a primary key for the conditional access table? It
> only lists 1:n properties for providers, it doesn't have an
> "identity" itself.
Don't know, I just use to create a a pk to every table I do create ;-) It's
certainly a relationship table, In the meantime it's useful to filet
channels when you are grabbing them from internet by conditional access
system.
> * "Deutsch", not "Deustch" ;-)
Sorry. Given my english, I'm am sure that will be more like this, feel free
to patch them whenever you see one.
> * You are adding a terrible lot of tables. Do you really need them
> all? For example
> o Can't you completely include the disecq settings into the
> sat table?
NO. Channels belongs to satellites, diseqc to antenna configuration. That
would be a BIG mistake. Imagine for instance more than one card in a backend
with different diseqc configurations as a source at each card.
> o Why do you need the sat table at all? It seems you only need
> it for disecq, so why is the current solution (one diseqc
> int in the channel_dvb table) not sufficient? Does anybody
> have a motor dish which accepts sat positions? Or do you
> just want to have a name, for a nicer UI (would be a
> reason)? Do you really need to prefill all the values, or
> can you fetch it from some imported channel config file?
You already mentioned some of the reasons. Every satellite receiver has that
table in somewhat format. In our case, having a relational database is the
best place to have it, better than hardcoded. Note it's basically static but
might have to be updated from time to time when new satellites are launched
or stop working.
> o What's that channellists? Nothing uses it, and I can't see
> how it would be used. Why do you need channellistsmembers
> and don't just add a single channellistid field to the
> channel table?
That's a master/detail. A common way to describe this kind of relationships
in a relational model.
Will be already used within mythchannels to browse channels by groups. All
the satellite receivers that I have seen have that propierty, and again,
since I'm able to load it.... Sure will be nice top extend that to the rest
of mythtv.

Thx ;)

linux.news at bucksch

Aug 4, 2003, 11:07 AM

Post #4 of 23 (3194 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

Ramon Roca wrote:

>
>> * PIDs
>> o Please use more descriptive names for the PID fields. vpids,
>> apids, adpids, tpids, ppids, what? Which one is the generic
>> one for things that we don't support yet?
>>
>
> vpids= videopids
> apids=audio pids
> adpids=audio dolby pids
> tpids=teletext pids
> ppids=pcr pids
>
OK, sounds like good names. So, how about:

* pids_video
* pids_audio
* pids_ac3
* pids_teletext
* pids_subtitles
* pids_pcr (what is PCR?)
* pids_other

? (Sounds a bit silly to me to have so many fields for PIDs, if we don't
really need them anyways for anything technical, but because you insist...)

> 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.

>> o If you separate them, you must read/use them all in
>>
>
> dvbchannels.
> Unless the code gets magic, we will have to read them everywhere we
> want to use them =)
>
>
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.

> NO. Channels belongs to satellites, diseqc to antenna configuration. That
> would be a BIG mistake. Imagine for instance more than one card in a
> backend with different diseqc configurations as a source at each card.
>
OK, that's a reason to separate diseqc from channels.

>> o sat table
>> Do you really need to prefill all the values, or
>> can you fetch it from some imported channel config file?
>>
>
> having a relational database is the best place to have it, better than
> hardcoded.
>
Actually, you do hardcode it in the mc.sql (and currently in cvs.sql and
10-to-11.sql as well). Thus my question about config files.

>> o What's that channellists? Nothing uses it, and I can't see
>> how it would be used. Why do you need channellistsmembers
>> and don't just add a single channellistid field to the
>> channel table?
>>
>
> That's a master/detail. A common way to describe this kind of
> relationships in a relational model.
>
Of course. My question was: Why do you need that detail table? What do
you store there which you can't store elsewhere, e.g. in the channel
table? It seems to me that the channels/channels_dvb table and the
channellistsmembers table have a 1:1 relationship (or at least almost),
in which case you can merge them.

> Will be already used within mythchannels to browse channels by groups.
> since I'm able to load it....
>
>
What is a "group"? We already know providers and channels types. So,
groups are music stations, news, sports, movies etc.? Could you please
add that as comment to the definition?

ramon.roca at xcombo

Aug 4, 2003, 11:56 AM

Post #5 of 23 (3201 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

> * pids_subtitles
I haven't seen them
> * pids_pcr (what is PCR?)
I know that is used in some channels to decode the video. I've it and I do
load it. That's all.
> * 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.

>
> ? (Sounds a bit silly to me to have so many fields for PIDs, if we don't
> really need them anyways for anything technical, but because you
insist...)
>
> > 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?
Programs not broadcast in accordance with the DVB standard have a number of
bits of data, which are "shunted" out of position during digital
transmission. As a result, all you see is a black screen. With manual PID
input, the data can be realigned for problem-free viewing. The required
information is published in the latest issues of satellite program listings
magazines such as TeleSatellite

>
> >> o If you separate them, you must read/use them all in
> >>
> >
> > dvbchannels.
> > Unless the code gets magic, we will have to read them everywhere we
> > want to use them =)
> >
> >
> 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! :-)
If you just mean adding columns in a select list of values that are not
fetched at all, I don't see that really an issue right now.
Note that the pids are still parsed by in the old way, for sure that is
something to do.

> >
> Actually, you do hardcode it in the mc.sql (and currently in cvs.sql and
> 10-to-11.sql as well). Thus my question about config files.
>
By hardcoded what I mean embeded in the code itself as a text, so need to
recompile.
I just thought that all the config files on filesystem where being moved to
the database (which makes a lot of sense to me). So I've just done that.

> >> o What's that channellists? Nothing uses it, and I can't see
> >> how it would be used. Why do you need channellistsmembers
> >> and don't just add a single channellistid field to the
> >> channel table?
> >>
> >
> > That's a master/detail. A common way to describe this kind of
> > relationships in a relational model.
> >
> Of course. My question was: Why do you need that detail table? What do
> you store there which you can't store elsewhere, e.g. in the channel
> table? It seems to me that the channels/channels_dvb table and the
> channellistsmembers table have a 1:1 relationship (or at least almost),
> in which case you can merge them.

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. BBC can
belong to both "English" and "News". Also by deleting a channel from a list,
you don't have to necessarily delete the channel itself...
The only place whete maybe it can be merged it's in the master... That would
be a de-normalization.

>
> > Will be already used within mythchannels to browse channels by groups.
> > since I'm able to load it....
> >
> >
> What is a "group"? We already know providers and channels types. So,
> groups are music stations, news, sports, movies etc.? Could you please
> add that as comment to the definition?

It's the channel lists. The channel lists are groups of channels. Is not
that complicated, just like a playlist it's for music. Give a try and you'll
see. On the other hand everyone who is familiar with a Satellite receiver
will understand that. Almost all of them currently have this. Some of them
call favorite lists or used defined lists, but I do avoid that term to don't
confuse with mythtv favorites, which btw can nicely complement channel
lists.

Look, again, for sure that's an on-development thing and will still be for a
while, that means a lot of things that probably can get better on time, but
if we don't start doing steps forward by consolidating what is done, ....

linux.news at bucksch

Aug 4, 2003, 12:22 PM

Post #6 of 23 (3194 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

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.

ramon.roca at xcombo

Aug 4, 2003, 2:20 PM

Post #7 of 23 (3190 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

> >
> 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.)
>
Oh no, dont get insane. After this patch you will have a clear way to
identify which are the AC3 PID if they are, something that wasn't before, so
now you can write a patch to use them. Still not sure how to map them with
languages, but I'm sure that we'll find also a way for that. I don't mind
also If you patch for storing them in a different format.
Note that I've done a patch for an ongoing development, splited with
mc.sql/cvs.sql/and 0.10-to0.11.sql and after this tested. Now I believe
that's safe, but will not if we start doing changes over it.
I'm quite sure that changes will be easier, and also more people will be
able to contribute, once we have the big one in.

Note: Not sure, I do suspect that the subtitles are coming in the text pids.
Anyway I didn't find such PIDs anywhere, just let me know where I can grab
them.

linux.news at bucksch

Aug 4, 2003, 3:24 PM

Post #8 of 23 (3203 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

Ramon Roca wrote:

>After this patch you will have a clear way to identify which are the AC3 PID if they are, something that wasn't before, so now you can write a patch to use them.
>
AC3 should work without your patch already (of course, I couldn't test
it). Isaac said the frontend supports it, and there's nothing specific
to be done in the backend. No need to change anything or write any code.

>Note: Not sure, I do suspect that the subtitles are coming in the text pids.
>Anyway I didn't find such PIDs anywhere, just let me know where I can grab
>them.
>
I don't know, but here's what I found using Google:

<http://www.dba.org.au/index.asp?sectionID=16>
*"Captions on Digital Television *
The DVB standard provides for captioning using two different systems -
DVB Teletext and DVB Subtitles.
DVB Teletext resembles World System Teletext used in analog broadcasting
in that only text information is carried in the datastream. This makes
it an efficient way to carry captions as it has low bandwidth
requirements. The trade-off, though, is that fonts are limited and
dictated by the display device.
DVB Subtitles are bit-mapped graphics. Their appearance is controlled by
the author in the same way as subtitles on DVDs. While a higher data
overhead is required, the readability of DVB Subtitles is far superior
to DVB Teletext."

<http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=15155>

ijr at po

Aug 4, 2003, 4:31 PM

Post #9 of 23 (3168 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

On Monday 04 August 2003 06:24 pm, Ben Bucksch wrote:
> Ramon Roca wrote:
> >After this patch you will have a clear way to identify which are the AC3
> > PID if they are, something that wasn't before, so now you can write a
> > patch to use them.
>
> AC3 should work without your patch already (of course, I couldn't test
> it). Isaac said the frontend supports it, and there's nothing specific
> to be done in the backend. No need to change anything or write any code.

Alioth:~/mythtv/mythtv# mythtv /mnt/store/Jang_00.tp
connecting to backend server: 192.168.1.101:6543
Input #0, mpegts, from '/mnt/store/Jang_00.tp':
Stream #0.0[0xe81]: Video: mpegvideo, 1920x1088, 29.97 fps, 18030 kb/s
Stream #0.1[0xe84]: Audio: ac3, 48000 Hz, stereo, 384 kb/s
Opening OSS audio device '/dev/dsp'.

So, yup :p

Isaac

ramon.roca at xcombo

Aug 4, 2003, 9:51 PM

Post #10 of 23 (3183 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

I don't know what all of this mean.

After my patch all of this will just behave like before.
"videopid,audiopid". Therefore can be easily forced manually as before if
the user wishes. The only diference is that if they are present depending on
the source the user uses (currently it happens only with vdr channels.conf
files, so since they are customized files, the user might now what he has
there), they are loaded in a way that the user will recognize which type of
PID is each one.

If you mean that to apply first I have to write the logic of choose the
audio pid while playback. Forget about my patch and mythchannels for a
while. At this point simply I don't have the knowledge for that (we need to
identify dynamically the meaning of each pid, i.e. if its original version
or translated, language, etc and provide the preferences setup for doing
that etc.).
Next week I'm on vacation for a week. Maybe it's not a good idea to commit
something just the day before I leave. Well, anyway I don't feel that I can
write that logic within a week... or even if I'm interested in doing so
given the circumstances. All of this doesn't help my enthusiasm, I'm just
trying to contribute, not get involved in neverend discussions or be where
I'm not wellcome.

Also for sure I'm not able to do something like this just alone.

Have a nice day,
Ramon.

----- Original Message -----
From: "Isaac Richards" <ijr [at] po>
To: "Development of mythtv" <mythtv-dev [at] mythtv>
Sent: Tuesday, August 05, 2003 1:31 AM
Subject: Re: [mythtv] Fw: DVB Big PATCH, Part I - for CVS pls

> On Monday 04 August 2003 06:24 pm, Ben Bucksch wrote:
> > Ramon Roca wrote:
> > >After this patch you will have a clear way to identify which are the
AC3
> > > PID if they are, something that wasn't before, so now you can write a
> > > patch to use them.
> >
> > AC3 should work without your patch already (of course, I couldn't test
> > it). Isaac said the frontend supports it, and there's nothing specific
> > to be done in the backend. No need to change anything or write any code.
>
> Alioth:~/mythtv/mythtv# mythtv /mnt/store/Jang_00.tp
> connecting to backend server: 192.168.1.101:6543
> Input #0, mpegts, from '/mnt/store/Jang_00.tp':
> Stream #0.0[0xe81]: Video: mpegvideo, 1920x1088, 29.97 fps, 18030 kb/s
> Stream #0.1[0xe84]: Audio: ac3, 48000 Hz, stereo, 384 kb/s
> Opening OSS audio device '/dev/dsp'.
>
> So, yup :p
>
> Isaac
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>
>

ke-aa at frisurf

Aug 4, 2003, 10:31 PM

Post #11 of 23 (3203 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

Hi,

Seems to me that all this pid talk is getting out of hand. Right now, we
configure a set of pids, which just get parsed and fed to a mpeg stream.
Now, these pids can't contain anything other than audio/video, and can only
contain one of each. So why not just clear up the mess and split pids into
audio/video. I have no idea how you are going to handle all those other
pids, Ben. At least I cannot see this in the current code, because libdvbdev
only handles video/audio. So there is the need for a different kind of
demuxer and recorder part. If we where to store for example subtitles (or
multiple audio/video) in the recording, how would that affect the player?

Also currently there is no way of even identifying which is which of those
'pids', so the split in the database seems clear to me (and btw. the change
in the recorder to support this is tiny).

Kenneth

----- Original Message -----
From: "Ramon Roca" <ramon.roca [at] xcombo>
To: "Development of mythtv" <mythtv-dev [at] mythtv>
Sent: Tuesday, August 05, 2003 6:51 AM
Subject: Re: [mythtv] Fw: DVB Big PATCH, Part I - for CVS pls

> I don't know what all of this mean.
>
> After my patch all of this will just behave like before.
> "videopid,audiopid". Therefore can be easily forced manually as before if
> the user wishes. The only diference is that if they are present depending
on
> the source the user uses (currently it happens only with vdr channels.conf
> files, so since they are customized files, the user might now what he has
> there), they are loaded in a way that the user will recognize which type
of
> PID is each one.
>
> If you mean that to apply first I have to write the logic of choose the
> audio pid while playback. Forget about my patch and mythchannels for a
> while. At this point simply I don't have the knowledge for that (we need
to
> identify dynamically the meaning of each pid, i.e. if its original version
> or translated, language, etc and provide the preferences setup for doing
> that etc.).
> Next week I'm on vacation for a week. Maybe it's not a good idea to commit
> something just the day before I leave. Well, anyway I don't feel that I
can
> write that logic within a week... or even if I'm interested in doing so
> given the circumstances. All of this doesn't help my enthusiasm, I'm just
> trying to contribute, not get involved in neverend discussions or be where
> I'm not wellcome.
>
> Also for sure I'm not able to do something like this just alone.
>
> Have a nice day,
> Ramon.

linux.news at bucksch

Aug 5, 2003, 2:39 AM

Post #12 of 23 (3204 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

Kenneth Aafl�y wrote:

>Now, these pids can't contain anything other than audio/video, and can only contain one of each.
>
Wrong. You can currently (in CVS, without Ramon's patch) record any
number of PIDs of any type.

What Ramon's patch does is to split them up into types of PIDs which
Ramon knows (and he missed at least one type) and to ignore all types
apart from video and stereo audio. It thus breaks AC3 (if the database
is used correctly).

>libdvbdev only handles video/audio.
>
Nope, it handles all types of streams. (Unless I am missing something.)

>If we where to store for example subtitles (or
>multiple audio/video) in the recording, how would that affect the player?
>
If the player supports them, it would allow the user to see the
subtitles (or other audio streams), accessed in a way custom to that
player. Xine, for example, has a button to switch between audio tracks
and another one to switch between subtitles.

>Also currently there is no way of even identifying which is which of those 'pids'
>
Not for the MythTV backend, no, but I don't see where this would be
needed. The player can infer the type of streams/PIDs by the stream itself.

linux.news at bucksch

Aug 5, 2003, 2:42 AM

Post #13 of 23 (3187 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

Ben Bucksch wrote:

> Kenneth Aafl�y wrote:
>
>> If we where to store for example subtitles (or multiple audio/video)
>> in the recording, how would that affect the player?
>
> If the player supports them, it would ...

If the player does not support them, it ignores them. It doesn't hurt,
apart from maybe wasting diskspace.

ramon.roca at xcombo

Aug 5, 2003, 3:18 AM

Post #14 of 23 (3208 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

> What Ramon's patch does is to split them up into types of PIDs which
> Ramon knows (and he missed at least one type) and to ignore all types
> apart from video and stereo audio. It thus breaks AC3 (if the database
> is used correctly).

I didn't touched that, player will still play what is on "video,audio"
pids. Should work just like before. Will even work if there is an user
that still uses the current format and has everything in the video pid.
Now everybody can force the pids to be used by that (note that in fact
apid is the audiopid to be played while changing to that program,
regardless of it's type, the sources I'm using aren't telling me that and
we still don't parse the streams...).

> If the player supports them, it would allow the user to see the
> subtitles (or other audio streams), accessed in a way custom to that
> player. Xine, for example, has a button to switch between audio tracks
> and another one to switch between subtitles.
>

That will be a good idea to start with, a hotkey to switch between
audiopids/textpids etc. Are you going to implement this?

I'm just wondering If we have to reject all the player just because still
doesn't have that keys implemented... will that make sense?

ke-aa at frisurf

Aug 5, 2003, 3:30 AM

Post #15 of 23 (3203 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

Ben Bucksch wrote:
> Kenneth Aafl�y wrote:
> >Now, these pids can't contain anything other than audio/video,
> >and can only contain one of each.
> Wrong. You can currently (in CVS, without Ramon's patch) record any
> number of PIDs of any type.
Yup, record...see that now.

> What Ramon's patch does is to split them up into types of PIDs which
> Ramon knows (and he missed at least one type) and to ignore all types
> apart from video and stereo audio. It thus breaks AC3 (if the database
> is used correctly).
But if his patch is missing a type, you can use other until you submit a
patch for it.

Breaks AC3? Just put the AC3 pid in either audio or other?

> >libdvbdev only handles video/audio.
> Nope, it handles all types of streams. (Unless I am missing something.)
Yes, I can see that now. Misunderstood the code a bit.

> >If we where to store for example subtitles (or
> >multiple audio/video) in the recording, how would that affect the player?
> If the player supports them, it would allow the user to see the
> subtitles (or other audio streams), accessed in a way custom to that
We are talking about MythTV here?

Currently the player does not support multiple audio/video streams, audio
gets mixed together into a mess, and video I think crashes the player.

Seems that we need to make some small changes to the Player, so that it uses
the two first streams (for now).

Kenneth

linux.news at bucksch

Aug 5, 2003, 3:45 AM

Post #16 of 23 (3194 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

Kenneth Aafl�y wrote:

>Breaks AC3? Just put the AC3 pid in either audio or other?
>
(There is no "other pids" field, that's what I proposed and Ramon
rejected that as well.)

Yes, but if there's a field for AC3, a user will put it in there, and it
won't work, because it's not read. The user would have to know about the
"bug" Ramon is about to introduce here and work around it, in a way
which is contrary to Ramon's field separation. And you can fix it in 2
lines of code, thus no need to discuss this further.

ramon.roca at xcombo

Aug 5, 2003, 3:54 AM

Post #17 of 23 (3164 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

>
> Breaks AC3? Just put the AC3 pid in either audio or other?
>
he, he, really at this point, the only thing I'm doing right now is
renaming current "pids" to "vpids" =), and starting to use first apid if
present. SatcoDX does not report if it is AC3 or not, reports the "main
audio pid" so I just load it in the apid, and about channels.conf, as far
as I know, the first is the one that will be used in vdr while zaping...
Anyway for sure that a lot of things have to be done here.

I do really appreciate your contributions in making the player work. BTW
once synched with CVS like you told me on the weekend got really better!
However I still got a hang if fails to lock the signal for whatever
reason. Is that happening to you? Will today's fix solve that?

Thanks,
Ramon

ke-aa at frisurf

Aug 5, 2003, 3:58 AM

Post #18 of 23 (3179 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

Ramon wrote:
> I do really appreciate your contributions in making the player work. BTW
> once synched with CVS like you told me on the weekend got really better!
> However I still got a hang if fails to lock the signal for whatever
> reason. Is that happening to you? Will today's fix solve that?

Unfortunatly not, I've done some thinking about this, but have not (yet) com
up with a sollution.

Isaac:
Do you know an easy way of making the frontend still process keystrokes if
the backend does not feed any data to it (A timeout somewhere)?

Kenneth

ramon.roca at xcombo

Aug 5, 2003, 4:10 AM

Post #19 of 23 (3195 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

> (There is no "other pids" field, that's what I proposed and Ramon
> rejected that as well.)

dont take the things out of context, I don't reject anything. I just don't
have created "other pids" just because I have no info to load to it in
current sources that I have :-)

note that when I had prepared a patch for CVS that was affecting the
database, I've worked and tested for mc/cvs and migration. And tested.
That takes a while. Also part I means that another part is following. If
we change a column name, add another one(I'm not rejecting also this)
there will some code to be rewritten in the Part II, retested and etc... I
just thought that we can do that incrementally.

> "bug" Ramon is about to introduce here and work around it, in a way

I'm learning a lot on this discussions:

"bug"=something to be developed
"2 lines of code"=will support all the things involved with PIDs.

Maybe also a few others, but maybe is better don't have the written ;)

linux.news at bucksch

Aug 5, 2003, 4:21 AM

Post #20 of 23 (3179 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

Ramon Roca wrote:

>After my patch all of this will just behave like before.
>
No, it will ignore most of the fields. But forget it. If your patch goes
in, I'll just fix these 2 lines myself.

>be where I'm not wellcome.
>
You are welcome and your contributions are very much valued. I am
thankful for your MythChannels.

Reviews (like what I just did) are normal, and if a reviewer or
maintainer asks requests from you to change something, then you are
expected to do just that, unless it's unreasonable (=wrong or way too
much work), and supply a new patch after you fixed all his/their
objections (no sense to create 20 patches). Esp. so if he points out why
your code may cause problems for users or other programmers. At least
that's how it works in the Mozilla project and others. You should always
expect that you may have to create another patch before it goes into CVS.

Of course, matters are different, if I comment about dvbchannel/recorder
etc., which is code I wrote, and if I comment about your MythChannels.
In the latter case, it's your code, I may only make a few well-intended
suggestions, and it's completely up to you what you do with them. If you
modify my code, I think I have a right to object to some changes which I
think are wrong. I think you would feel the same, if I went and changed
your MythChannels (in CVS) in a way you dislike.

A bit trivia: I fixed a Mozilla bug, which over 20 people voted for.
Mozilla reviews are mandatory (otherwise I'm not allowed to check in),
and it took 3 months for anybody to review it. He then asked some
questions, but I can't answer them anymore, because it's too long ago, I
forgot it. I have to restart from stratch. So, the patch is still lying
around. Another Mozilla feature I implemented, which 200 people voted
for (thus one of the most requested ones), waits for review since 1-2
months already as well. During a Mozilla review, it's normal that every
10th line is being critizised, for using the "wrong" string conversion
function or whatever. There, your reviewer is like your boss - he asks
you do to something, and you just do it, unless it's unreasonable
(sometimes even then), otherwise you never get your review, because
people are too busy to discuss with you (who supplied the patch). MythTV
is not the Mozilla project, luckily, but just to get things into
perspective.
Also, with my DVB patch, Isaac asked me to change *way* more than I
asked you to change. I redid most of the classes and the database, and
that although I tried to get things sorted out first on the mailing
list, before I started coding. These changes took me maybe 12 hours
coding, and I personally thought that the code was worse afterwards than
my original code, but I had to do it to get it into MythTV. If Isaac
hadn't been willing to some compromises, it would have been even worse.

I'm really trying to be nice and rational, but I don't have time to
endlessly argue about every objection I have, neither can I allow you to
break features that I added earlier, like the ability to record any PID
streams, incl. esp. AC3 and subtitles, and I catched severe bugs in
Kenneth's code, like memory fragmentation (even security holes?) or
endless loops / CPU usage. Almost any maintainer would have rejected
Kenneth's first "cleanup" patch. The current thread started with:

"This looks pretty good. Esp. the extensive comments in the DB scheme
are helpful.

Comments/review:"

then 10 comments to a 1500 line patch. You accepted *none*, not a single
one, of them. So, I don't think I am unreasonable here. I really
appreciate your code, I do think that your patch is good, from what I
saw, apart from these few things I mentioned.

I hope I didn't sound like an asshole here (I feel bad about this post),
but I also invested time into that code and care about it.

I know how it feels for you, how frustrating it can be, I've been in the
same situation, and I am really sorry for it and wanted to avoid that
you and Kenneth feel that way, but I don't know how. It doesn't help
that I currently have no time at all, so I cannot rethink every email 3
times.

>Also for sure I'm not able to do something like this just alone.
>
You are not. I spent a lot of time to write the basic code, Zaheer fixed
important bugs, you and Kenneth are working on it. Maybe somebody else
helps with better player support (e.g. for 16:9) when HDTV takes off.

"Whatever." :-)

Ben

quintesse at palacio-cristal

Aug 5, 2003, 7:02 AM

Post #21 of 23 (3191 views)
Permalink

RE: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

> [mailto:mythtv-dev-bounces [at] mythtv] On Behalf Of Ramon Roca
> Sent: maandag 4 augustus 2003 20:57
> Subject: Re: [mythtv] Fw: DVB Big PATCH, Part I - for CVS pls

<snip>

> > >> o What's that channellists? Nothing uses it,
> and I can't see
> > >> how it would be used. Why do you need
> channellistsmembers
> > >> and don't just add a single channellistid field to the
> > >> channel table?
> > >>
> > >
> > > That's a master/detail. A common way to describe this kind of
> > > relationships in a relational model.
> > >
> > Of course. My question was: Why do you need that detail
> table? What do
> > you store there which you can't store elsewhere, e.g. in the channel
> > table? It seems to me that the channels/channels_dvb table and the
> > channellistsmembers table have a 1:1 relationship (or at
> least almost),
> > in which case you can merge them.
>
> 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. BBC can
> belong to both "English" and "News". Also by deleting a
> channel from a list,
> you don't have to necessarily delete the channel itself...
> The only place whete maybe it can be merged it's in the
> master... That would
> be a de-normalization.

Perfectly logical

>
> >
> > > Will be already used within mythchannels to browse
> channels by groups.
> > > since I'm able to load it....
> > >
> > >
> > What is a "group"? We already know providers and channels types. So,
> > groups are music stations, news, sports, movies etc.? Could
> you please
> > add that as comment to the definition?
>
> It's the channel lists. The channel lists are groups of
> channels. Is not
> that complicated, just like a playlist it's for music. Give a
> try and you'll
> see. On the other hand everyone who is familiar with a
> Satellite receiver
> will understand that. Almost all of them currently have this.
> Some of them
> call favorite lists or used defined lists, but I do avoid
> that term to don't
> confuse with mythtv favorites, which btw can nicely complement channel
> lists.

How about adding a "special" group called [Favorites] or something like
that which can be used to manage the favorites?

Hmmm, no that would be silly, better the other way around: why not
change the EPG so that it knows about groups?
That way it could be made to show only the programs from one particular
group (which you can change of course).
The ? could still be used to add/remove the currently selected channel
to/from the currently selected group.

Would be easy for families as well: John's Favorites, Judy's Favorites,
etc.

But probably this is exactly what you had in mind anyway, isn't it? :-)

Cheers,
-Tako

ke-aa at frisurf

Aug 5, 2003, 8:31 AM

Post #22 of 23 (3191 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

Tako Schotanus wrote:
> How about adding a "special" group called [Favorites] or something like
> that which can be used to manage the favorites?
>
> Hmmm, no that would be silly, better the other way around: why not
> change the EPG so that it knows about groups?
> That way it could be made to show only the programs from one particular
> group (which you can change of course).
> The ? could still be used to add/remove the currently selected channel
> to/from the currently selected group.
>
> Would be easy for families as well: John's Favorites, Judy's Favorites,
> etc.
>
> But probably this is exactly what you had in mind anyway, isn't it? :-)

I too is completely for this, imagine managing a four lnb dish with
1500-2000 channels without some form of grouping. That would be fun :)

Kenneth

ramon.roca at xcombo

Aug 5, 2003, 3:16 PM

Post #23 of 23 (3200 views)
Permalink

Re: Fw: DVB Big PATCH, Part I - for CVS pls [In reply to]

:) I'm very happy to see something that I start to understand.

If we talk clearly and frankly, we can understand, if not, not, and well, I
know that sometimes that could be difficult given my english... ;)

Let me explain what I do think to all of this (trying to be clear)

1.-I'm currently doing that as a hobby/fun
2.-I've no problem in answering all the questions that I can. I try to
answer all of them.
3.-I'm open to any discussion
4.-MythChannels it's all about *new* functionallity. A lot of it comes from
feedback/suggestions that I've just collected from many people, including
you. For sure with it will introduce a lot of bugs, also I know that a lot
of code might be impoved (I had not much experience on c++). Changes outside
of it are testimonial. To sustain that I'm introducing "bugs" or "disabling"
things looks quite unfair to me.
5.- mythchannels is not 1,500 lines, it's +7,000. Unfortunately, it's
already too big to be maintained without control. Changing something like a
column name, affects starting from metadata.cpp to the rest of the code, I
do not reject changes like that in something in development, but don't
expect that I'll do immediately.
6.-To differ in a criteria sometimes might change my criteria, but that's
not mandatory. Also I don't expect this from others.
7.-I don't know how other projects work. I'm only part of the xmltv dev.
team. But for sure that what I'm not looking is for a boss :). I already
have one because I'm getting paid for that, I do not need more. What I'm
looking for is fun with friends in a teamwork and collaborationship. I do
distinguish between comment, review and approval.

Why I'm pointing this? just because I want to be clear. If that doesn't fits
and because I can be wrong I need to know where I am. I don't have that much
spare for throwing it to the trashcan, I've also a family, wife, sons, a job
etc...

Hey, I'm not trying to be a pain on the neck eh? =)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads