John Andersen wrote:

On Thu, Jan 8, 2009 at 12:26 PM, Marc Chamberlin <marc@marcchamberlin.com> wrote:

...

Thanks again Charles for your reply, I will intersperse my results (comments) within your queries below...

Marc..

Is it just me, or did your Thunderbird just break threading of this topic by not including any Reference Headers?

Well I suspect it was a combination of things... Apparently this group's mail list server will not accept messages that have or are formatted with html content. Even though I have configured Thunderbird to reply to and/or compose messages to this group (via a setting in the address book) with plain text, Thunderbird apparently has decided it will not honor that setting and sends it with html markup instead anywise. (by default) And I, being only a mere human, keep forgetting about that "feature", since most people and groups that I interact with don't mind receiving email with html content... Therefore, for this group, I have to try and remember to reformat email so it is in plain text, and when I don't (as was what happened in this case) eventually this groups server bounces my message or response back to me... Then I have to try and forward the bounced message back to the group, (cuz I am to lazy to recompose it from scratch) first reformatting it in plain text... So that is probably what caused the reference headers to disappear... Someday perhaps... we will finally figure out how to design software so that it all works seamlessly together... Sigh... but as long as these sort of artificial hurdles and barriers are in play, I for one will make mistakes while trying to remember just what the rules are for each and every $!**# application (and mail list servers) I have to work with... double SIGH... Marc...

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Charles Philip Chan wrote:

Marc Chamberlin <marc@marcchamberlin.com> writes:

...

lsmod | grep ivtv ivtv 134496 0 videodev 31236 3 msp3400,tuner,ivtv compat_ioctl32 1104 1 ivtv i2c_algo_bit 5764 1 ivtv cx2341x 11076 1 ivtv v4l2_common 10648 6 msp3400,saa7127,saa7115,tuner,ivtv,cx2341x tveeprom 11248 1 ivtv i2c_core 29972 13 tuner_simple,tda9887,tda8290,msp3400,saa7127,saa7115,tuner,ivtv,i2c_algo_bit,nvidia,v4l2_common,tveeprom,i2c_i801

OK, the drivers are loaded.

...

Yes and that is when I noticed I am having troubles... In the Capture Card Setup section, I am selecting for Card type: MPEG-2 encoder card (PVR-x50, PVR-500) This fails to fill in anything in the field for Video device:

You must not be in the video group:

,---- | hoor@MagnusOpus:~> getfacl /dev/video0 | getfacl: Removing leading '/' from absolute path names | # file: dev/video0 | # owner: root | # group: video | user::rw- | group::rw- | other::--- `----

Put yourself in it, relogin and try again. If that deosn't work, post the output of:

,---- | dmesg | grep ivtv `----

You should see something like this:

,----[ Output of dmesg | grep ivtv ] | ivtv: Start initialization, version 1.4.0 | ivtv0: Initializing card #0 | ivtv0: Autodetected Hauppauge card (cx23416 based) | ivtv 0000:01:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 | ivtv0: Unreasonably low latency timer, setting to 64 (was 32) | ivtv0: Autodetected Hauppauge WinTV PVR-150 | ivtv0: Reopen i2c bus for IR-blaster support | cx25840 1-0044: cx25841-23 found @ 0x88 (ivtv i2c driver #0) | tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0) | wm8775 1-001b: chip found @ 0x36 (ivtv i2c driver #0) | ivtv0: Registered device video1 for encoder MPG (4096 kB) | ivtv0: Registered device video32 for encoder YUV (2048 kB) | ivtv0: Registered device vbi0 for encoder VBI (1024 kB) | ivtv0: Registered device video24 for encoder PCM (320 kB) | ivtv0: Initialized card #0: Hauppauge WinTV PVR-150 | ivtv: End initialization | ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes) | ivtv0: Encoder revision: 0x02060039 `----

Charles

Thanks Charles for your help! Your suggestion to check to see if I was a member of the video group lead me to the answer, but it came as a surprise... On my system I had created a user called mythTV with the intention of having the system autologin mythTV (for wife friendly purposes...) And the user mythTV was a member of the video group so I thought I had that covered... But mythtv-setup must be run as root and it was the root user which was not a member of the video group. So setting root to be a member of the video group fix the problem and mythtv-setup worked fine after that... Before I fade out, I will pass along a couple of thoughts for anyone who cares... For me as a user, the permissions model Linux uses is on the border of incomprehensibility. I would have expected that the user - root would be automatically a member of all groups since Linux makes it appear as if one is suppose to be able to do anything on the system, when logged in as root... And between Samba, file mounts etc, trying to understand permissions gets to be a nightmare at times... That said, a far more serious issue that the mythtv developers should pay heed to, is that this mythtv-setup utility is failing to meet its primary purpose, by failing to GUIDE a user to a solution that works. You gave me a series of steps to follow to discover where the problem was. If the mythtv-setup utility had been developed, with the purpose of guiding a user to a working solution, it too would have follow these same steps that you presented to me, to insure everything in its environment was properly set up. And if it had discovered something amiss, it should have either corrected the problem automatically, if possible, or given the user a clue or help on how to do so... So many programs that I encounter are designed by developers who have a deep knowledge of the system that they work in, and just expect users to grok what is needed to make their program work. If more programmers could understand the difference between a tool that is just a setup/config utility and a tool that is a guide I should think there would be far fewer problems, such as this one, encountered, by end users... The whole presentation of a GUI changes when the developers look towards developing a guide and not just a bunch of form fields and checkboxes to be filled in, often by a clueless user... A guide's primary purpose is to teach a user how to setup and use a tool. A guide will try and ascertain a users skill level and adapt accordingly. A guide will analyze anything that fails, and quickly, interactively provide an answer on how to solve it. A guile will carefully explain to the user what information is needed and help the user to acquire it. A guide will also make sure that the models it uses are understood by a user and such models are based on established precedence. It also will explain what limitations, if any, there are and explain why any "expected" behavior may be restricted... (I don't like throwing rocks at volunteers, but this type of programming/design flaw has become so prevalent that I try to point it out as often as I can.. I am a veteran professional programmer myself, and speak from the school of hard knocks! LOL) Marc... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org