Mailing List Archive

On Thu, 9 Mar 2023 18:27:06 -0500, you wrote:

>Hi folks,
>
>I'm a strong believer in "If it ain't broke, don't fix it!"
>But at the same time I also don't want to be running
>unsupported/vulnerable platforms. And it's touch hard to reconcile
>these two different mindsets.
>
>Given the upcoming EOL of Ubuntu 18.04, I figure that it's time to
>update things. But before I dig into this project, I'm curious about
>any snags that one might expect in either the updating of a MythTV box's
>underlying Ubuntu version, or the updating of MythTV itself.
>
>Having skimmed through this list from time to time, I seem to recall
>seeing messages along the line of "lirc doesn't work anymore unless you
>do <blah>", or something similar.
>
>Is there a resource out there that covers the various things that may
>break as the result of doing such an update (both MythTV and Ubuntu, if
>I had my wishes), and what can be done to prevent/correct them?
>Obviously I'll have a full system backup before going down this path,
>but I'd like to avoid surprises and the related time sinks.
>
>
>Thanks
>-WD

I am afraid that there is no specific resource where all the
accumulated knowledge about update problems resides. This list and
the forum will have what you need, but finding it will be a problem.
The upside of waiting so long to upgrade is that all the problems you
might encounter should already have been met by other people and
solved already.

If you have not already upgraded the PC to use SSD for the operating
system, it is best to do that before upgrading the Ubuntu version, as
without SSD the upgrade times would be pretty bad now. Especially as
you will need to do two upgrades - 18.04 to 20.04 and then 20.04 to
22.04.

When I do an Ubuntu version upgrade, there are always config files
that the upgrade process flags as having been altered from the
standard version, and the upgrade pauses on each one to ask what you
want to do about it (keep the old one, or use the new one, or manually
fix the problem). I use a GUI diff program (vsdiff that comes with my
pay Slickedit editor) to compare the old and new files and create a
merged version. Most of the time, the changes are obvious and I just
have to copy things from the either version of the file appropriately.
I would recommend that you find yourself a good GUI diff program and
try it out before doing the upgrades.

About lirc specifically, I believe the "lirc does not work" problem is
fixed in 22.04 (the missing _client.so file is present), but you may
still need to update your lirc config for it to work properly. You
should not use the lirc_setup program though, as it accidentally
somehow deletes the _client.so file, so you need to manually set up
the /etc/lirc/lirc_options.conf file. Should the _client.so file be
deleted, you can just reinstall it by using this command:

sudo apt install --reinstall lirc

I think the major updates to lirc happened in the 16.04 to 18.04
upgrade (the drivers moved into the kernel mostly), so your 18.04
setup should only need tweaks rather than anything major. If you have
customised your keymap files in /etc/rc_keymaps, then they will need
to be converted to the new .toml format. See
/usr/lib/udev/rc_keymaps/ for the standard .toml keymap files that you
can copy and modify. It is only a format change, the content in the
files is the same. And if you are using
/etc/lirc/lircd.conf.d/devinput.lircd.conf to configure the remote
keystrokes, the new lirc has slightly updated versions in each Ubuntu
upgrade, usually to add new keystrokes, but some have been renamed
occasionally. I just run a diff between the new and old versions and
it is usually clear what changes are needed. Then you may need to
change your $(HOME)/<mythfrontend user>/.lircrc/mythtv file to match
any changed names in devinput.lircd.conf.

For mythweb, each new version of Ubuntu updates the PHP version, so
you need to make sure you change your Apache2 config to use the new
version. This does not happen automatically. To do this for php8.1
in Ubuntu 22.04:

sudo a2query -m | grep php

to see the currently enabled php module version and then:

sudo a2dismod php<old-version-number>
sudo a2enmod php8.1
sudo systemctl restart apache2
_______________________________________________
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 09/03/2023 23:27, Will Dormann wrote:
> Hi folks,
> .
> .
> .
>
> Having skimmed through this list from time to time, I seem to recall
> seeing messages along the line of "lirc doesn't work anymore unless you
> do <blah>", or something similar.


I went through the swap from lirc to evdev last year. I build the disc
image for my frontend with kiwi-ng and have the recipe in a git
repository here: https://github.com/Glidos/kiwi-mythfrontend

Looking back, I can see that I ...

* Removed lirc from the system including all the old config and tables

* Added a package called v4l-utils (may be called something else in
distros other than openSuSE)

* Created a file called rc6_mce in /etc/rc_keymaps, containing

0x800f0400 KEY_0
0x800f0401 KEY_1
0x800f0402 KEY_2
0x800f0403 KEY_3
0x800f0404 KEY_4
0x800f0405 KEY_5
0x800f0406 KEY_6
0x800f0407 KEY_7
0x800f0408 KEY_8
0x800f0409 KEY_9
0x800f040c KEY_T
0x800f040d KEY_M
0x800f040f KEY_I
0x800f0410 KEY_F11
0x800f0411 KEY_F10
0x800f0412 KEY_UP
0x800f0413 KEY_DOWN
0x800f0414 KEY_RIGHTBRACE
0x800f0415 KEY_LEFTBRACE
0x800f0416 KEY_ENTER
0x800f0417 KEY_R
0x800f0418 KEY_P
0x800f0419 KEY_O
0x800f041a KEY_Z
0x800f041b KEY_Q
0x800f041c KEY_T
0x800f041d KEY_T
0x800f041e KEY_UP
0x800f041f KEY_DOWN
0x800f0420 KEY_LEFT
0x800f0421 KEY_RIGHT
0x800f0422 KEY_ENTER
0x800f0423 KEY_ESC
0x800f0426 KEY_S


I think I may have come up with those codes by running a program that
displayed them while pressing keys on the remote, but I can't off hand
remember the name of the program.
_______________________________________________
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 Fri, 10 Mar 2023 10:24:43 +0000, you wrote:

>On 09/03/2023 23:27, Will Dormann wrote:
>> Hi folks,
>> .
> > .
> > .
>>
>> Having skimmed through this list from time to time, I seem to recall
>> seeing messages along the line of "lirc doesn't work anymore unless you
>> do <blah>", or something similar.
>
>
>I went through the swap from lirc to evdev last year. I build the disc
>image for my frontend with kiwi-ng and have the recipe in a git
>repository here: https://github.com/Glidos/kiwi-mythfrontend
>
>Looking back, I can see that I ...
>
>* Removed lirc from the system including all the old config and tables
>
>* Added a package called v4l-utils (may be called something else in
>distros other than openSuSE)
>
>* Created a file called rc6_mce in /etc/rc_keymaps, containing
>
>0x800f0400 KEY_0
>0x800f0401 KEY_1
>0x800f0402 KEY_2
>0x800f0403 KEY_3
>0x800f0404 KEY_4
>0x800f0405 KEY_5
>0x800f0406 KEY_6
>0x800f0407 KEY_7
>0x800f0408 KEY_8
>0x800f0409 KEY_9
>0x800f040c KEY_T
>0x800f040d KEY_M
>0x800f040f KEY_I
>0x800f0410 KEY_F11
>0x800f0411 KEY_F10
>0x800f0412 KEY_UP
>0x800f0413 KEY_DOWN
>0x800f0414 KEY_RIGHTBRACE
>0x800f0415 KEY_LEFTBRACE
>0x800f0416 KEY_ENTER
>0x800f0417 KEY_R
>0x800f0418 KEY_P
>0x800f0419 KEY_O
>0x800f041a KEY_Z
>0x800f041b KEY_Q
>0x800f041c KEY_T
>0x800f041d KEY_T
>0x800f041e KEY_UP
>0x800f041f KEY_DOWN
>0x800f0420 KEY_LEFT
>0x800f0421 KEY_RIGHT
>0x800f0422 KEY_ENTER
>0x800f0423 KEY_ESC
>0x800f0426 KEY_S
>
>
>I think I may have come up with those codes by running a program that
>displayed them while pressing keys on the remote, but I can't off hand
>remember the name of the program.

If you go down that route, remember that the remote can only be used
for one program (MythTV). I always need to use mplayer as an
alternative player from mythfrontend, as I have quite a few old .wmv
files and some DVDs that MythTV can not play properly. So using
direct key mappings would not work for using the remote with
mythfrontend and mplayer.

Your rc6_mce file is in the old format. For Ubuntu 22.04, it would
need to be converted to .toml format, which looks like this where I
have copied the original and added one new key assignment that was
missing:

root@crw-pvr:/etc/rc_keymaps# cat haupp.toml
[[protocols]]
name = "haupp"
protocol = "unknown"
[protocols.scancodes]
0x1e00 = "KEY_0"
0x1e01 = "KEY_1"
0x1e02 = "KEY_2"
0x1e03 = "KEY_3"
0x1e04 = "KEY_4"
0x1e05 = "KEY_5"
0x1e06 = "KEY_6"
0x1e07 = "KEY_7"
0x1e08 = "KEY_8"
0x1e09 = "KEY_9"
0x1e0a = "KEY_KPASTERISK"
0x1e0b = "KEY_RED"
0x1e0c = "KEY_RADIO"
0x1e0d = "KEY_MENU"
0x1e0e = "KEY_GRAVE"
0x1e0f = "KEY_MUTE"
0x1e10 = "KEY_VOLUMEUP"
0x1e11 = "KEY_VOLUMEDOWN"
0x1e12 = "KEY_CHANNEL"
0x1e14 = "KEY_UP"
0x1e15 = "KEY_DOWN"
0x1e16 = "KEY_LEFT"
0x1e17 = "KEY_RIGHT"
0x1e18 = "KEY_VIDEO"
0x1e19 = "KEY_AUDIO"
0x1e1a = "KEY_IMAGES"
0x1e1b = "KEY_EPG"
0x1e1c = "KEY_TV"
0x1e1e = "KEY_NEXT"
0x1e1f = "KEY_BACK"
0x1e20 = "KEY_CHANNELUP"
0x1e21 = "KEY_CHANNELDOWN"
0x1e24 = "KEY_LAST"
0x1e25 = "KEY_OK"
0x1e29 = "KEY_BLUE"
0x1e2e = "KEY_GREEN"
0x1e30 = "KEY_PAUSE"
0x1e32 = "KEY_REWIND"
0x1e34 = "KEY_FASTFORWARD"
0x1e35 = "KEY_PLAY"
0x1e36 = "KEY_STOP"
0x1e37 = "KEY_RECORD"
0x1e38 = "KEY_YELLOW"
0x1e3b = "KEY_GOTO"
0x1e3d = "KEY_POWER"

# JSW additions
0x1e27 = "KEY_ENTER"
_______________________________________________
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

>
> 0x800f0422 KEY_ENTER
> 0x800f0423 KEY_ESC
> 0x800f0426 KEY_S
>
>
> I think I may have come up with those codes by running a program that
> displayed them while pressing keys on the remote, but I can't off hand
> remember the name of the program.
> _______________________________________________
>
>
I've used xev in the past for something like that.

