Mailing List Archive

Ubuntu Mythbackend issue
having tons of issues with CentOS 7 and it's repository, so spun up an
Ubuntu 16, installed a backend.

it came up - but had a ton of problem getting the frontend to talk to it.
Found out that the config.xml changes the password so i had to use that
goofy password in the "mysql" install.

So when it finally talked from frontend, i thought yipee.

but i am getting these:

https://pastebin.com/Sq8Bp8yc


I checked permissions inside and it gets me this:
Ubuntu Mythbackend issue [ In reply to ]
having tons of issues with CentOS 7 and it's repository, so spun up an
Ubuntu 16, installed a backend.

it came up - but had a ton of problem getting the frontend to talk to it.
Found out that the config.xml changes the password so i had to use that
goofy password in the "mysql" install.

So when it finally talked from frontend, i thought yipee.

but i am getting these:

https://pastebin.com/Sq8Bp8yc


I checked permissions inside and it gets me this:

https://pastebin.com/9ySdTtXD
Re: Ubuntu Mythbackend issue [ In reply to ]
On 12/05/18 13:27, Ashu Desai wrote:
having tons of issues with CentOS 7 and it's repository, so spun up an Ubuntu 16, installed a backend.

it came up - but had a ton of problem getting the frontend to talk to it. Found out that the config.xml changes the password so i had to use that goofy password in the "mysql" install.

So when it finally talked from frontend, i thought yipee.

but i am getting these:

https://pastebin.com/Sq8Bp8yc


I checked permissions inside and it gets me this:

https://pastebin.com/9ySdTtXD


Looks to me like the FE is talking to the database (port 3306) but not the backend (port 6543). Is your BE on the same machine / IP as the database?


1.
2018-05-11 18:28:14.563156 I MythCoreContext::ConnectCommandSocket(): Connecting to backend server: 10.0.0.54:6543 (try 1 of 1)
2.
2018-05-11 18:28:14.592341 I MythCoreContext::CheckProtoVersion(): Using protocol version 91 BuzzOff
3. .....
4.
2018-05-11 18:29:12.307678 E MythSocket(7ff0c400b050:48): ReadStringList: Error, timed out after 30000 ms.
5.
2018-05-11 18:29:12.308138 E MythSocket(7ff0c400b050:-1): No response.
6.
2018-05-11 18:29:12.308161 N MythCoreContext::SendReceiveStringList(): Connection to backend server lost
7.
2018-05-11 18:29:12.309207 N MythCoreContext::connectionClosed(): Event socket closed. No connection to the backend.


What does the BE log for the FE connection attempts? Check firewall settings (6543 and 6544) on the BE maybe.
Re: Ubuntu Mythbackend issue [ In reply to ]
On Sat, May 12, 2018, 6:06 AM Mark Perkins <perkins1724@hotmail.com> wrote:

>
>
> On 12/05/18 13:27, Ashu Desai wrote:
>
> having tons of issues with CentOS 7 and it's repository, so spun up an
> Ubuntu 16, installed a backend.
>
> it came up - but had a ton of problem getting the frontend to talk to it.
> Found out that the config.xml changes the password so i had to use that
> goofy password in the "mysql" install.
>
> So when it finally talked from frontend, i thought yipee.
>
> but i am getting these:
>
> https://pastebin.com/Sq8Bp8yc
>
>
> I checked permissions inside and it gets me this:
>
> https://pastebin.com/9ySdTtXD
>
>
> Looks to me like the FE is talking to the database (port 3306) but not the
> backend (port 6543). Is your BE on the same machine / IP as the database?
>

Different machines. x.x.x.54 is my backend, 58 is my FE

no firewall on either.

it's the myth proto error and file permissions that also worry me

>
>
> 1. 2018-05-11 18:28:14.563156 I
> MythCoreContext::ConnectCommandSocket(): Connecting to backend server:
> 10.0.0.54:6543 (try 1 of 1)
> 2. 2018-05-11 18:28:14.592341 I MythCoreContext::CheckProtoVersion():
> Using protocol version 91 BuzzOff
> 3. .....
> 4. 2018-05-11 18:29:12.307678 E MythSocket(7ff0c400b050:48):
> ReadStringList: Error, timed out after 30000 ms.
> 5. 2018-05-11 18:29:12.308138 E MythSocket(7ff0c400b050:-1): No
> response.
> 6. 2018-05-11 18:29:12.308161 N
> MythCoreContext::SendReceiveStringList(): Connection to backend server lost
> 7. 2018-05-11 18:29:12.309207 N MythCoreContext::connectionClosed():
> Event socket closed. No connection to the backend.
>
>
>
> What does the BE log for the FE connection attempts? Check firewall
> settings (6543 and 6544) on the BE maybe.
> _______________________________________________
> 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
>
Re: Ubuntu Mythbackend issue [ In reply to ]
On 12 May 2018 11:16:27 pm Ashu Desai <ashu.desai@gmail.com> wrote:


On Sat, May 12, 2018, 6:06 AM Mark Perkins <perkins1724@hotmail.com<mailto:perkins1724@hotmail.com>> wrote:


On 12/05/18 13:27, Ashu Desai wrote:
having tons of issues with CentOS 7 and it's repository, so spun up an Ubuntu 16, installed a backend.

it came up - but had a ton of problem getting the frontend to talk to it. Found out that the config.xml changes the password so i had to use that goofy password in the "mysql" install.

So when it finally talked from frontend, i thought yipee.

but i am getting these:

https://pastebin.com/Sq8Bp8yc


I checked permissions inside and it gets me this:

https://pastebin.com/9ySdTtXD


Looks to me like the FE is talking to the database (port 3306) but not the backend (port 6543). Is your BE on the same machine / IP as the database?

Different machines. x.x.x.54 is my backend, 58 is my FE

Is the database (server) located on the same server as your BE? The FE is connecting to the database but not the BE. As it appears to me at least.



no firewall on either.

it's the myth proto error and file permissions that also worry me


1.
2018-05-11 18:28:14.563156 I MythCoreContext::ConnectCommandSocket(): Connecting to backend server: 10.0.0.54:6543<http://10.0.0.54:6543> (try 1 of 1)
2.
2018-05-11 18:28:14.592341 I MythCoreContext::CheckProtoVersion(): Using protocol version 91 BuzzOff
3. .....
4.
2018-05-11 18:29:12.307678 E MythSocket(7ff0c400b050:48): ReadStringList: Error, timed out after 30000 ms.
5.
2018-05-11 18:29:12.308138 E MythSocket(7ff0c400b050:-1): No response.
6.
2018-05-11 18:29:12.308161 N MythCoreContext::SendReceiveStringList(): Connection to backend server lost
7.
2018-05-11 18:29:12.309207 N MythCoreContext::connectionClosed(): Event socket closed. No connection to the backend.


What does the BE log for the FE connection attempts? Check firewall settings (6543 and 6544) on the BE maybe.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org<mailto: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
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org<mailto:mythtv-users%40mythtv.org>
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Ubuntu Mythbackend issue [ In reply to ]
On Sun, May 13, 2018 at 7:34 AM Mark Perkins <perkins1724@hotmail.com>
wrote:

>
>
> On 12 May 2018 11:16:27 pm Ashu Desai <ashu.desai@gmail.com> wrote:
>
>>
>>
>> On Sat, May 12, 2018, 6:06 AM Mark Perkins <perkins1724@hotmail.com>
>> wrote:
>>
>>>
>>>
>>> On 12/05/18 13:27, Ashu Desai wrote:
>>>
>>> having tons of issues with CentOS 7 and it's repository, so spun up an
>>> Ubuntu 16, installed a backend.
>>>
>>> it came up - but had a ton of problem getting the frontend to talk to
>>> it. Found out that the config.xml changes the password so i had to use that
>>> goofy password in the "mysql" install.
>>>
>>> So when it finally talked from frontend, i thought yipee.
>>>
>>> but i am getting these:
>>>
>>> https://pastebin.com/Sq8Bp8yc
>>>
>>>
>>> I checked permissions inside and it gets me this:
>>>
>>> https://pastebin.com/9ySdTtXD
>>>
>>>
>>> Looks to me like the FE is talking to the database (port 3306) but not
>>> the backend (port 6543). Is your BE on the same machine / IP as the
>>> database?
>>>
>>
>> Different machines. x.x.x.54 is my backend, 58 is my FE
>>
>
> Is the database (server) located on the same server as your BE? The FE is
> connecting to the database but not the BE. As it appears to me at least.
>

Yes, the mysql is on the Ubuntu BE, and the FE is trying to access it. The
weird part is, it works on and off - i think it works every time I try to
do a "chmod 775" on the backend but i think with a rescan it gets messed
up.



>
>
>
>> no firewall on either.
>>
>> it's the myth proto error and file permissions that also worry me
>>
>>>
>>>
>>> 1. 2018-05-11 18:28:14.563156 I
>>> MythCoreContext::ConnectCommandSocket(): Connecting to backend server:
>>> 10.0.0.54:6543 (try 1 of 1)
>>> 2. 2018-05-11 18:28:14.592341 I
>>> MythCoreContext::CheckProtoVersion(): Using protocol version 91 BuzzOff
>>> 3. .....
>>> 4. 2018-05-11 18:29:12.307678 E MythSocket(7ff0c400b050:48):
>>> ReadStringList: Error, timed out after 30000 ms.
>>> 5. 2018-05-11 18:29:12.308138 E MythSocket(7ff0c400b050:-1): No
>>> response.
>>> 6. 2018-05-11 18:29:12.308161 N
>>> MythCoreContext::SendReceiveStringList(): Connection to backend server lost
>>> 7. 2018-05-11 18:29:12.309207 N
>>> MythCoreContext::connectionClosed(): Event socket closed. No connection
>>> to the backend.
>>>
>>>
>>>
>>> What does the BE log for the FE connection attempts? Check firewall
>>> settings (6543 and 6544) on the BE maybe.
>>>
>>>
Here's what the backend logs:

