Moving mythtv to manjaro from ubuntu, hung at mythweb's video_dir

For discussion of topics specific to MythTV on linux
Post Reply
User avatar
keepitsimpleengineer
Junior
Posts: 18
Joined: Fri Oct 03, 2014 9:53 pm
Location: Central California, U.S.A.
Contact:
United States of America

Moving mythtv to manjaro from ubuntu, hung at mythweb's video_dir

Post by keepitsimpleengineer » Fri May 10, 2019 5:18 pm

I have a nine year old mythbuntu system that would not upgrade from Ubuntu 16.04 LTS to 18.04, so I elected to switch to Manjaro. I now will have three Manjaro, two Archlinux and assorted MS Windows systems. I’ve get everything working including a LAMP (https://forum.manjaro.org/t/install-apa ... -2016/1243) but am stuck with mythweb (https://wiki.archlinux.org/index.php/MythWeb). My initial directory structure seems not to support current mythweb although it worked in 16.04.
I have four physical disks, the first has three partitions, root, swap and mythtv, the remaining three are single mythtv partitions.

Code: Select all

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 465.8G  0 disk
├─sda1   8:1    0    64G  0 part /
├─sda2   8:2    0   7.5G  0 part [SWAP]
└─sda3   8:3    0 394.3G  0 part /pvt
sdb      8:16   0   2.7T  0 disk
└─sdb1   8:17   0   2.7T  0 part /pvr
sdc      8:32   0   1.8T  0 disk
└─sdc1   8:33   0   1.8T  0 part /pvs
sdd      8:48   0   5.5T  0 disk
└─sdd1   8:49   0   5.5T  0 part /pvu
The mythtv partitions are all xfs and have nearly the same structure,

Code: Select all

ls /pvt
bnnrs  cvrart  db_bu  default  fanart  livetv  root-back-up  scrnshots  strmng  tmp  trlrs  videos
All recordings are in the ‘default’ subdirectory in each mythtv partition. Here is fstab

Code: Select all

UUID=2ad58694-ece5-4fc0-a6bd-50c7d91e370c /              ext4    defaults,noatime 0 1
UUID=d435a4cd-c3e5-4e20-a014-c01f0bb114ac swap           swap    defaults,noatime 0 2
# /dev/sda3 LABEL=MYTH01
UUID=53dccff3-05e7-4de8-aac5-5617c512e3ee       /pvt    xfs     logbufs=8,allocsize=512m        0       2
# /dev/sdb1 LABEL=Rpl-MYTHforP
UUID=00e8ef5f-b7c8-44c9-bab0-ed88ab11236a       /pvr    xfs     logbufs=8,allocsize=512m        0       2
# /dev/sdc1 LABEL=MYTH03
UUID=fc3a4957-7e70-4cf4-b0a1-220536de640a       /pvs    xfs     logbufs=8,allocsize=512m        0       2
# /dev/sdd1 LABEL=XFSforPVU
UUID=2382c570-631d-4582-b127-86cb8a49b7d0       /pvu    xfs     logbufs=8,allocsize=512m        0       2
It seems that current practice is to mount all recording in a single point, and I am not quite sure as to pull that off or find a workaround. What I really crave is a working mythweb, and an open to any suggestions.

Here's storage groups from the backend…
278fa83464562817d503dcd7c95b6959b799842e_2_690x162.jpeg
278fa83464562817d503dcd7c95b6959b799842e_2_690x162.jpeg (67.86 KiB) Viewed 182 times
UPDATE
(Note: all recording are in the 'Default' Storage group)
So according to https://wiki.archlinux.org/index.php/My ... ntegration which wants all the recordings in one directory, will this work?

Code: Select all

# ln -s /pvr/default /var/lib/mythtv/mythweb/video_dir
# ln -s /pvs/default /var/lib/mythtv/mythweb/video_dir
# ln -s /pvt/default /var/lib/mythtv/mythweb/video_dir
# ln -s /pvu/default /var/lib/mythtv/mythweb/video_dir
Last edited by keepitsimpleengineer on Fri May 10, 2019 6:47 pm, edited 1 time in total.

User avatar
bill6502
Developer
Posts: 1289
Joined: Fri Feb 07, 2014 5:28 pm
United States of America

Re: Moving mythtv to manjaro from ubuntu, hung at mythweb's video_dir

Post by bill6502 » Fri May 10, 2019 5:58 pm

I disagree with the "current practice is to mount all recording in a single point" comment. It
isn't unusual to have a parent, e.g. /srv/mythtv/. What's critical is making sure that if a
mount fails, recordings won't end up in the root filesystem. /srv/mythtv/pvX could be a mount
point, but /srv/mythtv/pvX/recordings is where the recordings go (recordings is a directory that
exists on the partition mounted so if the mount fails, nothing gets written.)

mythweb setup isn't dependent on storage groups. The Arch Wiki cited above looks OK (I didn't
read the whole thing.) The /srv/http/mythweb location for the mythweb files makes sense. The
configuration file points to it.

Since I don't use it much, I'd suggest defining what is failing, so that others can comment.

Looking for logs may help. In my case, /var/log/apache2/error.log is used.

In the mean time, <yourBackend>:6544 will get you WebFrontend that has some of the mythweb
features.

User avatar
keepitsimpleengineer
Junior
Posts: 18
Joined: Fri Oct 03, 2014 9:53 pm
Location: Central California, U.S.A.
Contact:
United States of America

Re: Moving mythtv to manjaro from ubuntu, hung at mythweb's video_dir

Post by keepitsimpleengineer » Fri May 10, 2019 6:54 pm

bill6502 wrote:
Fri May 10, 2019 5:58 pm
I disagree with the "current practice is to mount all recording in a single point" comment. It
isn't unusual to have a parent, e.g. /srv/mythtv/. What's critical is making sure that if a
mount fails, recordings won't end up in the root filesystem. /srv/mythtv/pvX could be a mount
point, but /srv/mythtv/pvX/recordings is where the recordings go (recordings is a directory that
exists on the partition mounted so if the mount fails, nothing gets written.)

mythweb setup isn't dependent on storage groups. The Arch Wiki cited above looks OK (I didn't
read the whole thing.) The /srv/http/mythweb location for the mythweb files makes sense. The
configuration file points to it.

Since I don't use it much, I'd suggest defining what is failing, so that others can comment.

Looking for logs may help. In my case, /var/log/apache2/error.log is used.

In the mean time, <yourBackend>:6544 will get you WebFrontend that has some of the mythweb
features.
Thanks for the tip about <yourBackend>:6544 :)
I also updated the original post as you suggested.

User avatar
keepitsimpleengineer
Junior
Posts: 18
Joined: Fri Oct 03, 2014 9:53 pm
Location: Central California, U.S.A.
Contact:
United States of America

Re: Moving mythtv to manjaro from ubuntu, hung at mythweb's video_dir

Post by keepitsimpleengineer » Fri May 10, 2019 8:30 pm

I think I may have found a solution, using mergerfs

Code: Select all

UUID=2ad58694-ece5-4fc0-a6bd-50c7d91e370c /              ext4    defaults,noatime 0 1
UUID=d435a4cd-c3e5-4e20-a014-c01f0bb114ac swap           swap    defaults,noatime 0 2
# /dev/sda3 LABEL=MYTH01
UUID=53dccff3-05e7-4de8-aac5-5617c512e3ee       /pvt    xfs     logbufs=8,allocsize=512m        0       2
# /dev/sdb1 LABEL=Rpl-MYTHforP
UUID=00e8ef5f-b7c8-44c9-bab0-ed88ab11236a       /pvr    xfs     logbufs=8,allocsize=512m        0       2
# /dev/sdc1 LABEL=MYTH03
UUID=fc3a4957-7e70-4cf4-b0a1-220536de640a       /pvs    xfs     logbufs=8,allocsize=512m        0       2
# /dev/sdd1 LABEL=XFSforPVU
UUID=2382c570-631d-4582-b127-86cb8a49b7d0       /pvu    xfs     logbufs=8,allocsize=512m        0       2

#mergerfs
/pvr/default:/pvs/default:/pvr/default:/pvu/default /var/lib/mythtv/mythweb/video_dir fuse.mergerfs defaults,allow_other,direct_io,use_ino,category.create=eplfs,moveonenospc=true
Which produces this:

Code: Select all

# df -h
Filesystem                               Size  Used Avail Use% Mounted on
dev                                      3.9G     0  3.9G   0% /dev
run                                      3.9G  1.3M  3.9G   1% /run
/dev/sdb1                                 63G   11G   49G  19% /
tmpfs                                    3.9G     0  3.9G   0% /dev/shm
tmpfs                                    3.9G     0  3.9G   0% /sys/fs/cgroup
tmpfs                                    3.9G  7.5M  3.9G   1% /tmp
/dev/sdd1                                5.5T  4.1T  1.5T  74% /pvu
/dev/sdb3                                395G  175G  220G  45% /pvt
/dev/sdc1                                1.9T  1.2T  648G  66% /pvs
/dev/sda1                                2.8T  2.1T  650G  77% /pvr
tmpfs                                    798M   12K  798M   1% /run/user/1000
r/default:s/default:r/default:u/default   11T  7.3T  2.8T  73% /var/lib/mythtv/mythweb/video_dir
I'll follow up after testing... .. .

Post Reply