Mailing List Archive: MythTV: Dev

mythtv- code architecture

Index | Next | Previous | View Threaded

khalid_eee at yahoo

Jun 12, 2007, 10:12 PM

Post #1 of 10 (2128 views)
Permalink

mythtv- code architecture

Hello,
I am new to the world of mythtv. Could anyone
suggest me where I can get a conprehensive details of
the architecture of MythTV specially its coding.

Khalid Ashraf

--- mythtv-dev-request [at] mythtv wrote:

> Send mythtv-dev mailing list submissions to
> mythtv-dev [at] mythtv
>
> To subscribe or unsubscribe via the World Wide Web,
> visit
>
>
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> or, via email, send a message with subject or body
> 'help' to
> mythtv-dev-request [at] mythtv
>
> You can reach the person managing the list at
> mythtv-dev-owner [at] mythtv
>
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of mythtv-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: [mythtv-commits] Ticket #3394: GPL FLV
> Player for MythWeb
> (Chris Petersen)
> 2. Re: [mythtv-commits] Ticket #3363:
> TranslateKeyPress: prefer
> local action over jump point's (Yeechang Lee)
> 3. Re: IVTV VBI reading (Bruce Markey)
> 4. Re: ffmpeg sync (Bruce Markey)
> 5. Re: adding gnome-power-manager/HAL support to
> mythtv (Ma Begaj)
> 6. Re: Making the state of the frontend dependant
> on the state
> of the TV/monitor? (Ma Begaj)
> 7. Re: Making the state of the frontend dependant
> on the
> (Martin Ebourne)
> 8. Re: adding gnome-power-manager/HAL support to
> mythtv
> (Colin Guthrie)
> 9. Re: [mythtv-commits] Ticket #3394: GPL FLV
> Player for MythWeb
> (Dan Wilga)
> 10. Re: [mythtv-commits] Ticket #3601: Segfault in
> GenericTree::addNode (stanley kamithi)
> 11. Issues updating trac tickets (Steven Ellis)
> 12. Re: Issues updating trac tickets (Anduin
> Withers)
> 13. Re: ffmpeg sync (Janne Grunau)
> 14. Jump points and local overrides (Roo)
>
>
>
----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 11 Jun 2007 09:30:59 -0700
> From: Chris Petersen <lists [at] forevermore>
> Subject: Re: [mythtv] [mythtv-commits] Ticket #3394:
> GPL FLV Player
> for MythWeb
> To: Development of mythtv <mythtv-dev [at] mythtv>
> Message-ID: <466D78C3.4070702 [at] forevermore>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Dan Wilga wrote:
> > Just guessing, but might the problem be be that
> ffmpeg is running
> > very slowly (around 10 fps) and the player isn't
> getting data fast
> > enough?
>
> It could be, yes.
>
> > On a somewhat unrelated topic, should ffmpeg be
> able to handle
> > MPEG4-transcoded files? Mine, at least, can't; it
> errors-out. If this
> > is a fault of my version of ffmpeg, then I think
> the player should
> > give a meaningful error message in this case,
> rather than simply
> > doing nothing. It would prevent a lot of user
> head-scratching.
>
> MythTV, and *only* MythTV (despite some reports to
> the contrary about
> mplayer) is the only program that can correctly
> decipher nuv files
> created by MythTV.
>
> As I have stated many times before, the FLV player
> currently in MythWeb
> SVN is a *proof of concept* player, and would be
> removed/disabled if .21
> were to be released today. It only works with .mpg
> files, and has lots
> of issues (as you and others have reported). Most
> of them can't/won't
> be fixed, especially things related to ffmpeg,
> because ffmpeg isn't part
> of the final plan.
>
> -Chris
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 189 bytes
> Desc: OpenPGP digital signature
> Url :
>
http://mythtv.org/pipermail/mythtv-dev/attachments/20070611/52ea212c/attachment-0001.pgp
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 11 Jun 2007 09:39:28 -0700
> From: Yeechang Lee <ylee [at] pobox>
> Subject: Re: [mythtv] [mythtv-commits] Ticket #3363:
> TranslateKeyPress: prefer local action over jump
> point's
> To: Development of mythtv <mythtv-dev [at] mythtv>
> Message-ID:
> <18029.31424.120161.694057 [at] dobie>
> Content-Type: text/plain; charset=us-ascii
>
> Michael T. Dean <mtdean [at] thirdcontact> says:
> > If anyone else can think of places where a
> jumppoint seems to do the
> > wrong thing in certain contexts, now would be a
> great time to
> > mention it.
>
> I'd still prefer the generic prefer-local-to-global
> patch to a
> specific approach, but since that isn't in the cards
> at the moment
> (Why was that reverted, anyway?), as Chris
> mentioned, the Jumppoints
> for Program Guide and Program Finder should call the
> special
> put-playback-on-pause-and-permit-return-to-playback
> versions of these
> screens when in any playback mode, not just Live TV.
> I've been using
> John Poet's patch
>
(<URL:http://www.gossamer-threads.com/lists/mythtv/users/232375#232375>),
> which does work this way, for so long that I didn't
> realize the
> current approach didn't already act this way.
>
> Other than that, though, I can't think of anything,
> in part because
> the above are the only two such special versions of
> mythfrontend
> screens that currently exist. (I'd love Upcoming
> Recordings and System
> Status to also be able to act in this way, by the
> way.)
>
> Once the jumppoint rewiring is done, shouldn't the
> "M" and "#" keys be
> deleted? I can't think of any situation that one
> would, while watching
> Live TV or a recording, want to be able to bring up
> both the
> non-special and special versions of Program Guide or
> Program Finder,
> so one Jumppoint key for each should suffice in all
> circumstances.
>
> --
> Yeechang Lee <ylee [at] pobox> | +1 650 776 7763 |
> San Francisco CA US
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 11 Jun 2007 10:19:53 -0700
> From: Bruce Markey <bjm [at] lvcm>
> Subject: Re: [mythtv] IVTV VBI reading
> To: Development of mythtv <mythtv-dev [at] mythtv>,
> Hans Verkuil
> <hverkuil [at] xs4all>
> Message-ID: <466D8439.1060809 [at] lvcm>
> Content-Type: text/plain; charset=iso-8859-1;
> format=flowed
>
> Bruce Markey wrote:
> > Hans Verkuil wrote:
> ...
> >>>> but scaling does introduce slight amount of
> >>>> ghosting. Whether this is a driver, firmware or
> hardware bug is
> >>>> something that I need to look into one of these
> days.
> >>> This seems to be a severe issue if only the
> extreme maximum
> >>> resolution is considered to be acceptable. A
> 720x480
=== message truncated ===

____________________________________________________________________________________
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

kormoc at gmail

Jun 12, 2007, 11:43 PM

Post #2 of 10 (2072 views)
Permalink

Re: mythtv- code architecture [In reply to]

On 6/12/07, khalid ashraf <khalid_eee [at] yahoo> wrote:
> Hello,
> I am new to the world of mythtv. Could anyone
> suggest me where I can get a conprehensive details of
> the architecture of MythTV specially its coding.
>
> Khalid Ashraf

Hello Khalid,

Please don't include the full text of the digest email when posting to
the list, it's really bad form.

Also, the most documentation there is for the code is on the wiki, and
it's rather light. The best way is to just dive in and read the peices
you are interested in.

~Rob
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

stuart at tase

Jun 13, 2007, 1:53 AM

Post #3 of 10 (2059 views)
Permalink

Re: mythtv- code architecture [In reply to]

On Wednesday 13 June 2007 07:43:25 Rob Smith wrote:
> On 6/12/07, khalid ashraf <khalid_eee [at] yahoo> wrote:
> > Hello,
> > I am new to the world of mythtv. Could anyone
> > suggest me where I can get a conprehensive details of
> > the architecture of MythTV specially its coding.
<snip>
> Also, the most documentation there is for the code is on the wiki, and
> it's rather light. The best way is to just dive in and read the peices
> you are interested in.

There is some incomplete doxygen documentation at
http://www.cuymedia.net/doxygen-dev-docs/html/

I don't know when it was last re-sync'd. I suspect that Daniel only does it at
each major release.

It might not be a bad idea to mirror this on the mythtv.org website and maybe
include a set for the development version too (updated weekly).
--
Stuart Morgan
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

hendrixski at storsint

Jun 13, 2007, 12:20 PM

Post #4 of 10 (2054 views)
Permalink

Re: mythtv- code architecture [In reply to]

Good documentation lowers the barrier to entry for new developers who
can make solid contributions. Making that documentation easily
accessible wouldn't be a bad idea either.

I've been reading the wiki, perusing the lack of documentation on
doxygen, and reading a book on Qt. I feel like I'm playing Resident
Evil or some other video game where you have to go through a maze
collecting clues and then you have to defeat teh final boss of the
internet before you find what you need to develop something for mythtv.

It's my first attempt at joining an open source project... so I'm gonna
stick it out and learn stuff. I just wanted to say that I sympathize
with Khalid and the long long journey he'll undertake to learn how to
develop stuff for mythtv.

- hendrixski

P.S. I'd love to see a diagram of the architecture as well. Something
to help me understand how to code for it. Just a nice detailed picture
would answer SSSSOOOO many questions for me that I'd probably not have
to pester anyone on the IRC channel for a while.

Stuart Morgan wrote:
>> Also, the most documentation there is for the code is on the wiki, and
>> it's rather light. The best way is to just dive in and read the peices
>> you are interested in.
>
> There is some incomplete doxygen documentation at
> http://www.cuymedia.net/doxygen-dev-docs/html/
>
> I don't know when it was last re-sync'd. I suspect that Daniel only does it at
> each major release.
>
> It might not be a bad idea to mirror this on the mythtv.org website and maybe
> include a set for the development version too (updated weekly).
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

danielk at cuymedia

Jun 13, 2007, 1:52 PM

Post #5 of 10 (2044 views)
Permalink

Re: mythtv- code architecture [In reply to]

On Wed, 2007-06-13 at 15:20 -0400, hendrixski wrote:
> Good documentation lowers the barrier to entry for new developers who
> can make solid contributions. Making that documentation easily
> accessible wouldn't be a bad idea either.

If you write any developer docs, doxygen or any other type,
I'll be glad to commit these to the tree and mirror the
results of 'cd mythtv/docs; make devdocs' at cuymedia.net.

I think writing developer documentation for MythTV is a good
way to learn the code.

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

asherml at gmail

Jun 13, 2007, 2:07 PM

Post #6 of 10 (2039 views)
Permalink

Re: mythtv- code architecture [In reply to]

I've been thinking of making some patches which are just comments for
the code to document what (little) I am able to figure out. How large
would you want the patches? I know generally smaller is better for
actual features, so that review is not too painful. Would the same
thing be true for comments? I suppose I could open a single ticket
and attach many small patches to be reviewed in bite-sized chunks as
time permitted. My fear is that I'll be WRONG about the conclusions
I've come to, so I don't want them checked in without being read over
by someone with actual understanding of the code.

David.

On 6/13/07, Daniel Kristjansson <danielk [at] cuymedia> wrote:
> On Wed, 2007-06-13 at 15:20 -0400, hendrixski wrote:
> > Good documentation lowers the barrier to entry for new developers who
> > can make solid contributions. Making that documentation easily
> > accessible wouldn't be a bad idea either.
>
> If you write any developer docs, doxygen or any other type,
> I'll be glad to commit these to the tree and mirror the
> results of 'cd mythtv/docs; make devdocs' at cuymedia.net.
>
> I think writing developer documentation for MythTV is a good
> way to learn the code.
>
> -- Daniel
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

danielk at cuymedia

Jun 13, 2007, 2:21 PM

Post #7 of 10 (2031 views)
Permalink

Re: mythtv- code architecture [In reply to]

On Wed, 2007-06-13 at 17:07 -0400, David Asher wrote:
> I've been thinking of making some patches which are just comments for
> the code to document what (little) I am able to figure out. How large
> would you want the patches? I know generally smaller is better for
> actual features, so that review is not too painful. Would the same
> thing be true for comments? I suppose I could open a single ticket
> and attach many small patches to be reviewed in bite-sized chunks as
> time permitted. My fear is that I'll be WRONG about the conclusions
> I've come to, so I don't want them checked in without being read over
> by someone with actual understanding of the code.

Don't worry I'll read over them before committing them.

A dozen files at a time per patch is fine if you are
documenting something like the audio subsystem. But if
you are documenting a large file, or a file that changes
frequently, do a patch per file. The goal is to have as
few rejects as possible. With documentation patches this
isn't as essential because a missing piece of documentation
isn't going to break any functionality, but it does mean
some additional work. A tracking ticket is a good idea.

Also, documenting parameters or how a method works is usually
not very important. Documenting what classes do and how
to use them, relationships between classes, and how to use
complicated methods method are important. Basically, if you
don't need the documentation to understand something new to
you, probably no one else does either, if you do, someone
else may also benefit from it.

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mythtv at colin

Jun 14, 2007, 2:26 AM

Post #8 of 10 (2029 views)
Permalink

Re: mythtv- code architecture [In reply to]

Daniel Kristjansson wrote:
> On Wed, 2007-06-13 at 15:20 -0400, hendrixski wrote:
>> Good documentation lowers the barrier to entry for new developers who
>> can make solid contributions. Making that documentation easily
>> accessible wouldn't be a bad idea either.
>
> If you write any developer docs, doxygen or any other type,
> I'll be glad to commit these to the tree and mirror the
> results of 'cd mythtv/docs; make devdocs' at cuymedia.net.
>
> I think writing developer documentation for MythTV is a good
> way to learn the code.

I'm not sure if this is useful or not but on the Digikam list recently I
read the following mail.

Digikam's lead developer Gilles experimented with extending what the
Doxygen docs generated to create better class diagrams etc.

It takse a long time to generate them and I'd imagine doing the same for
Myth would also take >1hr!

May be worth someone playing around.

PS Sorry if the Myth Doxygen stuff already does this, but I've not
looked for a while.

Also, are you aware there is a Trac plugin for Doxygen docs.... may be a
useful addition to add to Myth's site. Works quite nicely if you care to
style it a little (integrated search bit is nice!)

Anyway here is Gilles' mail, hope it's insightful!

Col

> Yesterday, by IRC, Adrien Nicolas Bernhardt, a new developper witch work on a new Image Editor plugin, ask me how to generate the digiKam API documentation.
>
> On the web site the link to KDE web site where is auto-generated the API-DOC is completly out of date :
>
> http://developer.kde.org/documentation/library/3.5-api/extragear-graphics-apidocs/digikam/digikam/html
>
> Today, i have played with Doxygen with is used to generate API documentation. I have set Doxygen to use Graphiz and provide UML diagrams. You can see examples here :
>
> http://digikam3rdparty.free.fr/API_DOC/html/classDigikam_1_1DImg.html
>
> http://digikam3rdparty.free.fr/API_DOC/html/inherits.html
>
> Not all diagrams are generated, because it take a while. Just to generate this documentation, my Double core PIV 1.6 Ghz have take around 90 mns...
>
> The doxygen config file is on "project" sub-folder from svn. Just go to this forder and run doxygen as well... and take a coffee (:=)))
>
> You can set more UML diagrams with Kdevelop witch have a config GUI for Doxygen. Just go to "Project/Project Options" menu entry and select "Doxgen" tag on the left. All advanced diagrams settings are in "Dot" tab from the top of config dialog...
>
> Few days ago, Brian Remedios have posted a messages about UML diagrams generated with a proprietary program. I think than Doxygen + Graphiz are enough here, especially to forget proprietary programs to do it in opensource project (:=)))
>
> I hope than it can help future contributors...
>
> Gilles

