Mailing List Archive

On Tue, Jan 9, 2024 at 9:40?AM Adam Skinner <kingmoffa@gmail.com> wrote:

> Hi list,
>
> Another raspberry pi 5 success story.
>
> Rasbian OS latest 64bit with a deb light compiled from source
> (packaging-master).
>
> I'm using the active cooler and no thermal issues.
>

What formats have you tried to playback on the Pi 5? I've only tried MPEG2,
since I recorded from the HDHomerun Tuner.
Also did you notice any artifacts regarding color, like the color depth was
low? Are you running the mythfrontend from the desktop or standalone.
Thanks.


>
> In addition , the HiFi Berry amp2 hat from my pi4 works fine. Little tight
> for space with the active cooler and it just about fits.
>
> Adam
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

Hi,

I’m trying to get an acceptable configuration using a pi5 – so far without success.

I’m currently stuck at mythtv 30 with raspi 3b frontends using openmax output; that has perfect playback for mpeg2 and h.264 up to and including 1920x1080p for recordings from DVB and DVB-S2

The reason I’m stuck at v30 is that openmax output was removed with 31, and I couldn’t get acceptable playback with pi3 or pi4 – decoding and menu speed was ok, but I’d always get tearing, particularly noticeable on horizontal pans.

Now I tried to see what things were like with pi5, tried to get a setup working with raspi os bookworm and the precompiled binaries for MythTV_Light v33 for pi bookworm.

The good news: mostly worked out-of-the box.

The bad news: output quality issues. Output is to a 4k capable display, but resolution was set to 1920p50 – This matches pal/Europe recording frame rate.

When running on wayland

* Both the menus and the actual display look like it’s using reduced color depth; there’s very visible banding of gradients.
* Frontend wouldn’t hide the mouse cursor.
* Couldn’t get screen blanking to work when frontend was started; worked fine without frontend but screen no longer blanks as soon as frontend is active (even it it’s just sitting in the menu)
* Except for the color depth issue playback is fine, no tearing issues whatsoever

When running on X11 (same system, same configuration – just changed from Wayland to X11 using raspi-config)

* Banding issue is gone, Menu and images look much better
* Screen blanking works as expected
* Tearing issues are back

Playback profile is v4l2 Codecs, but also tried opengl standard with same results

Just for the record: playing back the same video file used for frontend tests using vlc works flawlessly both on wayland and on X11 and has neither the banding nor the tearing issue on either system. (but does use about twice as much cpu)

So, if anyone has any version of mythtv > 30 running on a pi frontend without tearing and without banding I’d really like to know what your configuration is.

Thanks,
Martin Bene,
no.disclaimer

On 2024-02-01 13:56, Martin Bene wrote:
> So, if anyone has any version of mythtv > 30 running on a pi frontend without tearing and without banding I’d really like to know what your configuration is.

I have tested MythTV 31 on a Raspberry Pi 4 with mythfrontend and did
not experience the above issues. However I did experience some judder
when playing back 1080i OTA content. Hence I use options other than the
RPi4 Mythfrontend for viewing recordings.

I wrote a tutorial about it if it is of any help to you.

Build a PVR using Raspberry Pi 4, MythTV, & HDHomeRun
https://gedakc.users.sourceforge.net/display-doc.php?name=pvr-rpi-mythtv-fe-be

The references section contains links to relevant MythTV Forum and Wiki
articles.

Regards,
Curtis
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

I'm running 33-fixes over wifi. It mostly works without playback problems.
Sounds like you should upgrade!

Steve Greene
(301) 842-8923
historicity.co
An independent archival professional specializing in still photography,
moving images and recorded sound.


On Fri, Feb 2, 2024 at 12:00?PM Curtis Gedak <gedakc@gmail.com> wrote:

> On 2024-02-01 13:56, Martin Bene wrote:
> > So, if anyone has any version of mythtv > 30 running on a pi frontend
> without tearing and without banding I’d really like to know what your
> configuration is.
>
> I have tested MythTV 31 on a Raspberry Pi 4 with mythfrontend and did
> not experience the above issues. However I did experience some judder
> when playing back 1080i OTA content. Hence I use options other than the
> RPi4 Mythfrontend for viewing recordings.
>
> I wrote a tutorial about it if it is of any help to you.
>
> Build a PVR using Raspberry Pi 4, MythTV, & HDHomeRun
>
> https://gedakc.users.sourceforge.net/display-doc.php?name=pvr-rpi-mythtv-fe-be
>
> The references section contains links to relevant MythTV Forum and Wiki
> articles.
>
> Regards,
> Curtis
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

Thanks Steve for the prompt response.

It would be helpful if you provide details on your MythTV configuration.

I believe that is what Martin was looking for with the original post.

Curtis

On 2024-02-02 10:11, Steve Greene wrote:
> I'm running 33-fixes over wifi. It mostly works without playback problems.
> Sounds like you should upgrade!
>
> Steve Greene
> (301) 842-8923
> historicity.co
> An independent archival professional specializing in still photography,
> moving images and recorded sound.
>
>
> On Fri, Feb 2, 2024 at 12:00?PM Curtis Gedak <gedakc@gmail.com> wrote:
>
>> On 2024-02-01 13:56, Martin Bene wrote:
>>> So, if anyone has any version of mythtv > 30 running on a pi frontend
>> without tearing and without banding I’d really like to know what your
>> configuration is.
>>
>> I have tested MythTV 31 on a Raspberry Pi 4 with mythfrontend and did
>> not experience the above issues. However I did experience some judder
>> when playing back 1080i OTA content. Hence I use options other than the
>> RPi4 Mythfrontend for viewing recordings.
>>
>> I wrote a tutorial about it if it is of any help to you.
>>
>> Build a PVR using Raspberry Pi 4, MythTV, & HDHomeRun
>>
>> https://gedakc.users.sourceforge.net/display-doc.php?name=pvr-rpi-mythtv-fe-be
>>
>> The references section contains links to relevant MythTV Forum and Wiki
>> articles.
>>
>> Regards,
>> Curtis
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Thanks for the Pointer.

Your documented setup uses MMAL acceleration, which is no longer available in current raspi os (and not at all on pi 5), so unfortunately not something I can try with current hard/software. I still have a pi 4, I'll give that a shot using legacy 32 bit OS which should still have MMAL.

Martin Bene,
no.disclaimer
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Hi,

* I'm running 33-fixes over wifi. It mostly works without playback problems. Sounds like you should upgrade!
Since the issues I’m seeing occurred after trying to update, it doesn’t seem to be so easy.

Can you provide some details on your configuration?

* Which OS exactly
* Which Model pi
* Which playback profile.
Thanks,
Martin Bene,
no.disclaimer

My install was with a Raspberry Pi 5, no surprises here. I'm using a
FLIRC-USB for wireless remotes. I'm running Ubuntu 23.10, using the default
packages. In Mythtv, the encoder choice was RPI5 (unsurprisingly). The only
concession I made to tweaking was to up the audio playback i/io buffer to
500. My system connects to a home router at WP54g speeds. OCCASIONALLY, you
will note minor glitches in playback, but they usually occur without
tearing the picture or distorting or skipping audio. These instances are
difficult to notice unless you're paying close attention.

Steve Greene
(301) 842-8921
historicity.co
An independent archival professional specializing in still photography,
moving images and recorded sound.


On Fri, Feb 2, 2024 at 6:05?PM Martin Bene <Martin.Bene@icomedias.com>
wrote:

> Hi,
>
> - I'm running 33-fixes over wifi. It mostly works without playback
> problems. Sounds like you should upgrade!
>
> Since the issues I’m seeing occurred after trying to update, it doesn’t
> seem to be so easy.
>
>
>
> Can you provide some details on your configuration?
>
> - Which OS exactly
> - Which Model pi
> - Which playback profile.
>
> Thanks,
>
> Martin Bene,
>
> no.disclaimer
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

I finally got a break after trying lots of different configurations / OS versions / Playback profiles without getting anywhere:

startx /usr/bin/mythfrontend does NOT have the tearing issues observed when starting the frontend from the default GUI Desktop!

So next step: finding out what other stuff is causing the issues...

Its xcompmgr

And that's an issue that’s been around for a long time; fairly recent discussion:
https://github.com/raspberrypi/linux/issues/5564
which was closed with the release of bookwork w/ default wayland - which doesn't have the tearing issue.

So current takeaway:
* in X11 xcompmgr must be disabled. In previous versions of raspi Os there was an option in raspi-config, no longer available in bookworm; removing /etc/xdg/autostart/xcompmgr.desktop works.
* wayland would be a better option, but the 16-bit RGB 5-6-5 Surface mythtv creates currently makes that impractical. I haven't had any success trying to get mythtv to initialize a proper 24-bit surface.

To recapitulate my configuration:

* Raspberry Pi OS, 64 bit, Bookworm
* switch from wayland to X11 using raspi-config
* disable xcompmgr by removing /etc/xdg/autostart/xcompmgr.desktop
* using precompiled mythtv-light (v34/master). sudo apt install ./mythtv-light.deb will resolve and install dependencies.

Martin Bene
No disclaimer

HybridForms® We enable companies & authorities to vastly reduce delays – by transforming paper forms to digital workflows

Watch: HybridForms.net/Video<https://hybridforms.net/Video> Folder: HybridForms.net/Product<https://hybridforms.net/Product> Test: HybridForms.net/Start<https://hybridforms.net/Start> Web: HybridForms.net<https://hybridforms.net/>

[.HybridForms® We enable companies & authorities to vastly reduce delays – by transforming paper forms to digital workflows. Mobile offline App for iOS, Android, Windows and Progressive Web App]<https://hybridforms.net/emailbanner>
© icomedias.com<http://icomedias.com> | icomedias®_group – GDPR | DSGVO Privacy policy<https://www.icomedias.com/en/privacy/> – HybridForms<https://www.HybridForms.net> is a trademark by icomedias group.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Hi,


* Also did you notice any artifacts regarding color, like the color depth was low? Are you running the mythfrontend from the desktop or standalone. Thanks.

Low color depth: I noticed that on wayland, color depth defaults to 16 bit, (RGB 5:6:5); in contrast, X11 which defaults to 24 bit (RGB 8:8:8) this leads to quite visible banding when displaying gradients; it’s quite visible both in the menus and when playing content.

Just had the first success with a source code modification that actually requests a format using 8 bits/pixel under wayland; I’ll add that to an issue I opened on github.

Martin Bene,
no.disclaimer

On Mon, Feb 5, 2024 at 1:51?PM Martin Bene <Martin.Bene@icomedias.com>
wrote:

> Hi,
>
>
>
> - Also did you notice any artifacts regarding color, like the color
> depth was low? Are you running the mythfrontend from the desktop or
> standalone. Thanks.
>
>
>
> Low color depth: I noticed that on wayland, color depth defaults to 16
> bit, (RGB 5:6:5); in contrast, X11 which defaults to 24 bit (RGB 8:8:8)
> this leads to quite visible banding when displaying gradients; it’s quite
> visible both in the menus and when playing content.
>
>
>
> Just had the first success with a source code modification that actually
> requests a format using 8 bits/pixel under wayland; I’ll add that to an
> issue I opened on github.
>

Hi, can you give us the modification so I can patch it in also? thanks.


>
>
> Martin Bene,
>
> no.disclaimer
>
>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

On Sat, Feb 10, 2024 at 2:32?PM Monkey Pet <monkeypet@gmail.com> wrote:

> On Mon, Feb 5, 2024 at 1:51?PM Martin Bene <Martin.Bene@icomedias.com>
> wrote:
>
>> Hi,
>>
>>
>>
>> - Also did you notice any artifacts regarding color, like the color
>> depth was low? Are you running the mythfrontend from the desktop or
>> standalone. Thanks.
>>
>>
>>
>> Low color depth: I noticed that on wayland, color depth defaults to 16
>> bit, (RGB 5:6:5); in contrast, X11 which defaults to 24 bit (RGB 8:8:8)
>> this leads to quite visible banding when displaying gradients; it’s quite
>> visible both in the menus and when playing content.
>>
>>
>>
>> Just had the first success with a source code modification that actually
>> requests a format using 8 bits/pixel under wayland; I’ll add that to an
>> issue I opened on github.
>>
>
> Hi, can you give us the modification so I can patch it in also? thanks.
>

I found this, https://github.com/MythTV/mythtv/issues/855
I patched the file and it seems much better, thanks.


>
>
>>
>>
>> Martin Bene,
>>
>> no.disclaimer
>>
>>
>>
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users@mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>>
>

> On Feb 11, 2024, at 06:32, Monkey Pet <monkeypet@gmail.com> wrote:
>
> On Mon, Feb 5, 2024 at 1:51?PM Martin Bene <Martin.Bene@icomedias.com> wrote:
> Hi,
>
> • Also did you notice any artifacts regarding color, like the color depth was low? Are you running the mythfrontend from the desktop or standalone. Thanks.
>
> Low color depth: I noticed that on wayland, color depth defaults to 16 bit, (RGB 5:6:5); in contrast, X11 which defaults to 24 bit (RGB 8:8:8) this leads to quite visible banding when displaying gradients; it’s quite visible both in the menus and when playing content.
> Just had the first success with a source code modification that actually requests a format using 8 bits/pixel under wayland; I’ll add that to an issue I opened on github.
>
> Hi, can you give us the modification so I can patch it in also? thanks.

Everything I’ve tried goes amock with wayland eg kdenlive eg nomachine eg tiggervnc.
From a group that I imagine has realistic opinions are there any pros to wayland? I see the cons as [it’s newer than xorg] [very anti sharing desktop] (since most of my machines are headless that is a biggie) [colour spaces]

I seek not turf wars, so if you are ardently pro your opinion is probably sus. Anybody?

James
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Hi,
Low color depth: I noticed that on wayland, color depth defaults to 16 bit, (RGB 5:6:5); in contrast, X11 which defaults to 24 bit (RGB 8:8:8) this leads to quite visible banding when displaying gradients; it’s quite visible both in the menus and when playing content.
Just had the first success with a source code modification that actually requests a format using 8 bits/pixel under wayland; I’ll add that to an issue I opened on github.
Hi, can you give us the modification so I can patch it in also? thanks.

I found this, https://github.com/MythTV/mythtv/issues/855
I patched the file and it seems much better, thanks.

Yes, that’s the right one. I should probably change that to use the qt platform type instead of an environment variable so it works without having to change the frontend invocation.
Next thing to look into is screensaver / dmps integration – that doesn’t seem to work quite right yet. When running frontend in a window, menu interactions using a remote control don’t reset the idle timer and when running fullscreen dpms blanking doesn’t happen at all.

Martin
no.disclaimer

On Sun, Feb 11, 2024 at 2:22?AM Martin Bene <Martin.Bene@icomedias.com>
wrote:

> Hi,
>
> Low color depth: I noticed that on wayland, color depth defaults to 16
> bit, (RGB 5:6:5); in contrast, X11 which defaults to 24 bit (RGB 8:8:8)
> this leads to quite visible banding when displaying gradients; it’s quite
> visible both in the menus and when playing content.
>
> Just had the first success with a source code modification that actually
> requests a format using 8 bits/pixel under wayland; I’ll add that to an
> issue I opened on github.
>
> Hi, can you give us the modification so I can patch it in also? thanks.
>
>
>
> I found this, https://github.com/MythTV/mythtv/issues/855
>
> I patched the file and it seems much better, thanks.
>
>
>
> Yes, that’s the right one. I should probably change that to use the qt
> platform type instead of an environment variable so it works without having
> to change the frontend invocation.
>
> Next thing to look into is screensaver / dmps integration – that doesn’t
> seem to work quite right yet. When running frontend in a window, menu
> interactions using a remote control don’t reset the idle timer and when
> running fullscreen dpms blanking doesn’t happen at all.
>

Also hiding the cursor doesn't work in Wayland, there were some utilities I
found, but I didn't patch it up to work yet, I've been just moving the
mouse on bootup.


>
>
> Martin
>
> no.disclaimer
>
>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

* VAlso hiding the cursor doesn't work in Wayland, there were some utilities I found, but I didn't patch it up to work yet, I've been just moving the mouse on bootup.

I got that working by using the hide-cursor plugin from wayfire-plugins extra https://github.com/WayfireWM/wayfire-plugins-extra

wayfire.ini

[core]
plugins = alpha animate autostart autostart-static command cube pixdecor expo fast-switcher fisheye grid idle invert move oswitch place resize switcher vswitch window-rules wm-actions wrot zoom winshadows hide-cursor

baseline plugins from /etc/wayfire/defaults.ini + the added hide-cursor plugin. Works just fine for me.

Martin
no.disclaimer

* Next thing to look into is screensaver / dmps integration – that doesn’t seem to work quite right yet. When running frontend in a window, menu interactions using a remote control don’t reset the idle timer and when running fullscreen dpms blanking doesn’t happen at all.


For the first part: using a lirc remote control bypasses the wayland input devices and thus does not interact with the screen blank inactivity timer.
mythtv actually interfaces with wayland screen blanking inhibitor since nov 2020.
The interface works by creating an inhibitor object associated with a surface when starting to play video and destroying the inhibitor object when playback stops and also when navigating the menus.

Problem: when navigating the menus, an inhibitor object is destroyed if it exists, but nothing is done if there is no current inhibitor.

The interface doesn’t seem to have any function for explicitly resetting the idle timer;

One quick thing to try: modify
mythtv/libs/libmythui/platforms/mythscreensaverwayland.cpp
to actually create an inhibitor in MythScreenSaverWayland::Disable() if it doesn’t exist and then destroy it – hopefully that will reset the idle timer.

The 2nd part is just a configuration error – wayfire idle plugin has a setting disable_on_fullscreen that defaults to true.
So we have to disable that in wayfire.ini

[idle]
dpms_timeout = 300
disable_on_fullscreen = false

Martin
no.disclaimer

Are you seeing freezes while navigating the recordings menu and browsing
recordings list? I see freezes lasting a few seconds, then everything comes
back, during the freeze, the UI doesn't take any input, but queues up the
keys, then a few seconds later, everything comes back. Super strange, but
noticeable for me. I am booting from an sd card, but I don't know the
speed, so I am not sure if that is causing things to freeze once in a
while. However, there is no freeze when I start a playback. Even when
overclocking, the freeze is still there, it was there prior to overclocking
also. Running v33 frontend.

On Sun, Feb 11, 2024 at 9:18?AM Martin Bene <Martin.Bene@icomedias.com>
wrote:

>
>
> - Next thing to look into is screensaver / dmps integration – that
> doesn’t seem to work quite right yet. When running frontend in a window,
> menu interactions using a remote control don’t reset the idle timer and
> when running fullscreen dpms blanking doesn’t happen at all.
>
>
>
>
>
> For the first part: using a lirc remote control bypasses the wayland input
> devices and thus does not interact with the screen blank inactivity timer.
>
> mythtv actually interfaces with wayland screen blanking inhibitor since
> nov 2020.
>
> The interface works by creating an inhibitor object associated with a
> surface when starting to play video and destroying the inhibitor object
> when playback stops and also when navigating the menus.
>
>
>
> Problem: when navigating the menus, an inhibitor object is destroyed if it
> exists, but nothing is done if there is no current inhibitor.
>
>
>
> The interface doesn’t seem to have any function for explicitly resetting
> the idle timer;
>
>
>
> One quick thing to try: modify
> mythtv/libs/libmythui/platforms/mythscreensaverwayland.cpp
>
> to actually create an inhibitor in MythScreenSaverWayland::Disable() if it
> doesn’t exist and then destroy it – hopefully that will reset the idle
> timer.
>
>
>
> The 2nd part is just a configuration error – wayfire idle plugin has a
> setting disable_on_fullscreen that defaults to true.
>
> So we have to disable that in wayfire.ini
>
>
>
> [idle]
>
> dpms_timeout = 300
>
> disable_on_fullscreen = false
>
>
>
> Martin
>
> no.disclaimer
>
>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

* Are you seeing freezes while navigating the recordings menu and browsing recordings list? I see freezes lasting a few seconds, then everything comes back, during the freeze, the UI doesn't take any input, but queues up the keys, then a few seconds later, everything comes back. Super strange, but noticeable for me. I am booting from an sd card, but I don't know the speed, so I am not sure if that is causing things to freeze once in a while. However, there is no freeze when I start a playback. Even when overclocking, the freeze is still there, it was there prior to overclocking also. Running v33 frontend.

No, haven’t seen anything like that, but haven’t used v33; my “production” system is still on 30 w/ raspi3 openmax frontends (and before that many older frontends and versions – oldest recording is 12/2004); trying to move from that to 34/fixes. I’ve been trying pi4/2GB and pi5/4gb on master (and now 34 fixes). Also running from sd.

Martin
no.disclaimer

> Problem: when navigating the menus, an inhibitor object is destroyed if it exists, but nothing is done if there is no current inhibitor.
> The interface doesn’t seem to have any function for explicitly resetting the idle timer;

> One quick thing to try: modify
> mythtv/libs/libmythui/platforms/mythscreensaverwayland.cpp
> to actually create an inhibitor in MythScreenSaverWayland::Disable() if it doesn’t exist and then destroy it – hopefully that will reset the idle timer.

Well, that's only a partial success unfortunately: creating and then destroying the idle inhibitor does extend the timeout while the display is active. What it can't do is reactivate the display once it goes into idle mode. That matches declared interface semantics:

If the surface is destroyed, unmapped, becomes occluded, loses
visibility, or otherwise becomes not visually relevant for the user, the
idle inhibitor will not be honored by the compositor

So far, I have failed to find any way for an application to request the display to resume from idle state. Please let me know if you have any idea on how to do that in wayland

Martin
no.disclaimer





_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org