https://pastebin.com/yrAsWNeZ

I see "can't write to" issue and some "AutoExpire: CalcParams(): Max
required Free Space: 1.0 GB w/freq: 15 min" thing which when I search seems
to be some TV Tuner issue

I somehow have this feeling its a file permission thing. Every time I do a
"chown" or "chmod" - it converts my nfs shared folders to the following:

myth@ScorpioOne:~$ ls -ahl /usr/local/media/
total 208K
drwxrwsr-x 9 nobody 4294967294 91 May 7 01:07 .
drwxr-xr-x 11 root root 127 May 11 14:24 ..
drwxrwsr-x 4 root mythtv 35 May 2 08:43 Data
drwxrwsr-x 2 root mythtv 6 May 7 01:07 live-tv
drwxrwsr-x 2 nobody 4294967294 128K May 12 23:11 metadata
drwxrwsr-x 185 nobody 4294967294 20K May 12 23:11 Music
drwxrwsr-x 103 nobody 4294967294 4.0K Jan 1 09:26 Pics
drwxrwsr-x 4 root mythtv 38 May 7 01:34 TV
drwxrwsr-x 8 root mythtv 108 Apr 13 12:47 Videos

ls -ahl /usr/local/media/metadata/

-rwxrwxr-x 1 nobody 4294967294 171K Apr 18 08:34
tmdb3.py_97449_coverart.jpg
-rwxrwxr-x 1 nobody 4294967294 11K Apr 24 12:04
tmdb3.py_97449_coverart.jpg.200x0.jpg
-rwxrwxr-x 1 nobody 4294967294 254K Apr 22 15:05 tmdb3.py_9759_coverart.jpg
-rwxrwxr-x 1 nobody 4294967294 12K Apr 23 15:53
tmdb3.py_9759_coverart.jpg.200x0.jpg
-rwxrwxr-x 1 nobody 4294967294 268K Apr 22 15:05 tmdb3.py_9759_fanart.jpg
-rwxrwxr-x 1 nobody 4294967294 282K Apr 29 17:49 tmdb3.py_9778_coverart.jpg
-rwxrwxr-x 1 nobody 4294967294 11K May 9 17:35
tmdb3.py_9778_coverart.jpg.200x0.jpg
-rwxrwxr-x 1 nobody 4294967294 57K Apr 29 17:49 tmdb3.py_9778_fanart.jpg
-rwxrwxr-x 1 nobody 4294967294 78K Apr 29 19:48 tmdb3.py_97_coverart.jpg
-rwxrwxr-x 1 nobody 4294967294 7.1K May 12 10:59
tmdb3.py_97_coverart.jpg.200x0.jpg
-rwxrwxr-x 1 nobody 4294967294 310K Apr 29 19:48 tmdb3.py_97_fanart.jpg
-rwxrwxr-x 1 nobody 4294967294 346K May 1 13:45 tmdb3.py_9802_coverart.jpg
-rwxrwxr-x 1 nobody 4294967294 564K May 1 13:46 tmdb3.py_9802_fanart.jpg
-rwxrwxr-x 1 nobody 4294967294 137K Apr 28 21:37 tmdb3.py_9820_coverart.jpg
-rwxrwxr-x 1 nobody 4294967294 251K Apr 28 21:37 tmdb3.py_9820_fanart.jpg
-rwxrwxr-x 1 nobody 4294967294 1.5M May 1 14:16 tmdb3.py_9869_coverart.jpg
-rwxrwxr-x 1 nobody 4294967294 568K May 1 14:16 tmdb3.py_9869_fanart.jpg
-rwxrwxr-x 1 nobody 4294967294 279K Apr 27 17:43 tmdb3.py_9880_coverart.jpg
-rwxrwxr-x 1 nobody 4294967294 248K Apr 27 17:43 tmdb3.py_9880_fanart.jpg
-rwxrwxr-x 1 nobody 4294967294 244K Apr 29 17:58 tmdb3.py_9913_coverart.jpg
-rwxrwxr-x 1 nobody 4294967294 371K Apr 29 17:58 tmdb3.py_9913_fanart.jpg
-rwxrwxr-x 1 nobody 4294967294 114K Apr 18 10:18 tmdb3.py_9919_coverart.jpg
-rwxrwxr-x 1 nobody 4294967294 8.6K Apr 23 15:53
tmdb3.py_9919_coverart.jpg.200x0.jpg
Re: Ubuntu Mythbackend issue [ In reply to ]
All of your storage directories (/usr/local/media/*) must be writable by
the user which the backend is running as.
Running mythtv-setup usually tests this when the storage groups are set up.

All of my storage directories are owner=mythtv, group=mythtv and for mythtv
to work you need to run something like "sudo chown -R mythtv.mythtv
/usr/local/media/*"

a) You must satisfy yourself that doing this meets your own security needs
and
(b) Realise that changing these permissions may "break" access to your
media from other applications or devices



On 13 May 2018 at 16:47, Ashu Desai <ashu.desai@gmail.com> wrote:

>
>
> On Sun, May 13, 2018 at 7:34 AM Mark Perkins <perkins1724@hotmail.com>
> wrote:
>
>>
>>
>> On 12 May 2018 11:16:27 pm Ashu Desai <ashu.desai@gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, May 12, 2018, 6:06 AM Mark Perkins <perkins1724@hotmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 12/05/18 13:27, Ashu Desai wrote:
>>>>
>>>> having tons of issues with CentOS 7 and it's repository, so spun up an
>>>> Ubuntu 16, installed a backend.
>>>>
>>>> it came up - but had a ton of problem getting the frontend to talk to
>>>> it. Found out that the config.xml changes the password so i had to use that
>>>> goofy password in the "mysql" install.
>>>>
>>>> So when it finally talked from frontend, i thought yipee.
>>>>
>>>> but i am getting these:
>>>>
>>>> https://pastebin.com/Sq8Bp8yc
>>>>
>>>>
>>>> I checked permissions inside and it gets me this:
>>>>
>>>> https://pastebin.com/9ySdTtXD
>>>>
>>>>
>>>> Looks to me like the FE is talking to the database (port 3306) but not
>>>> the backend (port 6543). Is your BE on the same machine / IP as the
>>>> database?
>>>>
>>>
>>> Different machines. x.x.x.54 is my backend, 58 is my FE
>>>
>>
>> Is the database (server) located on the same server as your BE? The FE is
>> connecting to the database but not the BE. As it appears to me at least.
>>
>
> Yes, the mysql is on the Ubuntu BE, and the FE is trying to access it. The
> weird part is, it works on and off - i think it works every time I try to
> do a "chmod 775" on the backend but i think with a rescan it gets messed
> up.
>
>
>
>>
>>
>>
>>> no firewall on either.
>>>
>>> it's the myth proto error and file permissions that also worry me
>>>
>>>>
>>>>
>>>> 1. 2018-05-11 18:28:14.563156 I MythCoreContext::ConnectCommandSocket():
>>>> Connecting to backend server: 10.0.0.54:6543 (try 1 of 1)
>>>> 2. 2018-05-11 18:28:14.592341 I MythCoreContext::CheckProtoVersion():
>>>> Using protocol version 91 BuzzOff
>>>> 3. .....
>>>> 4. 2018-05-11 18:29:12.307678 E MythSocket(7ff0c400b050:48):
>>>> ReadStringList: Error, timed out after 30000 ms.
>>>> 5. 2018-05-11 18:29:12.308138 E MythSocket(7ff0c400b050:-1): No
>>>> response.
>>>> 6. 2018-05-11 18:29:12.308161 N MythCoreContext::SendReceiveStringList():
>>>> Connection to backend server lost
>>>> 7. 2018-05-11 18:29:12.309207 N MythCoreContext::connectionClosed():
>>>> Event socket closed. No connection to the backend.
>>>>
>>>>
>>>>
>>>> What does the BE log for the FE connection attempts? Check firewall
>>>> settings (6543 and 6544) on the BE maybe.
>>>>
>>>>
> Here's what the backend logs:
>
> https://pastebin.com/yrAsWNeZ
>
> I see "can't write to" issue and some "AutoExpire: CalcParams(): Max
> required Free Space: 1.0 GB w/freq: 15 min" thing which when I search seems
> to be some TV Tuner issue
>
> I somehow have this feeling its a file permission thing. Every time I do a
> "chown" or "chmod" - it converts my nfs shared folders to the following:
>
> myth@ScorpioOne:~$ ls -ahl /usr/local/media/
> total 208K
> drwxrwsr-x 9 nobody 4294967294 91 May 7 01:07 .
> drwxr-xr-x 11 root root 127 May 11 14:24 ..
> drwxrwsr-x 4 root mythtv 35 May 2 08:43 Data
> drwxrwsr-x 2 root mythtv 6 May 7 01:07 live-tv
> drwxrwsr-x 2 nobody 4294967294 128K May 12 23:11 metadata
> drwxrwsr-x 185 nobody 4294967294 20K May 12 23:11 Music
> drwxrwsr-x 103 nobody 4294967294 4.0K Jan 1 09:26 Pics
> drwxrwsr-x 4 root mythtv 38 May 7 01:34 TV
> drwxrwsr-x 8 root mythtv 108 Apr 13 12:47 Videos
>
> ls -ahl /usr/local/media/metadata/
>
> -rwxrwxr-x 1 nobody 4294967294 171K Apr 18 08:34
> tmdb3.py_97449_coverart.jpg
> -rwxrwxr-x 1 nobody 4294967294 11K Apr 24 12:04
> tmdb3.py_97449_coverart.jpg.200x0.jpg
> -rwxrwxr-x 1 nobody 4294967294 254K Apr 22 15:05
> tmdb3.py_9759_coverart.jpg
> -rwxrwxr-x 1 nobody 4294967294 12K Apr 23 15:53
> tmdb3.py_9759_coverart.jpg.200x0.jpg
> -rwxrwxr-x 1 nobody 4294967294 268K Apr 22 15:05 tmdb3.py_9759_fanart.jpg
> -rwxrwxr-x 1 nobody 4294967294 282K Apr 29 17:49
> tmdb3.py_9778_coverart.jpg
> -rwxrwxr-x 1 nobody 4294967294 11K May 9 17:35
> tmdb3.py_9778_coverart.jpg.200x0.jpg
> -rwxrwxr-x 1 nobody 4294967294 57K Apr 29 17:49 tmdb3.py_9778_fanart.jpg
> -rwxrwxr-x 1 nobody 4294967294 78K Apr 29 19:48 tmdb3.py_97_coverart.jpg
> -rwxrwxr-x 1 nobody 4294967294 7.1K May 12 10:59 tmdb3.py_97_coverart.jpg.
> 200x0.jpg
> -rwxrwxr-x 1 nobody 4294967294 310K Apr 29 19:48 tmdb3.py_97_fanart.jpg
> -rwxrwxr-x 1 nobody 4294967294 346K May 1 13:45
> tmdb3.py_9802_coverart.jpg
> -rwxrwxr-x 1 nobody 4294967294 564K May 1 13:46 tmdb3.py_9802_fanart.jpg
> -rwxrwxr-x 1 nobody 4294967294 137K Apr 28 21:37
> tmdb3.py_9820_coverart.jpg
> -rwxrwxr-x 1 nobody 4294967294 251K Apr 28 21:37 tmdb3.py_9820_fanart.jpg
> -rwxrwxr-x 1 nobody 4294967294 1.5M May 1 14:16
> tmdb3.py_9869_coverart.jpg
> -rwxrwxr-x 1 nobody 4294967294 568K May 1 14:16 tmdb3.py_9869_fanart.jpg
> -rwxrwxr-x 1 nobody 4294967294 279K Apr 27 17:43
> tmdb3.py_9880_coverart.jpg
> -rwxrwxr-x 1 nobody 4294967294 248K Apr 27 17:43 tmdb3.py_9880_fanart.jpg
> -rwxrwxr-x 1 nobody 4294967294 244K Apr 29 17:58
> tmdb3.py_9913_coverart.jpg
> -rwxrwxr-x 1 nobody 4294967294 371K Apr 29 17:58 tmdb3.py_9913_fanart.jpg
> -rwxrwxr-x 1 nobody 4294967294 114K Apr 18 10:18
> tmdb3.py_9919_coverart.jpg
> -rwxrwxr-x 1 nobody 4294967294 8.6K Apr 23 15:53
> tmdb3.py_9919_coverart.jpg.200x0.jpg
>
>
>
> _______________________________________________
> 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
>
>
Re: Ubuntu Mythbackend issue [ In reply to ]
On Sun, 13 May 2018 10:47:45 -0500, you wrote:

>I see "can't write to" issue and some "AutoExpire: CalcParams(): Max
>required Free Space: 1.0 GB w/freq: 15 min" thing which when I search seems
>to be some TV Tuner issue

You can ignore the "Autoexpire:" messages - they are normal. It just
means that mythbackend has looked at all the storage groups and
checked that they have enough free space. If they do not, it will
choose some recordings to expire to create enough free space. Always
make sure your storage groups have enough free space unless you want
old recordings to expire. I leave a minimum of 20 Gibytes free at all
times.

The "can't write to" messages come about by mythbackend writing a zero
length file ".test" to each storage group directory on startup. If it
fails to create the file, or fails to be able to delete it, it will
give the "can't write to" message and will not use that storage group
directory for writing until the next time it is started.

So, first, take a look and see if your storage group directories
contain .test files, and what their ownership and permissions look
like. Then manually delete them if they are there. If you have had a
permissions problem that has caused the .test files to be left behind
undeleted, then I think the test fails on creating new ones, hence the
need to manually delete them after you fix the permissions.

Then, try creating the .test files yourself as the user that
mythbackend runs as (mythtv). Log in as root and do this:

su - mythtv -c touch "<storage group path>/.test"

And try deleting them again:

su - mythtv -c "rm <storage group path>/.test"

If either command does not work, then you need to fix the ownership
and permissions until it does work.
_______________________________________________
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
Re: Ubuntu Mythbackend issue [ In reply to ]
On Sun, May 13, 2018 at 11:55 AM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Sun, 13 May 2018 10:47:45 -0500, you wrote:
>
> >I see "can't write to" issue and some "AutoExpire: CalcParams(): Max
> >required Free Space: 1.0 GB w/freq: 15 min" thing which when I search
> seems
> >to be some TV Tuner issue
>
> You can ignore the "Autoexpire:" messages - they are normal. It just
> means that mythbackend has looked at all the storage groups and
> checked that they have enough free space. If they do not, it will
> choose some recordings to expire to create enough free space. Always
> make sure your storage groups have enough free space unless you want
> old recordings to expire. I leave a minimum of 20 Gibytes free at all
> times.
>
> The "can't write to" messages come about by mythbackend writing a zero
> length file ".test" to each storage group directory on startup. If it
> fails to create the file, or fails to be able to delete it, it will
> give the "can't write to" message and will not use that storage group
> directory for writing until the next time it is started.
>
> So, first, take a look and see if your storage group directories
> contain .test files, and what their ownership and permissions look
> like. Then manually delete them if they are there. If you have had a
> permissions problem that has caused the .test files to be left behind
> undeleted, then I think the test fails on creating new ones, hence the
> need to manually delete them after you fix the permissions.
>
> Then, try creating the .test files yourself as the user that
> mythbackend runs as (mythtv). Log in as root and do this:
>
> su - mythtv -c touch "<storage group path>/.test"
>
> And try deleting them again:
>
> su - mythtv -c "rm <storage group path>/.test"
>
> If either command does not work, then you need to fix the ownership
> and permissions until it does work.


so i am slightly confused. Here's what I have:

BE user - myth (no "tv"), mythconverg user: mythtv
FE user - mythtv

In ubuntu BE, i don't have "root". so i always log in as "myth" and when I
do, it let's me do the touch and rm the .test

When we test permissions, do we test the "mythtv" because the FE as well as
the DB user is "mythtv" or do we test "myth" because that's the BE user?

I gather the DB user "mythtv" comes in play later once FE talks to the BE,
but the file permissions AND ownership is what confuses me.

My share "/usr/local/media/metadata" is currently showing as

myth@ScorpioOne:~$ ls -ahl /usr/local/media/
total 208K
drwxrwsr-x 9 nobody 4294967294 91 May 7 01:07 .
drwxr-xr-x 11 root root 127 May 11 14:24 ..
drwxrwsr-x 4 root mythtv 35 May 2 08:43 Data
drwxrwsr-x 2 root mythtv 6 May 7 01:07 live-tv
drwxrwsr-x 2 nobody 4294967294 128K May 13 2018 metadata
drwxrwsr-x 185 nobody 4294967294 20K May 12 23:11 Music
drwxrwsr-x 103 nobody 4294967294 4.0K Jan 1 09:26 Pics
drwxrwsr-x 4 root mythtv 38 May 7 01:34 TV
drwxrwsr-x 8 root mythtv 108 Apr 13 12:47 Videos
Re: Ubuntu Mythbackend issue [ In reply to ]
On Sun, 13 May 2018 18:56:42 -0500, you wrote:

>On Sun, May 13, 2018 at 11:55 AM Stephen Worthington <
>stephen_agent@jsw.gen.nz> wrote:
>
>> On Sun, 13 May 2018 10:47:45 -0500, you wrote:
>>
>> >I see "can't write to" issue and some "AutoExpire: CalcParams(): Max
>> >required Free Space: 1.0 GB w/freq: 15 min" thing which when I search
>> seems
>> >to be some TV Tuner issue
>>
>> You can ignore the "Autoexpire:" messages - they are normal. It just
>> means that mythbackend has looked at all the storage groups and
>> checked that they have enough free space. If they do not, it will
>> choose some recordings to expire to create enough free space. Always
>> make sure your storage groups have enough free space unless you want
>> old recordings to expire. I leave a minimum of 20 Gibytes free at all
>> times.
>>
>> The "can't write to" messages come about by mythbackend writing a zero
>> length file ".test" to each storage group directory on startup. If it
>> fails to create the file, or fails to be able to delete it, it will
>> give the "can't write to" message and will not use that storage group
>> directory for writing until the next time it is started.
>>
>> So, first, take a look and see if your storage group directories
>> contain .test files, and what their ownership and permissions look
>> like. Then manually delete them if they are there. If you have had a
>> permissions problem that has caused the .test files to be left behind
>> undeleted, then I think the test fails on creating new ones, hence the
>> need to manually delete them after you fix the permissions.
>>
>> Then, try creating the .test files yourself as the user that
>> mythbackend runs as (mythtv). Log in as root and do this:
>>
>> su - mythtv -c touch "<storage group path>/.test"
>>
>> And try deleting them again:
>>
>> su - mythtv -c "rm <storage group path>/.test"
>>
>> If either command does not work, then you need to fix the ownership
>> and permissions until it does work.
>
>
>so i am slightly confused. Here's what I have:
>
>BE user - myth (no "tv"), mythconverg user: mythtv
>FE user - mythtv
>
>In ubuntu BE, i don't have "root". so i always log in as "myth" and when I
>do, it let's me do the touch and rm the .test

So does the backend user "mythtv" exist and have "mythtv" group? That
is important. So what does this command show:

su - mythtv -c "groups"

This is what I get:

root@mypvr:~# su - mythtv -c "groups"
mythtv dialout cdrom audio video

I am not sure why it has "dialout", but the other groups are
important.

>When we test permissions, do we test the "mythtv" because the FE as well as
>the DB user is "mythtv" or do we test "myth" because that's the BE user?

Mythbackend runs as user mythtv on the backend box. Mythfrontend runs
as whatever user you run your desktop under on the frontend box. Both
of those users normally have "mythtv" as an additional group on their
respective boxes. The group IDs of the "mythtv" groups on the two
different boxes will not usually be the same, hence the are not the
same group.

>I gather the DB user "mythtv" comes in play later once FE talks to the BE,
>but the file permissions AND ownership is what confuses me.
>
>My share "/usr/local/media/metadata" is currently showing as
>
>myth@ScorpioOne:~$ ls -ahl /usr/local/media/
>total 208K
>drwxrwsr-x 9 nobody 4294967294 91 May 7 01:07 .
>drwxr-xr-x 11 root root 127 May 11 14:24 ..
>drwxrwsr-x 4 root mythtv 35 May 2 08:43 Data
>drwxrwsr-x 2 root mythtv 6 May 7 01:07 live-tv
>drwxrwsr-x 2 nobody 4294967294 128K May 13 2018 metadata
>drwxrwsr-x 185 nobody 4294967294 20K May 12 23:11 Music
>drwxrwsr-x 103 nobody 4294967294 4.0K Jan 1 09:26 Pics
>drwxrwsr-x 4 root mythtv 38 May 7 01:34 TV
>drwxrwsr-x 8 root mythtv 108 Apr 13 12:47 Videos

For storage groups, the ownership and permissions of the mythbackend
user on the backend box are what matters. Mythbackend normally runs
as user "mythtv" and group "mythtv" in Ubuntu. Mythfrontend talks to
mythbackend for access to the storage group files, so for access to
the recordings, its ownership and permissions do not matter as all
that traffic happens over TCP/IP connections between mythbackend and
mythfrontend. The normal setup for any storage group directory that
mythbackend has to access is to be ownership mythtv:mythtv with user
and group access both set to execute (=directory access), read and
write (chmod u=xrw,g=xrw).

However, it is possible to access things other than through storage
groups. Both mythmusic (which is a plugin that runs entirely in
mythfrontend) and mythvideo (which is a builtin part of mythfrontend)
have settings for paths they can use to directly access things via the
normal access paths of the frontend box they are running on. These
paths are in addition to the storage group settings they also have. So
it depends on how you have them set up - if you have them access
things via their storage groups, then the same rules apply as for any
storage group - access is via mythbackend and the ownership and
permissions of mythbackend are what matter, and access happens from
the backend box. But if you are using the local system paths, access
to things via those paths uses mythfrontend's ownership and
permissions, and happens from the frontend box. The local paths are
also different for each frontend - the frontend settings are stored in
the "settings" table with a different hostname field value for each
frontend. So each frontend can access the videos or music in the
storage groups via the backend, and also potentially different videos
and music stored locally via the frontend.

I think mythgallery and its replacement (mythimage?) work the same way
as mythmusic and mythvideo.

Storage directories are set up in mythtv-setup on the backend box. The
local directories for a frontend are set up in mythfrontend on each
frontend box.

So, I find your /usr/local/media ownership a bit strange. For a
start, the listing shows that the metadata, Music and Pics directories
have an unknown group (group ID 4294967294). That normally only
happens if they are network mounted from a different PC, where the
group IDs and user IDs do not match those on the local PC. If they
were local they would normally have been created using existing local
users and groups and would be displayed with the name rather than a
number. Is that what is going on? That really can cause problems!
And having your recording directories mounted on other boxes means
that the bandwidth to them is limited by the Ethernet connection to
the other boxes, and that can cause failed recordings when the traffic
is too large.

And even more strange is that the /usr/local/media/ directory itself
is nobody:4294967294. So is that directory a network mount on a
different box?

The other directories (Data, live-tv, TV and Videos) all have root
ownership. That is not necessarily fatal, as they do have mythtv
group ownership, but it is not normal. They ought to be mythtv user
ownership.

And all the files under the storage group directories also should be
mythtv:mythtv ownership.

It would also be a good idea to check that mythbackend is running as
user mythtv. Is this something like what "ps -ef | grep mythba" shows
for you?

root@mypvr:~# ps -ef | grep mythba
mythtv 3480 1 8 May11 ? 06:22:36 /usr/bin/mythbackend
--quiet --syslog local7 -v record,dvbcam
root 18746 7172 0 14:39 pts/2 00:00:00 grep --color=auto
mythba
_______________________________________________
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
Re: Ubuntu Mythbackend issue [ In reply to ]
On Sun, May 13, 2018 at 10:06 PM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Sun, 13 May 2018 18:56:42 -0500, you wrote:
>
> >On Sun, May 13, 2018 at 11:55 AM Stephen Worthington <
> >stephen_agent@jsw.gen.nz> wrote:
> >
> >> On Sun, 13 May 2018 10:47:45 -0500, you wrote:
> >>
> >> >I see "can't write to" issue and some "AutoExpire: CalcParams(): Max
> >> >required Free Space: 1.0 GB w/freq: 15 min" thing which when I search
> >> seems
> >> >to be some TV Tuner issue
> >>
> >> You can ignore the "Autoexpire:" messages - they are normal. It just
> >> means that mythbackend has looked at all the storage groups and
> >> checked that they have enough free space. If they do not, it will
> >> choose some recordings to expire to create enough free space. Always
> >> make sure your storage groups have enough free space unless you want
> >> old recordings to expire. I leave a minimum of 20 Gibytes free at all
> >> times.
> >>
> >> The "can't write to" messages come about by mythbackend writing a zero
> >> length file ".test" to each storage group directory on startup. If it
> >> fails to create the file, or fails to be able to delete it, it will
> >> give the "can't write to" message and will not use that storage group
> >> directory for writing until the next time it is started.
> >>
> >> So, first, take a look and see if your storage group directories
> >> contain .test files, and what their ownership and permissions look
> >> like. Then manually delete them if they are there. If you have had a
> >> permissions problem that has caused the .test files to be left behind
> >> undeleted, then I think the test fails on creating new ones, hence the
> >> need to manually delete them after you fix the permissions.
> >>
> >> Then, try creating the .test files yourself as the user that
> >> mythbackend runs as (mythtv). Log in as root and do this:
> >>
> >> su - mythtv -c touch "<storage group path>/.test"
> >>
> >> And try deleting them again:
> >>
> >> su - mythtv -c "rm <storage group path>/.test"
> >>
> >> If either command does not work, then you need to fix the ownership
> >> and permissions until it does work.
> >
> >
> >so i am slightly confused. Here's what I have:
> >
> >BE user - myth (no "tv"), mythconverg user: mythtv
> >FE user - mythtv
> >
> >In ubuntu BE, i don't have "root". so i always log in as "myth" and when I
> >do, it let's me do the touch and rm the .test
>
> So does the backend user "mythtv" exist and have "mythtv" group? That
> is important. So what does this command show:
>
> su - mythtv -c "groups"
>
> This is what I get:
>
> root@mypvr:~# su - mythtv -c "groups"
> mythtv dialout cdrom audio video
>

I don't know the password for username "mythtv"
During installation, I tried to name my user as "mythtv" for consistency
sake, but Ubuntu didn't allow me saying it's reserved so I had to create
"myth" as a user

I do get mythtv as a username - quick search gave me a command:

myth@ScorpioOne:~$ cut -d: -f1 /etc/passwd
root
daemon
bin
sys
sync
games
man
lp
mail
news
uucp
proxy
www-data
backup
list
irc
gnats
nobody
systemd-timesync
systemd-network
systemd-resolve
systemd-bus-proxy
syslog
_apt
messagebus
uuidd
lightdm
whoopsie
avahi-autoipd
avahi
dnsmasq
colord
speech-dispatcher
hplip
kernoops
pulse
rtkit
saned
usbmux
myth
mysql
ntp
mythtv
sshd
vboxadd
statd



>
> I am not sure why it has "dialout", but the other groups are
> important.
>
> >When we test permissions, do we test the "mythtv" because the FE as well
> as
> >the DB user is "mythtv" or do we test "myth" because that's the BE user?
>
> Mythbackend runs as user mythtv on the backend box. Mythfrontend runs
> as whatever user you run your desktop under on the frontend box. Both
> of those users normally have "mythtv" as an additional group on their
> respective boxes. The group IDs of the "mythtv" groups on the two
> different boxes will not usually be the same, hence the are not the
> same group.
>
> >I gather the DB user "mythtv" comes in play later once FE talks to the BE,
> >but the file permissions AND ownership is what confuses me.
> >
> >My share "/usr/local/media/metadata" is currently showing as
> >
> >myth@ScorpioOne:~$ ls -ahl /usr/local/media/
> >total 208K
> >drwxrwsr-x 9 nobody 4294967294 91 May 7 01:07 .
> >drwxr-xr-x 11 root root 127 May 11 14:24 ..
> >drwxrwsr-x 4 root mythtv 35 May 2 08:43 Data
> >drwxrwsr-x 2 root mythtv 6 May 7 01:07 live-tv
> >drwxrwsr-x 2 nobody 4294967294 128K May 13 2018 metadata
> >drwxrwsr-x 185 nobody 4294967294 20K May 12 23:11 Music
> >drwxrwsr-x 103 nobody 4294967294 4.0K Jan 1 09:26 Pics
> >drwxrwsr-x 4 root mythtv 38 May 7 01:34 TV
> >drwxrwsr-x 8 root mythtv 108 Apr 13 12:47 Videos
>
> For storage groups, the ownership and permissions of the mythbackend
> user on the backend box are what matters. Mythbackend normally runs
> as user "mythtv" and group "mythtv" in Ubuntu. Mythfrontend talks to
> mythbackend for access to the storage group files, so for access to
> the recordings, its ownership and permissions do not matter as all
> that traffic happens over TCP/IP connections between mythbackend and
> mythfrontend. The normal setup for any storage group directory that
> mythbackend has to access is to be ownership mythtv:mythtv with user
> and group access both set to execute (=directory access), read and
> write (chmod u=xrw,g=xrw).
>
> However, it is possible to access things other than through storage
> groups. Both mythmusic (which is a plugin that runs entirely in
> mythfrontend) and mythvideo (which is a builtin part of mythfrontend)
> have settings for paths they can use to directly access things via the
> normal access paths of the frontend box they are running on. These
> paths are in addition to the storage group settings they also have. So
> it depends on how you have them set up - if you have them access
> things via their storage groups, then the same rules apply as for any
> storage group - access is via mythbackend and the ownership and
> permissions of mythbackend are what matter, and access happens from
> the backend box. But if you are using the local system paths, access
> to things via those paths uses mythfrontend's ownership and
> permissions, and happens from the frontend box. The local paths are
> also different for each frontend - the frontend settings are stored in
> the "settings" table with a different hostname field value for each
> frontend. So each frontend can access the videos or music in the
> storage groups via the backend, and also potentially different videos
> and music stored locally via the frontend.
>
> I think mythgallery and its replacement (mythimage?) work the same way
> as mythmusic and mythvideo.
>
> Storage directories are set up in mythtv-setup on the backend box. The
> local directories for a frontend are set up in mythfrontend on each
> frontend box.
>
> So, I find your /usr/local/media ownership a bit strange. For a
> start, the listing shows that the metadata, Music and Pics directories
> have an unknown group (group ID 4294967294). That normally only
> happens if they are network mounted from a different PC, where the
> group IDs and user IDs do not match those on the local PC.


You are correct - sorry I thought i had mentioned earlier - these are NFS
storage.


> If they
> were local they would normally have been created using existing local
> users and groups and would be displayed with the name rather than a
> number. Is that what is going on? That really can cause problems!
> And having your recording directories mounted on other boxes means
> that the bandwidth to them is limited by the Ethernet connection to
> the other boxes, and that can cause failed recordings when the traffic
> is too large.
>

I have a gig ethernet connection to the boxes, both at my home.


>
> And even more strange is that the /usr/local/media/ directory itself
> is nobody:4294967294. So is that directory a network mount on a
> different box?
>

Yes the storage are NFS mounted for everything

- Video
- TV
- metadata
- Music
- Pics
- live-tv


> The other directories (Data, live-tv, TV and Videos) all have root
> ownership. That is not necessarily fatal, as they do have mythtv
> group ownership, but it is not normal. They ought to be mythtv user
> ownership.
>
> And all the files under the storage group directories also should be
> mythtv:mythtv ownership.
>
> It would also be a good idea to check that mythbackend is running as
> user mythtv. Is this something like what "ps -ef | grep mythba" shows
> for you?
>
> root@mypvr:~# ps -ef | grep mythba
> mythtv 3480 1 8 May11 ? 06:22:36 /usr/bin/mythbackend
> --quiet --syslog local7 -v record,dvbcam
> root 18746 7172 0 14:39 pts/2 00:00:00 grep --color=auto
> mythba
>

This is what it shows for me:

myth@ScorpioOne:~$ ps -ef | grep mythba
myth 4668 2188 0 23:29 pts/18 00:00:00 grep --color=auto mythba
mythtv 25292 1 0 May12 ? 00:06:01 /usr/bin/mythbackend
--quiet --syslog local7
Re: Ubuntu Mythbackend issue [ In reply to ]
On Sun, 13 May 2018 23:29:49 -0500, you wrote:

>On Sun, May 13, 2018 at 10:06 PM Stephen Worthington <
>stephen_agent@jsw.gen.nz> wrote:
>
>> On Sun, 13 May 2018 18:56:42 -0500, you wrote:
>>
>> >On Sun, May 13, 2018 at 11:55 AM Stephen Worthington <
>> >stephen_agent@jsw.gen.nz> wrote:
>> >
>> >> On Sun, 13 May 2018 10:47:45 -0500, you wrote:
>> >>
>> >> >I see "can't write to" issue and some "AutoExpire: CalcParams(): Max
>> >> >required Free Space: 1.0 GB w/freq: 15 min" thing which when I search
>> >> seems
>> >> >to be some TV Tuner issue
>> >>
>> >> You can ignore the "Autoexpire:" messages - they are normal. It just
>> >> means that mythbackend has looked at all the storage groups and
>> >> checked that they have enough free space. If they do not, it will
>> >> choose some recordings to expire to create enough free space. Always
>> >> make sure your storage groups have enough free space unless you want
>> >> old recordings to expire. I leave a minimum of 20 Gibytes free at all
>> >> times.
>> >>
>> >> The "can't write to" messages come about by mythbackend writing a zero
>> >> length file ".test" to each storage group directory on startup. If it
>> >> fails to create the file, or fails to be able to delete it, it will
>> >> give the "can't write to" message and will not use that storage group
>> >> directory for writing until the next time it is started.
>> >>
>> >> So, first, take a look and see if your storage group directories
>> >> contain .test files, and what their ownership and permissions look
>> >> like. Then manually delete them if they are there. If you have had a
>> >> permissions problem that has caused the .test files to be left behind
>> >> undeleted, then I think the test fails on creating new ones, hence the
>> >> need to manually delete them after you fix the permissions.
>> >>
>> >> Then, try creating the .test files yourself as the user that
>> >> mythbackend runs as (mythtv). Log in as root and do this:
>> >>
>> >> su - mythtv -c touch "<storage group path>/.test"
>> >>
>> >> And try deleting them again:
>> >>
>> >> su - mythtv -c "rm <storage group path>/.test"
>> >>
>> >> If either command does not work, then you need to fix the ownership
>> >> and permissions until it does work.
>> >
>> >
>> >so i am slightly confused. Here's what I have:
>> >
>> >BE user - myth (no "tv"), mythconverg user: mythtv
>> >FE user - mythtv
>> >
>> >In ubuntu BE, i don't have "root". so i always log in as "myth" and when I
>> >do, it let's me do the touch and rm the .test
>>
>> So does the backend user "mythtv" exist and have "mythtv" group? That
>> is important. So what does this command show:
>>
>> su - mythtv -c "groups"
>>
>> This is what I get:
>>
>> root@mypvr:~# su - mythtv -c "groups"
>> mythtv dialout cdrom audio video
>>
>
>I don't know the password for username "mythtv"
>During installation, I tried to name my user as "mythtv" for consistency
>sake, but Ubuntu didn't allow me saying it's reserved so I had to create
>"myth" as a user

It is quite likely that the "mythtv" user does not have a password. It
is possible for package installers to create a user without a
password, and the "mythtv" user is created by the packages. The
normal way to access such a user is via su or sudo (or root). Using a
different name for your username on the backend box was the correct
thing to do. The "myth" user should be a member of the "mythtv"
group, but it will be a normal user capable of running a desktop and
running mythtv-setup and mythfrontend.

>I do get mythtv as a username - quick search gave me a command:
>
>myth@ScorpioOne:~$ cut -d: -f1 /etc/passwd
>root
>daemon
>bin
>sys
>sync
>games
>man
>lp
>mail
>news
>uucp
>proxy
>www-data
>backup
>list
>irc
>gnats
>nobody
>systemd-timesync
>systemd-network
>systemd-resolve
>systemd-bus-proxy
>syslog
>_apt
>messagebus
>uuidd
>lightdm
>whoopsie
>avahi-autoipd
>avahi
>dnsmasq
>colord
>speech-dispatcher
>hplip
>kernoops
>pulse
>rtkit
>saned
>usbmux
>myth
>mysql
>ntp
>mythtv
>sshd
>vboxadd
>statd
>
>
>
>>
>> I am not sure why it has "dialout", but the other groups are
>> important.
>>
>> >When we test permissions, do we test the "mythtv" because the FE as well
>> as
>> >the DB user is "mythtv" or do we test "myth" because that's the BE user?
>>
>> Mythbackend runs as user mythtv on the backend box. Mythfrontend runs
>> as whatever user you run your desktop under on the frontend box. Both
>> of those users normally have "mythtv" as an additional group on their
>> respective boxes. The group IDs of the "mythtv" groups on the two
>> different boxes will not usually be the same, hence the are not the
>> same group.
>>
>> >I gather the DB user "mythtv" comes in play later once FE talks to the BE,
>> >but the file permissions AND ownership is what confuses me.
>> >
>> >My share "/usr/local/media/metadata" is currently showing as
>> >
>> >myth@ScorpioOne:~$ ls -ahl /usr/local/media/
>> >total 208K
>> >drwxrwsr-x 9 nobody 4294967294 91 May 7 01:07 .
>> >drwxr-xr-x 11 root root 127 May 11 14:24 ..
>> >drwxrwsr-x 4 root mythtv 35 May 2 08:43 Data
>> >drwxrwsr-x 2 root mythtv 6 May 7 01:07 live-tv
>> >drwxrwsr-x 2 nobody 4294967294 128K May 13 2018 metadata
>> >drwxrwsr-x 185 nobody 4294967294 20K May 12 23:11 Music
>> >drwxrwsr-x 103 nobody 4294967294 4.0K Jan 1 09:26 Pics
>> >drwxrwsr-x 4 root mythtv 38 May 7 01:34 TV
>> >drwxrwsr-x 8 root mythtv 108 Apr 13 12:47 Videos
>>
>> For storage groups, the ownership and permissions of the mythbackend
>> user on the backend box are what matters. Mythbackend normally runs
>> as user "mythtv" and group "mythtv" in Ubuntu. Mythfrontend talks to
>> mythbackend for access to the storage group files, so for access to
>> the recordings, its ownership and permissions do not matter as all
>> that traffic happens over TCP/IP connections between mythbackend and
>> mythfrontend. The normal setup for any storage group directory that
>> mythbackend has to access is to be ownership mythtv:mythtv with user
>> and group access both set to execute (=directory access), read and
>> write (chmod u=xrw,g=xrw).
>>
>> However, it is possible to access things other than through storage
>> groups. Both mythmusic (which is a plugin that runs entirely in
>> mythfrontend) and mythvideo (which is a builtin part of mythfrontend)
>> have settings for paths they can use to directly access things via the
>> normal access paths of the frontend box they are running on. These
>> paths are in addition to the storage group settings they also have. So
>> it depends on how you have them set up - if you have them access
>> things via their storage groups, then the same rules apply as for any
>> storage group - access is via mythbackend and the ownership and
>> permissions of mythbackend are what matter, and access happens from
>> the backend box. But if you are using the local system paths, access
>> to things via those paths uses mythfrontend's ownership and
>> permissions, and happens from the frontend box. The local paths are
>> also different for each frontend - the frontend settings are stored in
>> the "settings" table with a different hostname field value for each
>> frontend. So each frontend can access the videos or music in the
>> storage groups via the backend, and also potentially different videos
>> and music stored locally via the frontend.
>>
>> I think mythgallery and its replacement (mythimage?) work the same way
>> as mythmusic and mythvideo.
>>
>> Storage directories are set up in mythtv-setup on the backend box. The
>> local directories for a frontend are set up in mythfrontend on each
>> frontend box.
>>
>> So, I find your /usr/local/media ownership a bit strange. For a
>> start, the listing shows that the metadata, Music and Pics directories
>> have an unknown group (group ID 4294967294). That normally only
>> happens if they are network mounted from a different PC, where the
>> group IDs and user IDs do not match those on the local PC.
>
>You are correct - sorry I thought i had mentioned earlier - these are NFS
>storage.

OK, I must have missed that.

>
>> If they
>> were local they would normally have been created using existing local
>> users and groups and would be displayed with the name rather than a
>> number. Is that what is going on? That really can cause problems!
>> And having your recording directories mounted on other boxes means
>> that the bandwidth to them is limited by the Ethernet connection to
>> the other boxes, and that can cause failed recordings when the traffic
>> is too large.
>>
>
>I have a gig ethernet connection to the boxes, both at my home.
>
>
>>
>> And even more strange is that the /usr/local/media/ directory itself
>> is nobody:4294967294. So is that directory a network mount on a
>> different box?
>>
>
>Yes the storage are NFS mounted for everything
>
> - Video
> - TV
> - metadata
> - Music
> - Pics
> - live-tv
>
>
>> The other directories (Data, live-tv, TV and Videos) all have root
>> ownership. That is not necessarily fatal, as they do have mythtv
>> group ownership, but it is not normal. They ought to be mythtv user
>> ownership.
>>
>> And all the files under the storage group directories also should be
>> mythtv:mythtv ownership.
>>
>> It would also be a good idea to check that mythbackend is running as
>> user mythtv. Is this something like what "ps -ef | grep mythba" shows
>> for you?
>>
>> root@mypvr:~# ps -ef | grep mythba
>> mythtv 3480 1 8 May11 ? 06:22:36 /usr/bin/mythbackend
>> --quiet --syslog local7 -v record,dvbcam
>> root 18746 7172 0 14:39 pts/2 00:00:00 grep --color=auto
>> mythba
>>
>
>This is what it shows for me:
>
>myth@ScorpioOne:~$ ps -ef | grep mythba
>myth 4668 2188 0 23:29 pts/18 00:00:00 grep --color=auto mythba
>mythtv 25292 1 0 May12 ? 00:06:01 /usr/bin/mythbackend
>--quiet --syslog local7

That is good - mythbackend is running as the mythtv user.


I have not used NFS much, but it looks like it has the same problem as
SAMBA/CIFS - the user IDs and group IDs (apart from root = 0) do not
match between machines. That makes it difficult to get ownership to
work, unless NFS has some mechanism to map the user IDs and group IDs
to get them to match. So you probably will need to use wide open
permissions instead. As in everybody having access (chmod a=rwx). But
have a look as the NFS documentation and do a web search to see what
your options are for getting correct ownership.

Using network drives is fine for read-only things, such as videos,
pictures and music. And there should be no problems for the small
writeable files for things like the metadata and artwork. But the
higher bandwidth, and time critical, writing of recordings can be a
problem. Looking at the numbers for the bandwidth of one HD DVB-T
recording from my channels, I seem to need about 10 Mbytes/s or 80
Mbit/s for one recording. So being generous and allocating 100
Mbit/s, you would think that a 1 Gbit/s Ethernet would be fine for up
to 10 recordings at once. But that ignores other traffic, and unless
the NFS recording traffic has its packets flagged as high priority and
the switch between the backend PC and the NFS box does QoS and gives
those packets priority over other traffic, then you will have a
problem with just one recording if something else is using all the
bandwidth it can get. Just you copying a file to the NFS box from
another device can use all the available bandwidth on the NFS box's
one Ethernet port, and has the potential to cause gaps in your
recordings. Doing backups to the NFS box (a common use for such a
box) is very likely to cause trouble unless the backup software has
options to be set to use lower bandwidth, or can be set to only do
backups when there will never be any recordings happening.

So I would suggest doing some serious testing to see if it is OK to
record directly to the NFS box before setting it up that way. How
many recordings at once do think you will be doing? How many tuners
do you have? How many multirec recordings will each tuner do at once?

An alternative is to record to a local drive on the mythbackend box,
and when each recording completes (or later), move it over to the NFS
box. To make that work, you set up another storage group (other than
"Default") and put the NFS recording directories in that storage
group. I have one like that called "Archives", for my 8 Tbyte
shingled drives that can not be used for recordings as they can just
stop for several seconds while they do a shingle re-write operation.
Then you put the local hard drive directories in the "Default" storage
group, and if you never create any recording rules that use the
"Archives" storage group, nothing will ever be recorded to that
storage group, but anything you move into the "Archives" storage group
will be visible to mythbackend and can be played and deleted.

I have written myself some Python for moving files to my archive
drives. It keeps a check on MythTV activity and stops moving files
when a recording starts or just before the next one is scheduled to
start. It is probably not quite what you would want for moving files
from your backend local drive(s) to NFS, but I would be happy to
modify it to do what you need if you decide to go that way.

Even with a local recording drive, if it is spinning rust I use a rule
of thumb that there should be no more than three recordings going to a
drive at once. The problem is about the time taken for head movements
between the recording files, and also to the directory areas when the
file needs to be expanded. And it is even worse if your system and
database are on the same drive. Then I would do no more than two
recordings at once. Modern hard drives have very fast write speeds,
but the head movement has not sped up nearly as much as the on-track
write speed has, so it is easy to get fooled by the fast write speed
in the specification.

Of course, if the local drive is an SSD, then you can usually write to
many more files at once as there is no head movement. All you have to
watch out for there is the problem of the erase times. If the spare
space on an SSD has already been erased, its write times are very
fast. But if the drive is using a weekly TRIM operation to do the
erasing (which is the default in Ubuntu), then the large file sizes of
recording files can cause it to run out of erased blocks and have to
do a block erase before each block write. That makes an SSD write
very slowly. So if you record to SSD you should either be using the
"discard" option on the SSD when it is mounted from fstab, or running
the fstrim cron job much more often. I run my fstrim cron job daily,
but I do not record to the SSD - it just gets a lot of database
activity.
_______________________________________________
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
Re: Ubuntu Mythbackend issue [ In reply to ]
On Mon, May 14, 2018 at 3:45 AM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Sun, 13 May 2018 23:29:49 -0500, you wrote:
>
> >On Sun, May 13, 2018 at 10:06 PM Stephen Worthington <
> >stephen_agent@jsw.gen.nz> wrote:
> >
> >> On Sun, 13 May 2018 18:56:42 -0500, you wrote:
> >>
> >> >On Sun, May 13, 2018 at 11:55 AM Stephen Worthington <
> >> >stephen_agent@jsw.gen.nz> wrote:
> >> >
> >> >> On Sun, 13 May 2018 10:47:45 -0500, you wrote:
> >> >>
> >> >> >I see "can't write to" issue and some "AutoExpire: CalcParams(): Max
> >> >> >required Free Space: 1.0 GB w/freq: 15 min" thing which when I
> search
> >> >> seems
> >> >> >to be some TV Tuner issue
> >> >>
> >> >> You can ignore the "Autoexpire:" messages - they are normal. It just
> >> >> means that mythbackend has looked at all the storage groups and
> >> >> checked that they have enough free space. If they do not, it will
> >> >> choose some recordings to expire to create enough free space. Always
> >> >> make sure your storage groups have enough free space unless you want
> >> >> old recordings to expire. I leave a minimum of 20 Gibytes free at
> all
> >> >> times.
> >> >>
> >> >> The "can't write to" messages come about by mythbackend writing a
> zero
> >> >> length file ".test" to each storage group directory on startup. If
> it
> >> >> fails to create the file, or fails to be able to delete it, it will
> >> >> give the "can't write to" message and will not use that storage group
> >> >> directory for writing until the next time it is started.
> >> >>
> >> >> So, first, take a look and see if your storage group directories
> >> >> contain .test files, and what their ownership and permissions look
> >> >> like. Then manually delete them if they are there. If you have had
> a
> >> >> permissions problem that has caused the .test files to be left behind
> >> >> undeleted, then I think the test fails on creating new ones, hence
> the
> >> >> need to manually delete them after you fix the permissions.
> >> >>
> >> >> Then, try creating the .test files yourself as the user that
> >> >> mythbackend runs as (mythtv). Log in as root and do this:
> >> >>
> >> >> su - mythtv -c touch "<storage group path>/.test"
> >> >>
> >> >> And try deleting them again:
> >> >>
> >> >> su - mythtv -c "rm <storage group path>/.test"
> >> >>
> >> >> If either command does not work, then you need to fix the ownership
> >> >> and permissions until it does work.
> >> >
> >> >
> >> >so i am slightly confused. Here's what I have:
> >> >
> >> >BE user - myth (no "tv"), mythconverg user: mythtv
> >> >FE user - mythtv
> >> >
> >> >In ubuntu BE, i don't have "root". so i always log in as "myth" and
> when I
> >> >do, it let's me do the touch and rm the .test
> >>
> >> So does the backend user "mythtv" exist and have "mythtv" group? That
> >> is important. So what does this command show:
> >>
> >> su - mythtv -c "groups"
> >>
> >> This is what I get:
> >>
> >> root@mypvr:~# su - mythtv -c "groups"
> >> mythtv dialout cdrom audio video
> >>
> >
> >I don't know the password for username "mythtv"
> >During installation, I tried to name my user as "mythtv" for consistency
> >sake, but Ubuntu didn't allow me saying it's reserved so I had to create
> >"myth" as a user
>
> It is quite likely that the "mythtv" user does not have a password. It
> is possible for package installers to create a user without a
> password, and the "mythtv" user is created by the packages. The
> normal way to access such a user is via su or sudo (or root). Using a
> different name for your username on the backend box was the correct
> thing to do. The "myth" user should be a member of the "mythtv"
> group, but it will be a normal user capable of running a desktop and
> running mythtv-setup and mythfrontend.
>
> >I do get mythtv as a username - quick search gave me a command:
> >
> >myth@ScorpioOne:~$ cut -d: -f1 /etc/passwd
> >root
> >daemon
> >bin
> >sys
> >sync
> >games
> >man
> >lp
> >mail
> >news
> >uucp
> >proxy
> >www-data
> >backup
> >list
> >irc
> >gnats
> >nobody
> >systemd-timesync
> >systemd-network
> >systemd-resolve
> >systemd-bus-proxy
> >syslog
> >_apt
> >messagebus
> >uuidd
> >lightdm
> >whoopsie
> >avahi-autoipd
> >avahi
> >dnsmasq
> >colord
> >speech-dispatcher
> >hplip
> >kernoops
> >pulse
> >rtkit
> >saned
> >usbmux
> >myth
> >mysql
> >ntp
> >mythtv
> >sshd
> >vboxadd
> >statd
> >
> >
> >
> >>
> >> I am not sure why it has "dialout", but the other groups are
> >> important.
> >>
> >> >When we test permissions, do we test the "mythtv" because the FE as
> well
> >> as
> >> >the DB user is "mythtv" or do we test "myth" because that's the BE
> user?
> >>
> >> Mythbackend runs as user mythtv on the backend box. Mythfrontend runs
> >> as whatever user you run your desktop under on the frontend box. Both
> >> of those users normally have "mythtv" as an additional group on their
> >> respective boxes. The group IDs of the "mythtv" groups on the two
> >> different boxes will not usually be the same, hence the are not the
> >> same group.
> >>
> >> >I gather the DB user "mythtv" comes in play later once FE talks to the
> BE,
> >> >but the file permissions AND ownership is what confuses me.
> >> >
> >> >My share "/usr/local/media/metadata" is currently showing as
> >> >
> >> >myth@ScorpioOne:~$ ls -ahl /usr/local/media/
> >> >total 208K
> >> >drwxrwsr-x 9 nobody 4294967294 91 May 7 01:07 .
> >> >drwxr-xr-x 11 root root 127 May 11 14:24 ..
> >> >drwxrwsr-x 4 root mythtv 35 May 2 08:43 Data
> >> >drwxrwsr-x 2 root mythtv 6 May 7 01:07 live-tv
> >> >drwxrwsr-x 2 nobody 4294967294 128K May 13 2018 metadata
> >> >drwxrwsr-x 185 nobody 4294967294 20K May 12 23:11 Music
> >> >drwxrwsr-x 103 nobody 4294967294 4.0K Jan 1 09:26 Pics
> >> >drwxrwsr-x 4 root mythtv 38 May 7 01:34 TV
> >> >drwxrwsr-x 8 root mythtv 108 Apr 13 12:47 Videos
> >>
> >> For storage groups, the ownership and permissions of the mythbackend
> >> user on the backend box are what matters. Mythbackend normally runs
> >> as user "mythtv" and group "mythtv" in Ubuntu. Mythfrontend talks to
> >> mythbackend for access to the storage group files, so for access to
> >> the recordings, its ownership and permissions do not matter as all
> >> that traffic happens over TCP/IP connections between mythbackend and
> >> mythfrontend. The normal setup for any storage group directory that
> >> mythbackend has to access is to be ownership mythtv:mythtv with user
> >> and group access both set to execute (=directory access), read and
> >> write (chmod u=xrw,g=xrw).
> >>
> >> However, it is possible to access things other than through storage
> >> groups. Both mythmusic (which is a plugin that runs entirely in
> >> mythfrontend) and mythvideo (which is a builtin part of mythfrontend)
> >> have settings for paths they can use to directly access things via the
> >> normal access paths of the frontend box they are running on. These
> >> paths are in addition to the storage group settings they also have. So
> >> it depends on how you have them set up - if you have them access
> >> things via their storage groups, then the same rules apply as for any
> >> storage group - access is via mythbackend and the ownership and
> >> permissions of mythbackend are what matter, and access happens from
> >> the backend box. But if you are using the local system paths, access
> >> to things via those paths uses mythfrontend's ownership and
> >> permissions, and happens from the frontend box. The local paths are
> >> also different for each frontend - the frontend settings are stored in
> >> the "settings" table with a different hostname field value for each
> >> frontend. So each frontend can access the videos or music in the
> >> storage groups via the backend, and also potentially different videos
> >> and music stored locally via the frontend.
> >>
> >> I think mythgallery and its replacement (mythimage?) work the same way
> >> as mythmusic and mythvideo.
> >>
> >> Storage directories are set up in mythtv-setup on the backend box. The
> >> local directories for a frontend are set up in mythfrontend on each
> >> frontend box.
> >>
> >> So, I find your /usr/local/media ownership a bit strange. For a
> >> start, the listing shows that the metadata, Music and Pics directories
> >> have an unknown group (group ID 4294967294). That normally only
> >> happens if they are network mounted from a different PC, where the
> >> group IDs and user IDs do not match those on the local PC.
> >
> >You are correct - sorry I thought i had mentioned earlier - these are NFS
> >storage.
>
> OK, I must have missed that.
>
> >
> >> If they
> >> were local they would normally have been created using existing local
> >> users and groups and would be displayed with the name rather than a
> >> number. Is that what is going on? That really can cause problems!
> >> And having your recording directories mounted on other boxes means
> >> that the bandwidth to them is limited by the Ethernet connection to
> >> the other boxes, and that can cause failed recordings when the traffic
> >> is too large.
> >>
> >
> >I have a gig ethernet connection to the boxes, both at my home.
> >
> >
> >>
> >> And even more strange is that the /usr/local/media/ directory itself
> >> is nobody:4294967294. So is that directory a network mount on a
> >> different box?
> >>
> >
> >Yes the storage are NFS mounted for everything
> >
> > - Video
> > - TV
> > - metadata
> > - Music
> > - Pics
> > - live-tv
> >
> >
> >> The other directories (Data, live-tv, TV and Videos) all have root
> >> ownership. That is not necessarily fatal, as they do have mythtv
> >> group ownership, but it is not normal. They ought to be mythtv user
> >> ownership.
> >>
> >> And all the files under the storage group directories also should be
> >> mythtv:mythtv ownership.
> >>
> >> It would also be a good idea to check that mythbackend is running as
> >> user mythtv. Is this something like what "ps -ef | grep mythba" shows
> >> for you?
> >>
> >> root@mypvr:~# ps -ef | grep mythba
> >> mythtv 3480 1 8 May11 ? 06:22:36 /usr/bin/mythbackend
> >> --quiet --syslog local7 -v record,dvbcam
> >> root 18746 7172 0 14:39 pts/2 00:00:00 grep --color=auto
> >> mythba
> >>
> >
> >This is what it shows for me:
> >
> >myth@ScorpioOne:~$ ps -ef | grep mythba
> >myth 4668 2188 0 23:29 pts/18 00:00:00 grep --color=auto mythba
> >mythtv 25292 1 0 May12 ? 00:06:01 /usr/bin/mythbackend
> >--quiet --syslog local7
>
> That is good - mythbackend is running as the mythtv user.
>
>
> I have not used NFS much, but it looks like it has the same problem as
> SAMBA/CIFS - the user IDs and group IDs (apart from root = 0) do not
> match between machines. That makes it difficult to get ownership to
> work, unless NFS has some mechanism to map the user IDs and group IDs
> to get them to match. So you probably will need to use wide open
> permissions instead. As in everybody having access (chmod a=rwx). But
> have a look as the NFS documentation and do a web search to see what
> your options are for getting correct ownership.
>
> Using network drives is fine for read-only things, such as videos,
> pictures and music. And there should be no problems for the small
> writeable files for things like the metadata and artwork. But the
> higher bandwidth, and time critical, writing of recordings can be a
> problem. Looking at the numbers for the bandwidth of one HD DVB-T
> recording from my channels, I seem to need about 10 Mbytes/s or 80
> Mbit/s for one recording. So being generous and allocating 100
> Mbit/s, you would think that a 1 Gbit/s Ethernet would be fine for up
> to 10 recordings at once. But that ignores other traffic, and unless
> the NFS recording traffic has its packets flagged as high priority and
> the switch between the backend PC and the NFS box does QoS and gives
> those packets priority over other traffic, then you will have a
> problem with just one recording if something else is using all the
> bandwidth it can get. Just you copying a file to the NFS box from
> another device can use all the available bandwidth on the NFS box's
> one Ethernet port, and has the potential to cause gaps in your
> recordings. Doing backups to the NFS box (a common use for such a
> box) is very likely to cause trouble unless the backup software has
> options to be set to use lower bandwidth, or can be set to only do
> backups when there will never be any recordings happening.
>

Thank you - def going to work on this - i may move my hard drive on my
"old" myth BE (which is what is currently working as the NFS server) to the
new BE and thus make it local. However, for now, I am ONLY doing the Videos
part, not recording any TV shows. My backend is currently a VM so the
antenna is an issue. But I digress.


>
> So I would suggest doing some serious testing to see if it is OK to
> record directly to the NFS box before setting it up that way. How
> many recordings at once do think you will be doing? How many tuners
> do you have? How many multirec recordings will each tuner do at once?
>
> An alternative is to record to a local drive on the mythbackend box,
> and when each recording completes (or later), move it over to the NFS
> box. To make that work, you set up another storage group (other than
> "Default") and put the NFS recording directories in that storage
> group. I have one like that called "Archives", for my 8 Tbyte
> shingled drives that can not be used for recordings as they can just
> stop for several seconds while they do a shingle re-write operation.
> Then you put the local hard drive directories in the "Default" storage
> group, and if you never create any recording rules that use the
> "Archives" storage group, nothing will ever be recorded to that
> storage group, but anything you move into the "Archives" storage group
> will be visible to mythbackend and can be played and deleted.
>
> I have written myself some Python for moving files to my archive
> drives. It keeps a check on MythTV activity and stops moving files
> when a recording starts or just before the next one is scheduled to
> start. It is probably not quite what you would want for moving files
> from your backend local drive(s) to NFS, but I would be happy to
> modify it to do what you need if you decide to go that way.
>
> Even with a local recording drive, if it is spinning rust I use a rule
> of thumb that there should be no more than three recordings going to a
> drive at once. The problem is about the time taken for head movements
> between the recording files, and also to the directory areas when the
> file needs to be expanded. And it is even worse if your system and
> database are on the same drive. Then I would do no more than two
> recordings at once. Modern hard drives have very fast write speeds,
> but the head movement has not sped up nearly as much as the on-track
> write speed has, so it is easy to get fooled by the fast write speed
> in the specification.
>
> Of course, if the local drive is an SSD, then you can usually write to
> many more files at once as there is no head movement. All you have to
> watch out for there is the problem of the erase times. If the spare
> space on an SSD has already been erased, its write times are very
> fast. But if the drive is using a weekly TRIM operation to do the
> erasing (which is the default in Ubuntu), then the large file sizes of
> recording files can cause it to run out of erased blocks and have to
> do a block erase before each block write. That makes an SSD write
> very slowly. So if you record to SSD you should either be using the
> "discard" option on the SSD when it is mounted from fstab, or running
> the fstrim cron job much more often. I run my fstrim cron job daily,
> but I do not record to the SSD - it just gets a lot of database
> activity.
>


What about all these issues - the Myth Proto Issue. I notice that this
comes up randomly every other day as if telling me that the BE is busy. But
a 8 Gb server with 8 Gb swap, only being a backend, nothing else, hard to
think it is so busy it can't let a frontend talk to it.

https://pastebin.com/Sq8Bp8yc
Re: Ubuntu Mythbackend issue [ In reply to ]
On Mon, 14 May 2018 11:06:00 -0500, you wrote:


>What about all these issues - the Myth Proto Issue. I notice that this
>comes up randomly every other day as if telling me that the BE is busy. But
>a 8 Gb server with 8 Gb swap, only being a backend, nothing else, hard to
>think it is so busy it can't let a frontend talk to it.
>
>https://pastebin.com/Sq8Bp8yc

The "Protocol version check failure" messages can have a number of
causes. You need to dig into the problem when it next happens. On
the backend, check that mythbackend is running, and then run

netstat -ap | grep myth

to see what connections are up and on what ports. And you may need to
run Wireshark at both ends and get it to capture the port 6543 traffic
to see exactly what is happening.
_______________________________________________
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
Re: Ubuntu Mythbackend issue [ In reply to ]
On Mon, May 14, 2018 at 1:01 PM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Mon, 14 May 2018 11:06:00 -0500, you wrote:
>
>
> >What about all these issues - the Myth Proto Issue. I notice that this
> >comes up randomly every other day as if telling me that the BE is busy.
> But
> >a 8 Gb server with 8 Gb swap, only being a backend, nothing else, hard to
> >think it is so busy it can't let a frontend talk to it.
> >
> >https://pastebin.com/Sq8Bp8yc
>
> The "Protocol version check failure" messages can have a number of
> causes. You need to dig into the problem when it next happens.


I have seen it happening it a couple times when i do metadata retrieval.
But with 8Gb RAM, and a new box, i would hate to think the metadata is
bogging down everything!

Are there some config that will "optimize" the backend?



> On
> the backend, check that mythbackend is running, and then run
>
> netstat -ap | grep myth
>
> to see what connections are up and on what ports. And you may need to
> run Wireshark at both ends and get it to capture the port 6543 traffic
> to see exactly what is happening.
> _______________________________________________
> 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
>


--
http://about.me/adesai
Re: Ubuntu Mythbackend issue [ In reply to ]
On 14 May 2018 1:26:29 am Ashu Desai <ashu.desai@gmail.com> wrote:


On Sun, May 13, 2018 at 7:34 AM Mark Perkins <perkins1724@hotmail.com<mailto:perkins1724@hotmail.com>> wrote:



On 12 May 2018 11:16:27 pm Ashu Desai <ashu.desai@gmail.com<mailto:ashu.desai@gmail.com>> wrote:


On Sat, May 12, 2018, 6:06 AM Mark Perkins <perkins1724@hotmail.com<mailto:perkins1724@hotmail.com>> wrote:


Looks to me like the FE is talking to the database (port 3306) but not the backend (port 6543). Is your BE on the same machine / IP as the database?

Different machines. x.x.x.54 is my backend, 58 is my FE

Is the database (server) located on the same server as your BE? The FE is connecting to the database but not the BE. As it appears to me at least.

Yes, the mysql is on the Ubuntu BE, and the FE is trying to access it. The weird part is, it works on and off - i think it works every time I try to do a "chmod 775" on the backend but i think with a rescan it gets messed up.





no firewall on either.

it's the myth proto error and file permissions that also worry me


1.
2018-05-11 18:28:14.563156 I MythCoreContext::ConnectCommandSocket(): Connecting to backend server: 10.0.0.54:6543<http://10.0.0.54:6543> (try 1 of 1)
2.
2018-05-11 18:28:14.592341 I MythCoreContext::CheckProtoVersion(): Using protocol version 91 BuzzOff
3. .....
4.
2018-05-11 18:29:12.307678 E MythSocket(7ff0c400b050:48): ReadStringList: Error, timed out after 30000 ms.
5.
2018-05-11 18:29:12.308138 E MythSocket(7ff0c400b050:-1): No response.
6.
2018-05-11 18:29:12.308161 N MythCoreContext::SendReceiveStringList(): Connection to backend server lost
7.
2018-05-11 18:29:12.309207 N MythCoreContext::connectionClosed(): Event socket closed. No connection to the backend.


What does the BE log for the FE connection attempts? Check firewall settings (6543 and 6544) on the BE maybe.


Here's what the backend logs:

https://pastebin.com/yrAsWNeZ


Only looking briefly on mobile but I can't see any connection attempts from remote "mythfe7" FE to your "ScorpioOne" BE. I would double check port 6543 and 6544 access from remote FE to BE.
Re: Ubuntu Mythbackend issue [ In reply to ]
On Mon, May 14, 2018 at 4:15 PM Mark Perkins <perkins1724@hotmail.com>
wrote:

>
>
>
> On 14 May 2018 1:26:29 am Ashu Desai <ashu.desai@gmail.com> wrote:
>
>>
>>
>> On Sun, May 13, 2018 at 7:34 AM Mark Perkins <perkins1724@hotmail.com>
>> wrote:
>>
>>>
>>>
>>> On 12 May 2018 11:16:27 pm Ashu Desai <ashu.desai@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Sat, May 12, 2018, 6:06 AM Mark Perkins <perkins1724@hotmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> Looks to me like the FE is talking to the database (port 3306) but not
>>>>> the backend (port 6543). Is your BE on the same machine / IP as the
>>>>> database?
>>>>>
>>>>
>>>> Different machines. x.x.x.54 is my backend, 58 is my FE
>>>>
>>>
>>> Is the database (server) located on the same server as your BE? The FE
>>> is connecting to the database but not the BE. As it appears to me at least.
>>>
>>
>> Yes, the mysql is on the Ubuntu BE, and the FE is trying to access it.
>> The weird part is, it works on and off - i think it works every time I try
>> to do a "chmod 775" on the backend but i think with a rescan it gets messed
>> up.
>>
>>
>>
>>>
>>>
>>>
>>>> no firewall on either.
>>>>
>>>> it's the myth proto error and file permissions that also worry me
>>>>
>>>>>
>>>>>
>>>>> 1. 2018-05-11 18:28:14.563156 I
>>>>> MythCoreContext::ConnectCommandSocket(): Connecting to backend server:
>>>>> 10.0.0.54:6543 (try 1 of 1)
>>>>> 2. 2018-05-11 18:28:14.592341 I
>>>>> MythCoreContext::CheckProtoVersion(): Using protocol version 91 BuzzOff
>>>>> 3. .....
>>>>> 4. 2018-05-11 18:29:12.307678 E MythSocket(7ff0c400b050:48):
>>>>> ReadStringList: Error, timed out after 30000 ms.
>>>>> 5. 2018-05-11 18:29:12.308138 E MythSocket(7ff0c400b050:-1): No
>>>>> response.
>>>>> 6. 2018-05-11 18:29:12.308161 N
>>>>> MythCoreContext::SendReceiveStringList(): Connection to backend server lost
>>>>> 7. 2018-05-11 18:29:12.309207 N
>>>>> MythCoreContext::connectionClosed(): Event socket closed. No connection
>>>>> to the backend.
>>>>>
>>>>>
>>>>>
>>>>> What does the BE log for the FE connection attempts? Check firewall
>>>>> settings (6543 and 6544) on the BE maybe.
>>>>>
>>>>>
>> Here's what the backend logs:
>>
>> https://pastebin.com/yrAsWNeZ
>>
>>
> Only looking briefly on mobile but I can't see any connection attempts
> from remote "mythfe7" FE to your "ScorpioOne" BE. I would double check
> port 6543 and 6544 access from remote FE to BE.
> ____________________
>

So this happens every now and then. Like right now - it works fine! I can't
seem to figure out what is causing this disconnect. The one I have posted
was when a couple hours earlier i had done metadata retrieval - but I would
hate to think that after a few hours, it's still bogging down the FE.

Last night I got permissions issue. This morning, without me having done
anything, I can access it fine. I wish I could debug this to find out what
is going on here...