On 10/03/2023 11:45, Stephen Worthington wrote:
> On Fri, 10 Mar 2023 10:24:43 +0000, you wrote:
>
>> On 09/03/2023 23:27, Will Dormann wrote:
>>> Hi folks,
>>> .
>>> .
>>> .
>>>
>>> Having skimmed through this list from time to time, I seem to recall
>>> seeing messages along the line of "lirc doesn't work anymore unless you
>>> do <blah>", or something similar.
>>
>>
>> I went through the swap from lirc to evdev last year. I build the disc
>> image for my frontend with kiwi-ng and have the recipe in a git
>> repository here: https://github.com/Glidos/kiwi-mythfrontend
>>
>> Looking back, I can see that I ...
>>
>> * Removed lirc from the system including all the old config and tables
>>
>> * Added a package called v4l-utils (may be called something else in
>> distros other than openSuSE)
>>
>> * Created a file called rc6_mce in /etc/rc_keymaps, containing
>>
>> 0x800f0400 KEY_0
>> 0x800f0401 KEY_1
>> 0x800f0402 KEY_2
>> 0x800f0403 KEY_3
>> 0x800f0404 KEY_4
>> 0x800f0405 KEY_5
>> 0x800f0406 KEY_6
>> 0x800f0407 KEY_7
>> 0x800f0408 KEY_8
>> 0x800f0409 KEY_9
>> 0x800f040c KEY_T
>> 0x800f040d KEY_M
>> 0x800f040f KEY_I
>> 0x800f0410 KEY_F11
>> 0x800f0411 KEY_F10
>> 0x800f0412 KEY_UP
>> 0x800f0413 KEY_DOWN
>> 0x800f0414 KEY_RIGHTBRACE
>> 0x800f0415 KEY_LEFTBRACE
>> 0x800f0416 KEY_ENTER
>> 0x800f0417 KEY_R
>> 0x800f0418 KEY_P
>> 0x800f0419 KEY_O
>> 0x800f041a KEY_Z
>> 0x800f041b KEY_Q
>> 0x800f041c KEY_T
>> 0x800f041d KEY_T
>> 0x800f041e KEY_UP
>> 0x800f041f KEY_DOWN
>> 0x800f0420 KEY_LEFT
>> 0x800f0421 KEY_RIGHT
>> 0x800f0422 KEY_ENTER
>> 0x800f0423 KEY_ESC
>> 0x800f0426 KEY_S
>>
>>
>> I think I may have come up with those codes by running a program that
>> displayed them while pressing keys on the remote, but I can't off hand
>> remember the name of the program.
>
> If you go down that route, remember that the remote can only be used
> for one program (MythTV). I always need to use mplayer as an
> alternative player from mythfrontend, as I have quite a few old .wmv
> files and some DVDs that MythTV can not play properly. So using
> direct key mappings would not work for using the remote with
> mythfrontend and mplayer.

Yes, I was aware of that. Have you found an alternative method that
avoids that limitation.

> Your rc6_mce file is in the old format. For Ubuntu 22.04, it would
> need to be converted to .toml format, which looks like this where I
> have copied the original and added one new key assignment that was
> missing:
>
> root@crw-pvr:/etc/rc_keymaps# cat haupp.toml
> [[protocols]]
> name = "haupp"
> protocol = "unknown"
> [protocols.scancodes]
> 0x1e00 = "KEY_0"
> 0x1e01 = "KEY_1"
> 0x1e02 = "KEY_2"
> 0x1e03 = "KEY_3"
> 0x1e04 = "KEY_4"
> 0x1e05 = "KEY_5"
> 0x1e06 = "KEY_6"
> 0x1e07 = "KEY_7"
> 0x1e08 = "KEY_8"
> 0x1e09 = "KEY_9"
> 0x1e0a = "KEY_KPASTERISK"
> 0x1e0b = "KEY_RED"
> 0x1e0c = "KEY_RADIO"
> 0x1e0d = "KEY_MENU"
> 0x1e0e = "KEY_GRAVE"
> 0x1e0f = "KEY_MUTE"
> 0x1e10 = "KEY_VOLUMEUP"
> 0x1e11 = "KEY_VOLUMEDOWN"
> 0x1e12 = "KEY_CHANNEL"
> 0x1e14 = "KEY_UP"
> 0x1e15 = "KEY_DOWN"
> 0x1e16 = "KEY_LEFT"
> 0x1e17 = "KEY_RIGHT"
> 0x1e18 = "KEY_VIDEO"
> 0x1e19 = "KEY_AUDIO"
> 0x1e1a = "KEY_IMAGES"
> 0x1e1b = "KEY_EPG"
> 0x1e1c = "KEY_TV"
> 0x1e1e = "KEY_NEXT"
> 0x1e1f = "KEY_BACK"
> 0x1e20 = "KEY_CHANNELUP"
> 0x1e21 = "KEY_CHANNELDOWN"
> 0x1e24 = "KEY_LAST"
> 0x1e25 = "KEY_OK"
> 0x1e29 = "KEY_BLUE"
> 0x1e2e = "KEY_GREEN"
> 0x1e30 = "KEY_PAUSE"
> 0x1e32 = "KEY_REWIND"
> 0x1e34 = "KEY_FASTFORWARD"
> 0x1e35 = "KEY_PLAY"
> 0x1e36 = "KEY_STOP"
> 0x1e37 = "KEY_RECORD"
> 0x1e38 = "KEY_YELLOW"
> 0x1e3b = "KEY_GOTO"
> 0x1e3d = "KEY_POWER"
>
> # JSW additions
> 0x1e27 = "KEY_ENTER"

Interesting, thanks. Do you know any good sources describing the
relationships between these formats. Sounds like something I should read
up on.
_______________________________________________
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 Will!
> Given the upcoming EOL of Ubuntu 18.04, I figure that it's time to
> update things. But before I dig into this project, I'm curious about
> any snags that one might expect in either the updating of a MythTV box's
> underlying Ubuntu version, or the updating of MythTV itself.

One problem you will run into is Ubuntu 22.04 will update MythTV to
version 32, or at least it does with the computers here running
Frontends.  MythTV will only 'see' one version, so a version 29 will not
see a version 32.

From my notes to update to Ubuntu 22.04 while staying at MythTV version
31 (hopefully work for your version 29):


Keep system from upgrading from the desired version. No need to set a
specific version.

|sudo apt-mark hold mythtv-frontend|


Keep system from upgrading from the desired version. No need to set a
specific version.

sudo apt-mark hold libmyth*

Had found there were numerous libraries so why the use of the wildcard.


Then do your OS upgrade.  Quite frankly this isn't foolproof: I had one
Frontend going from 18.04 --> 20.04 --> 22.04 (you can only go one
version at a time) which didn't like a certain libmyth file, copied
(then renamed), did an update/upgrade and it was fine, re-held the file,
and the rest of the transition to Jammy Jellyfish went fine.  I have
another Frontend which is still complaining about some file not being
current and so is stuck at 20.04 -- at least have a couple of years to
figure that out!


Good Luck!

Barry

On Fri, 10 Mar 2023 14:00:31 +0000, you wrote:

>On 10/03/2023 11:45, Stephen Worthington wrote:
>> On Fri, 10 Mar 2023 10:24:43 +0000, you wrote:
>>
>>> On 09/03/2023 23:27, Will Dormann wrote:
>>>> Hi folks,
>>>> .
>>>> .
>>>> .
>>>>
>>>> Having skimmed through this list from time to time, I seem to recall
>>>> seeing messages along the line of "lirc doesn't work anymore unless you
>>>> do <blah>", or something similar.
>>>
>>>
>>> I went through the swap from lirc to evdev last year. I build the disc
>>> image for my frontend with kiwi-ng and have the recipe in a git
>>> repository here: https://github.com/Glidos/kiwi-mythfrontend
>>>
>>> Looking back, I can see that I ...
>>>
>>> * Removed lirc from the system including all the old config and tables
>>>
>>> * Added a package called v4l-utils (may be called something else in
>>> distros other than openSuSE)
>>>
>>> * Created a file called rc6_mce in /etc/rc_keymaps, containing
>>>
>>> 0x800f0400 KEY_0
>>> 0x800f0401 KEY_1
>>> 0x800f0402 KEY_2
>>> 0x800f0403 KEY_3
>>> 0x800f0404 KEY_4
>>> 0x800f0405 KEY_5
>>> 0x800f0406 KEY_6
>>> 0x800f0407 KEY_7
>>> 0x800f0408 KEY_8
>>> 0x800f0409 KEY_9
>>> 0x800f040c KEY_T
>>> 0x800f040d KEY_M
>>> 0x800f040f KEY_I
>>> 0x800f0410 KEY_F11
>>> 0x800f0411 KEY_F10
>>> 0x800f0412 KEY_UP
>>> 0x800f0413 KEY_DOWN
>>> 0x800f0414 KEY_RIGHTBRACE
>>> 0x800f0415 KEY_LEFTBRACE
>>> 0x800f0416 KEY_ENTER
>>> 0x800f0417 KEY_R
>>> 0x800f0418 KEY_P
>>> 0x800f0419 KEY_O
>>> 0x800f041a KEY_Z
>>> 0x800f041b KEY_Q
>>> 0x800f041c KEY_T
>>> 0x800f041d KEY_T
>>> 0x800f041e KEY_UP
>>> 0x800f041f KEY_DOWN
>>> 0x800f0420 KEY_LEFT
>>> 0x800f0421 KEY_RIGHT
>>> 0x800f0422 KEY_ENTER
>>> 0x800f0423 KEY_ESC
>>> 0x800f0426 KEY_S
>>>
>>>
>>> I think I may have come up with those codes by running a program that
>>> displayed them while pressing keys on the remote, but I can't off hand
>>> remember the name of the program.
>>
>> If you go down that route, remember that the remote can only be used
>> for one program (MythTV). I always need to use mplayer as an
>> alternative player from mythfrontend, as I have quite a few old .wmv
>> files and some DVDs that MythTV can not play properly. So using
>> direct key mappings would not work for using the remote with
>> mythfrontend and mplayer.
>
>Yes, I was aware of that. Have you found an alternative method that
>avoids that limitation.
>
>> Your rc6_mce file is in the old format. For Ubuntu 22.04, it would
>> need to be converted to .toml format, which looks like this where I
>> have copied the original and added one new key assignment that was
>> missing:
>>
>> root@crw-pvr:/etc/rc_keymaps# cat haupp.toml
>> [[protocols]]
>> name = "haupp"
>> protocol = "unknown"
>> [protocols.scancodes]
>> 0x1e00 = "KEY_0"
>> 0x1e01 = "KEY_1"
>> 0x1e02 = "KEY_2"
>> 0x1e03 = "KEY_3"
>> 0x1e04 = "KEY_4"
>> 0x1e05 = "KEY_5"
>> 0x1e06 = "KEY_6"
>> 0x1e07 = "KEY_7"
>> 0x1e08 = "KEY_8"
>> 0x1e09 = "KEY_9"
>> 0x1e0a = "KEY_KPASTERISK"
>> 0x1e0b = "KEY_RED"
>> 0x1e0c = "KEY_RADIO"
>> 0x1e0d = "KEY_MENU"
>> 0x1e0e = "KEY_GRAVE"
>> 0x1e0f = "KEY_MUTE"
>> 0x1e10 = "KEY_VOLUMEUP"
>> 0x1e11 = "KEY_VOLUMEDOWN"
>> 0x1e12 = "KEY_CHANNEL"
>> 0x1e14 = "KEY_UP"
>> 0x1e15 = "KEY_DOWN"
>> 0x1e16 = "KEY_LEFT"
>> 0x1e17 = "KEY_RIGHT"
>> 0x1e18 = "KEY_VIDEO"
>> 0x1e19 = "KEY_AUDIO"
>> 0x1e1a = "KEY_IMAGES"
>> 0x1e1b = "KEY_EPG"
>> 0x1e1c = "KEY_TV"
>> 0x1e1e = "KEY_NEXT"
>> 0x1e1f = "KEY_BACK"
>> 0x1e20 = "KEY_CHANNELUP"
>> 0x1e21 = "KEY_CHANNELDOWN"
>> 0x1e24 = "KEY_LAST"
>> 0x1e25 = "KEY_OK"
>> 0x1e29 = "KEY_BLUE"
>> 0x1e2e = "KEY_GREEN"
>> 0x1e30 = "KEY_PAUSE"
>> 0x1e32 = "KEY_REWIND"
>> 0x1e34 = "KEY_FASTFORWARD"
>> 0x1e35 = "KEY_PLAY"
>> 0x1e36 = "KEY_STOP"
>> 0x1e37 = "KEY_RECORD"
>> 0x1e38 = "KEY_YELLOW"
>> 0x1e3b = "KEY_GOTO"
>> 0x1e3d = "KEY_POWER"
>>
>> # JSW additions
>> 0x1e27 = "KEY_ENTER"
>
>Interesting, thanks. Do you know any good sources describing the
>relationships between these formats. Sounds like something I should read
>up on.

Just read "man rc_keymap".
_______________________________________________
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 10 Mar 2023, at 10:00 pm, Barry Martin <barry3martin@gmail.com> wrote:
>
>
> Hi Will!
>> Given the upcoming EOL of Ubuntu 18.04, I figure that it's time to
>> update things. But before I dig into this project, I'm curious about
>> any snags that one might expect in either the updating of a MythTV box's
>> underlying Ubuntu version, or the updating of MythTV itself.
> One problem you will run into is Ubuntu 22.04 will update MythTV to version 32, or at least it does with the computers here running Frontends. MythTV will only 'see' one version, so a version 29 will not see a version 32.
> From my notes to update to Ubuntu 22.04 while staying at MythTV version 31 (hopefully work for your version 29):
>
>
>
> Keep system from upgrading from the desired version. No need to set a specific version.
> sudo apt-mark hold mythtv-frontend
>
>
>
> Keep system from upgrading from the desired version. No need to set a specific version.
> sudo apt-mark hold libmyth*
> Had found there were numerous libraries so why the use of the wildcard.
>
>
> Then do your OS upgrade. Quite frankly this isn't foolproof: I had one Frontend going from 18.04 --> 20.04 --> 22.04 (you can only go one version at a time) which didn't like a certain libmyth file, copied (then renamed), did an update/upgrade and it was fine, re-held the file, and the rest of the transition to Jammy Jellyfish went fine. I have another Frontend which is still complaining about some file not being current and so is stuck at 20.04 -- at least have a couple of years to figure that out!

Building the version you want, particularly ubuntu host, with ansible, is quick and easy and will let you get the latest fixes.
Personally I would never leave my mythtv to the whims of others, The only caveat is you need a good idea about the ins and outs of mythtv eg mysql setup and mythconverg_backup.pl, mythconverg_restore.pl
James

On 3/9/23 6:27 PM, Will Dormann wrote:
> Is there a resource out there that covers the various things that may
> break as the result of doing such an update (both MythTV and Ubuntu, if
> I had my wishes), and what can be done to prevent/correct them?
> Obviously I'll have a full system backup before going down this path,
> but I'd like to avoid surprises and the related time sinks.


Just an update for the benefit of anybody else who may be in a similar
boat. Obviously, my MythTV machine lineage and configuration won't
match what else is out there, but here was my experience FWIW:

From Ubuntu 18.04 to 20.04, and MythTV 2:29.1+fixes to 2:31.0+fixes (at
the same time):

Surprisingly, this double upgrade went mostly without issue at all! The
only thing that didn't work was after the upgrade mysqld wasn't
starting. This seems to be due to me at some point optimizing the mysql
performance, adding mysql config options that were dropped. Fixing this
involved looking at what option was not recognized, removing it, and
trying again. If memory serves me correctly, options were both in
/etc/mysql/my.cnf and /etc/mysql/conf.d/mythtv.conf



From Ubuntu 20.04 to 22.04:

This was much more problematic.
First, the nvidia drivers weren't loading. Despite what a google search
suggested, "sudo apt install xserver-xorg-video-nvidia-525" is what
fixed it. "sudo apt install nvidia-driver-525 nvidia-dkms-525" led to
some weirdness with the proprietary nvidia driver *not* being used by
Xorg. I also had to "sudo apt install flex bison" along the way, as
somehow in the OS upgrade, I ended up without the ability to compile the
nvidia modules.

Apache also wasn't running. I had to "sudo a2dismod php7.4" to get it
to start OK.

After the above steps (which took more time to figure out than I'd like
to admit), the resulting MythTV box was not ideal in two ways:

1) The deinterlacing with the 525 drivers was noticeably *worse* than
the nvidia 390 drivers that Ubuntu 20.04 was fine with. I think
switching to NVDEC for decoding made it better. But I'm not convinced
that the deinterlacing is better than what VDPAU got me with older
driver versions.

2) I have a cable box that it controlled by 6200ch. For some reason,
after the upgrade to Ubuntu 22.04, this channel changing script was not
behaving well. Upon changing the channel (e.g. via clicking on a
different channel using the MythTV channel guide), the resulting channel
was some combination of a completely wrong channel, not-in-HD, or some
strange menu / PPV screen from my cable box. I couldn't even notice an
off-by-one or dropped-character issue, as from what I can recall, trying
to select channel 600 would get me to channel 24, for example. Running
6200ch from a terminal worked 100% of the time, every time. Why there'd
be a difference between MythTV invoking 6200ch and me invoking it from a
shell is beyond me. But given the seemingly asynchronous nature of the
channel changing and the HD-PVR recording, some channel changes resulted
in the HD-PVR getting out of sync and choked up and dumping me back to
the MythTV menu.


I spent a decent amount of time troubleshooting this, but ended up
restoring to the backup that I made after the 20.04 upgrade. And
everything is back to normal.

I suppose I'm vaguely interested in what exactly caused the problems I
encountered with this upgrade. As far as I can tell, both my 20.04 and
22.04 experiments both used the exact same version of the MythTV
packages. So apparently something at the OS level is at fault here.
But at least I've bought myself 2 years here in the process.


-WD


_______________________________________________
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 Mon, 24 Apr 2023 21:43:34 -0400, you wrote:

> From Ubuntu 20.04 to 22.04:
>
>This was much more problematic.
>First, the nvidia drivers weren't loading. Despite what a google search
>suggested, "sudo apt install xserver-xorg-video-nvidia-525" is what
>fixed it. "sudo apt install nvidia-driver-525 nvidia-dkms-525" led to
>some weirdness with the proprietary nvidia driver *not* being used by
>Xorg. I also had to "sudo apt install flex bison" along the way, as
>somehow in the OS upgrade, I ended up without the ability to compile the
>nvidia modules.

I had a problem with the Nvidia drivers not loading recently, also
with the 525 drivers. What I found in the logs was that X was unable
to find the Nvidia .so files, despite them being in the same location
as usual. So I had to add this to my /etc/X11/xorg.conf file:

# For some reason X is unable to find the Nvidia drivers, so manual
paths
# are required.
Section "Files"
ModulePath "/usr/lib/x86_64-linux-gnu/nvidia/xorg/"
ModulePath "/usr/lib/xorg/modules"
EndSection

I have not tried removing it again when a new version of the Nvidia
525 drivers was installed.

Your problem with nvidia-dkms-525 may be related to a new thing that
the Nvidia drivers do on Ubuntu, which is to install pre-built *.ko
module files instead of compiling them against each kernel with dkms.
For some reason this does not always work, and you can get a failure
to load the Nvidia drivers. It is good when it does work, as you do
not have to wait for the dkms compiles when installing new kernels. I
have one 22.04 machine on 525 drivers where I have removed the
nvidia-dkms-525 package and it works. On another 22.04 machine I had
bad problems and backed off to 515 with dkms to get it to work again.
I should try updating that machine to 525 again now that there are
updated 525 versions since I had that problem.

For installing Nvidia drivers now, I use the "ubuntu-drivers install"
command, rather than trying to specify the packages in an apt command.

[snip]
>After the above steps (which took more time to figure out than I'd like
>to admit), the resulting MythTV box was not ideal in two ways:
>
>1) The deinterlacing with the 525 drivers was noticeably *worse* than
>the nvidia 390 drivers that Ubuntu 20.04 was fine with. I think
>switching to NVDEC for decoding made it better. But I'm not convinced
>that the deinterlacing is better than what VDPAU got me with older
>driver versions.

I find this interesting, as I am very sensitive to deinterlacing
problems and have not had this happen to me. I have been using both
VDPAU and NVDEC at times on the 525 drivers and can see no difference
between them, except for the NVDEC drivers supporting more 4K files
than VDPAU, and NVDEC not supporting some older video files. I do not
remember any difference in the deinterlacing as I moved through the
driver versions from 390 upwards. I am using Nvidia GT1030 cards.
_______________________________________________
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 4/24/23 11:59 PM, Stephen Worthington wrote:
> I find this interesting, as I am very sensitive to deinterlacing
> problems and have not had this happen to me. I have been using both
> VDPAU and NVDEC at times on the 525 drivers and can see no difference
> between them, except for the NVDEC drivers supporting more 4K files
> than VDPAU, and NVDEC not supporting some older video files. I do not
> remember any difference in the deinterlacing as I moved through the
> driver versions from 390 upwards. I am using Nvidia GT1030 cards.

Yeah, I can't rule out that it may be hardware-specific. In my case
it's a GeForce GT 730. I happened to have a horizontally-panning scene
on the TV at the time, and it was distractingly flickering.

Given that the broken-for-reasons-I-didn't-get-around-to-figuring-out
6200ch channel changer was the more-pressing deal breaker, I'll admit
that I didn't spend a whole lot of time poking around with the
deinterlacing issues. The fact that manually running 6200ch worked fine
from a shell, but not as expectd when invoked from MythTV sure was a
head scratcher for me. Could be as simple as a race condition between
the channel changing being sent out over firewire and the HD-PVR
starting to record. I did notice that the HD-PVR started recording
before 6200ch actually completes (tested via adding e.g. a 10-second
sleep to the channel changer). That's about the point where the time I
had sunk into looking at it had exceeded the value of being on a recent
Ubuntu version. :)

But after reverting back to my backup that had the 390 Nvidia drivers,
it's back to smooth / non-flickering / no evidence of having been
interlaced.


-WD
_______________________________________________
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 Tue, 25 Apr 2023 10:24:28 -0400, you wrote:

>On 4/24/23 11:59 PM, Stephen Worthington wrote:
>> I find this interesting, as I am very sensitive to deinterlacing
>> problems and have not had this happen to me. I have been using both
>> VDPAU and NVDEC at times on the 525 drivers and can see no difference
>> between them, except for the NVDEC drivers supporting more 4K files
>> than VDPAU, and NVDEC not supporting some older video files. I do not
>> remember any difference in the deinterlacing as I moved through the
>> driver versions from 390 upwards. I am using Nvidia GT1030 cards.
>
>Yeah, I can't rule out that it may be hardware-specific. In my case
>it's a GeForce GT 730. I happened to have a horizontally-panning scene
>on the TV at the time, and it was distractingly flickering.

Since a GT730 is obsolete (no longer sold), I doubt that the latest
drivers get much testing on it. So it is entirely possible that they
are broken with respect to a GT730. So sticking to an older driver
version that was around when they were still being sold is likely a
good idea, as the new things in the newer drivers tend to be only for
the new hardware anyway. But then eventually you will run into the
problem that the older drivers will stop being supported and will then
stop working with the newer kernels.

Juddering during panning is pretty sure sign the deinterlacing is not
working properly, but you can get that when using a very crude
deinterlacing algorithm instead of the best ones. Which could be a
configuration problem. If you want to check the deinterlacing
actually being used for playback, start playing a problem recording
and then do M(enu) > Playback > Playback Data. The information
displayed at the top of the picture includes a line right at the
bottom in the middle titled "Deint : " which tells you exactly what is
being used. For VDPAU it should say "2 x VDPAU advanced" and for
NVDEC it should be "2 x NVDEC adaptive".

Here in New Zealand, it used to be common on the Choice and HGTV
channels to get recordings with judder during panning, due to the
setup being used for converting ATSC 29.95 Hz to DVB-T 25 Hz not being
correct. They finally fixed that only after Discovery bought those
channels from the previous owners a couple of years ago. When I first
met that, it took me quite a while to discover that no amount of
fiddling with my deinterlace settings was ever going to be able to fix
it.

>Given that the broken-for-reasons-I-didn't-get-around-to-figuring-out
>6200ch channel changer was the more-pressing deal breaker, I'll admit
>that I didn't spend a whole lot of time poking around with the
>deinterlacing issues. The fact that manually running 6200ch worked fine
>from a shell, but not as expectd when invoked from MythTV sure was a
>head scratcher for me. Could be as simple as a race condition between
>the channel changing being sent out over firewire and the HD-PVR
>starting to record. I did notice that the HD-PVR started recording
>before 6200ch actually completes (tested via adding e.g. a 10-second
>sleep to the channel changer). That's about the point where the time I
>had sunk into looking at it had exceeded the value of being on a recent
>Ubuntu version. :)

Race conditions are always nasty to deal with. In this case, there
has been a recent bug fix in v33 that fixed the problem that
mythbackend was sometimes generating the pre-recording events at the
wrong times. It is possible that the same bug was affecting when the
channel change command was being run. If so, that might explain your
problem. It would pay to ask the devs exactly when the channel change
command is supposed to be being run, and check that it is actually
happening then and not later. If it is being run at the correct time,
you could consider running 6200ch from the pre-recording events (now
that they work properly), as there is a setting that can be used to
tell mythbackend how much before the recording start it should do the
first pre-recording event.

>But after reverting back to my backup that had the 390 Nvidia drivers,
>it's back to smooth / non-flickering / no evidence of having been
>interlaced.

Yes, that is vital to those of us who are bothered by it. My mother
does not notice such things.
_______________________________________________
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 Tue, Apr 25, 2023 at 11:29?AM Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:
>
> On Tue, 25 Apr 2023 10:24:28 -0400, you wrote:
>
> >On 4/24/23 11:59 PM, Stephen Worthington wrote:
> >> I find this interesting, as I am very sensitive to deinterlacing
> >> problems and have not had this happen to me. I have been using both
> >> VDPAU and NVDEC at times on the 525 drivers and can see no difference
> >> between them, except for the NVDEC drivers supporting more 4K files
> >> than VDPAU, and NVDEC not supporting some older video files. I do not
> >> remember any difference in the deinterlacing as I moved through the
> >> driver versions from 390 upwards. I am using Nvidia GT1030 cards.
> >
> >Yeah, I can't rule out that it may be hardware-specific. In my case
> >it's a GeForce GT 730. I happened to have a horizontally-panning scene
> >on the TV at the time, and it was distractingly flickering.
>
> Since a GT730 is obsolete (no longer sold), I doubt that the latest
> drivers get much testing on it. So it is entirely possible that they
> are broken with respect to a GT730. So sticking to an older driver
> version that was around when they were still being sold is likely a
> good idea, as the new things in the newer drivers tend to be only for
> the new hardware anyway. But then eventually you will run into the
> problem that the older drivers will stop being supported and will then
> stop working with the newer kernels.
>
> Juddering during panning is pretty sure sign the deinterlacing is not
> working properly, but you can get that when using a very crude
> deinterlacing algorithm instead of the best ones. Which could be a
> configuration problem. If you want to check the deinterlacing
> actually being used for playback, start playing a problem recording
> and then do M(enu) > Playback > Playback Data. The information
> displayed at the top of the picture includes a line right at the
> bottom in the middle titled "Deint : " which tells you exactly what is
> being used. For VDPAU it should say "2 x VDPAU advanced" and for
> NVDEC it should be "2 x NVDEC adaptive".
>
> Here in New Zealand, it used to be common on the Choice and HGTV
> channels to get recordings with judder during panning, due to the
> setup being used for converting ATSC 29.95 Hz to DVB-T 25 Hz not being
> correct. They finally fixed that only after Discovery bought those
> channels from the previous owners a couple of years ago. When I first
> met that, it took me quite a while to discover that no amount of
> fiddling with my deinterlace settings was ever going to be able to fix
> it.
>
> >Given that the broken-for-reasons-I-didn't-get-around-to-figuring-out
> >6200ch channel changer was the more-pressing deal breaker, I'll admit
> >that I didn't spend a whole lot of time poking around with the
> >deinterlacing issues. The fact that manually running 6200ch worked fine
> >from a shell, but not as expectd when invoked from MythTV sure was a
> >head scratcher for me. Could be as simple as a race condition between
> >the channel changing being sent out over firewire and the HD-PVR
> >starting to record. I did notice that the HD-PVR started recording
> >before 6200ch actually completes (tested via adding e.g. a 10-second
> >sleep to the channel changer). That's about the point where the time I
> >had sunk into looking at it had exceeded the value of being on a recent
> >Ubuntu version. :)
>
> Race conditions are always nasty to deal with. In this case, there
> has been a recent bug fix in v33 that fixed the problem that
> mythbackend was sometimes generating the pre-recording events at the
> wrong times. It is possible that the same bug was affecting when the
> channel change command was being run. If so, that might explain your
> problem. It would pay to ask the devs exactly when the channel change
> command is supposed to be being run, and check that it is actually
> happening then and not later. If it is being run at the correct time,
> you could consider running 6200ch from the pre-recording events (now
> that they work properly), as there is a setting that can be used to
> tell mythbackend how much before the recording start it should do the
> first pre-recording event.
>
> >But after reverting back to my backup that had the 390 Nvidia drivers,
> >it's back to smooth / non-flickering / no evidence of having been
> >interlaced.
>
> Yes, that is vital to those of us who are bothered by it. My mother
> does not notice such things.

It is crazy to me how some people do not notice - I have a friend
whose A/V was out of sync by > 300ms and they happily watched TV with
lips and audio off by that much. It drove me nuts to watch TV over
there until I syned the receiver and firestick.. Just goes to show
how "picky" we can be at times:)
_______________________________________________
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

Just a note, if you are really using an nvidia GT730 with the 525 drivers, are you sure it is actually using the nvidia drivers and not falling back to nouveau drivers?

Based on https://www.nvidia.com/Download/driverResults.aspx/204639/en-us/, the GT730 is not listed as under the supported cards.

But the Latest Legacy version (470 - https://www.nvidia.com/Download/driverResults.aspx/200634/en-us/) does list the GT730 as being supported.


_______________________________________________
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 4/26/23 12:24 AM, Mark Wedel wrote:
> Just a note, if you are really using an nvidia GT730 with the 525
> drivers, are you sure it is actually using the nvidia drivers and not
> falling back to nouveau drivers?

I'm pretty sure that I was. Based on:

1) The machine would not start X until I installed the
xserver-xorg-video-nvidia-525 package. All pre-525 nvidia packages were
removed.
2) I successfully used NVDEC for TV playback. Nouveau doesn't support
NVDEC, does it?



-WD

_______________________________________________
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 4/26/23 06:44, Will Dormann wrote:
> On 4/26/23 12:24 AM, Mark Wedel wrote:
>> Just a note, if you are really using an nvidia GT730 with the 525 drivers, are you sure it is actually using the nvidia drivers and not falling back to nouveau drivers?
>
> I'm pretty sure that I was.  Based on:
>
> 1) The machine would not start X until I installed the xserver-xorg-video-nvidia-525 package.  All pre-525 nvidia packages were removed.
> 2) I successfully used NVDEC for TV playback.  Nouveau doesn't support NVDEC, does it?

It doesn't look like it. But given that official nvidia docs say GT730 is not supported was 525 drivers, might not be surprising it doesn't work particularly well. It is possible that some parts that it needs to work well have been removed or otherwise no longer trigger.

It might also just mean that in some future version of that series of drivers, support will be fully removed, and right now is on borrowed time. I don't know if nvidia does this, but some companies don't like to drop support except in major releases (it would otherwise be annoying to update from say 525 to 530 and find devices stop working, but more reasonable to expect that from 5xx version to 6xx version)

_______________________________________________
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 Wed, Apr 26, 2023, at 23:45, Mark Wedel wrote:

> It doesn't look like it. But given that official nvidia docs say
> GT730 is not supported was 525 drivers, might not be surprising it
> doesn't work particularly well. It is possible that some parts that it
> needs to work well have been removed or otherwise no longer trigger.
>
> It might also just mean that in some future version of that series of
> drivers, support will be fully removed, and right now is on borrowed
> time. I don't know if nvidia does this, but some companies don't like
> to drop support except in major releases (it would otherwise be
> annoying to update from say 525 to 530 and find devices stop working,
> but more reasonable to expect that from 5xx version to 6xx version)

That's not really how it works with NVIDIA drivers. I have more experience with datacenter hardware, so I'm not sure if it's different for the desktop-grade cards (we do also run high-end consumer-grade cards in the data center), but a recent example was that R470 was the last release of the driver to support K80 GPUs. There was at least an R495 release that did not support them. R470 was a long-term support release, and that's typically where hardware support will end for a particular card, but the R5xx vs. R6xx seems to be more about support for new hardware or something and does not line up with end of support. They also will definitively not work, at least for datacenter grade cards, on a driver version too new to support them, which was initially how I found out that K80s were not supported by newer than R470: the driver will simply not load/cards will not be visible.

=R
_______________________________________________
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 4/24/23 9:43 PM, Will Dormann wrote:
> Just an update for the benefit of anybody else who may be in a similar
> boat.  Obviously, my MythTV machine lineage and configuration won't
> match what else is out there, but here was my experience FWIW:


Also, and while I don't regret getting this machine vaguely up to date,
for those of you in Ubuntu land:

If your main concern is to continue to receive security updates,
personal accounts (up to 5 machines) are available for Ubuntu Pro for free:
https://ubuntu.com/pro

This will extend the support of an LTS release from 5 years to 10 years!



-WD

_______________________________________________
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

Am 10.03.2023 um 15:00 schrieb Barry Martin:
>
>
> One problem you will run into is Ubuntu 22.04 will update MythTV to
> version 32, or at least it does with the computers here running
> Frontends.  MythTV will only 'see' one version, so a version 29 will not
> see a version 32.
>
> From my notes to update to Ubuntu 22.04 while staying at MythTV version
> 31 (hopefully work for your version 29):
>
>
> Keep system from upgrading from the desired version. No need to set a
> specific version.
>
> |sudo apt-mark hold mythtv-frontend|
>
>
> Keep system from upgrading from the desired version. No need to set a
> specific version.
>
> sudo apt-mark hold libmyth*
>
> Had found there were numerous libraries so why the use of the wildcard.
>
>
> Then do your OS upgrade.  Quite frankly this isn't foolproof: I had one
> Frontend going from 18.04 --> 20.04 --> 22.04 (you can only go one
> version at a time) which didn't like a certain libmyth file, copied
> (then renamed), did an update/upgrade and it was fine, re-held the file,
> and the rest of the transition to Jammy Jellyfish went fine.  I have
> another Frontend which is still complaining about some file not being
> current and so is stuck at 20.04 -- at least have a couple of years to
> figure that out!
>
>

I didn't upgrade but installed a new frontend with Lubuntu 22.04. And
beneath mythtv-frontend and libmyth, I had to "apt-mark hold"
mythtv-common too.

Actually, I did a downgrade:

- first install mythtv-frontend that comes with Lubuntu 22.04, aka
version 32, then remove the packages mythtv-frontend, libmyth and
mythtv-common without removing dependencies

- then install version 31 of the three above mentioned packages (one
requires a further package as a dependency, but I can't remember which one)

You can download the packages from here:

https://launchpad.net/~mythbuntu/+archive/ubuntu/31/+build/23217944
_______________________________________________
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