--

+------------------------+
| Colin Guthrie |
+------------------------+
| myth(at)colin.guthr.ie |
| http://colin.guthr.ie/ |
+------------------------+
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

hendrixski at storsint

Jun 14, 2007, 7:49 AM

Post #9 of 10 (2035 views)
Permalink

Re: mythtv- code architecture [In reply to]

I'm afraid of making the wrong documentation as well, but if it's going
to be proof-read and edited then I guess it is a pretty good point of
entry into a project. :-)

I'm eager to try this out. I'm on vacation all next week, and won't be
near a computer, so first thing I'll do when I get back is try
submitting a documentation patch. :-)

- Hendrixski
soon-to-be mythtv contributor

David Asher wrote:
> My fear is that I'll be WRONG about the conclusions
> I've come to, so I don't want them checked in without being read over
> by someone with actual understanding of the code.
>
> David.
>
>> I think writing developer documentation for MythTV is a good
>> way to learn the code.
>>
>> -- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

dburr at veritel

Jun 14, 2007, 8:36 AM

Post #10 of 10 (2014 views)
Permalink

Re: mythtv- code architecture [In reply to]

On Thu, 2007-06-14 at 10:49 -0400, hendrixski wrote:
> I'm afraid of making the wrong documentation as well, but if it's going
> to be proof-read and edited then I guess it is a pretty good point of
> entry into a project. :-)
>
> I'm eager to try this out. I'm on vacation all next week, and won't be
> near a computer, so first thing I'll do when I get back is try
> submitting a documentation patch. :-)

I have been working on a "HOWTO write a MythPlugin" document. It's in
very early stages at the moment but perhaps in can be integrated into
your developer documentation.

DB
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads