[mythtv-users] Video storage group problems with slave backends
Michael T. Dean
mtdean at thirdcontact.com
Wed Feb 13 16:31:52 UTC 2013
On 02/13/2013 07:59 AM, Andre Newman wrote:
> Hi,
>
> I'm having a couple of strange problems with Video storage groups, I've been trying to resolve this and putting up with it for some time.
>
> I have a main backend "fair" with loads of storage and a couple of tuners, a slave backend "media" with two satellite tuners and NFS mounted storage paths same as the main backend. Finally a remote proper frontend and a couple of laptops running mythfrontend occasionally.
>
> Master backend: Ubuntu 12.04 mythbackend version: fixes/0.25 [v0.25.3-32-g79a24c9]
> Slave backend: Ubuntu 11.10 mythbackend version: fixes/0.25 [v0.25.3-15-g76d9c3e-dirty] (dirty due to patch for>5 multirec tuners)
>
> The main problem and potentially the cause?:
>
> Every time I "scan for changes" in the video library I get an error
>
> Failed to Scan SG Video Hosts:
> melbourne
> If they no longer exist please remove them
>
> Ok, I used to have a slave backend called melbourne but this long gone and the tuners it provided are now in the master backend, no way to resurrect it. I found a posting by Mike Dean referring to the wiki article on retiring failed slave backends and I have tried this procedure, well several times actually.
> http://www.mythtv.org/wiki/Backend_migration#Retiring_an_old_backend
>
> I get the Delete Default SG on remote hosts message but melbourne still pops up!
>
> I have tried to reset my video library by pointing the Video SG to an empty directory and scanning for changes, in my current situation most of the videos are removed but I still get the "Failed to Scan SG Video hosts: Melbourne" message again. There are three videos remaining (from Melbourne I guess) and I am unable to play or delete them.
>
> having a look in the DB for anything odd hasn't helped, SELECT * FROM storagegroup; returns exactly the directories I have configured all against the master BE hostname fair, nothing from melbourne.
>
> mysql> SELECT * FROM storagegroup;
> +-----+-------------+----------+--------------------------------+
> | id | groupname | hostname | dirname |
> +-----+-------------+----------+--------------------------------+
> | 222 | Streaming | fair | /var/lib/mythtv/streaming/ |
> | 223 | Videos | fair | /var/lib/mythtv/R4/videosB/ |
> | 210 | Default | fair | /var/lib/mythtv/R1/recordings/ |
> | 211 | Default | fair | /var/lib/mythtv/R2/recordings/ |
> | 212 | Default | fair | /var/lib/mythtv/R3/recordings/ |
> | 213 | Default | fair | /var/lib/mythtv/R4/recordings/ |
> | 214 | LiveTV | fair | /var/lib/mythtv/livetv/ |
> | 215 | DB Backups | fair | /var/lib/mythtv/R1/db_backups/ |
> | 216 | DB Backups | fair | /var/lib/mythtv/R4/db_backups/ |
> | 217 | Trailers | fair | /var/lib/mythtv/trailers/ |
> | 218 | Coverart | fair | /var/lib/mythtv/coverart/ |
> | 219 | Fanart | fair | /var/lib/mythtv/fanart/ |
> | 220 | Screenshots | fair | /var/lib/mythtv/screenshots/ |
> | 221 | Banners | fair | /var/lib/mythtv/banners/ |
> +-----+-------------+----------+--------------------------------+
> 14 rows in set (0.00 sec)
>
> The videosB directory is a purposely empty directory created for resetting the video library.
>
>
> The second problem and perhaps a clue:
>
> Coverart for videos is sparse at best and doesn't update when asked to "w" or "retrieve all details" (hence the resetting the library) Scanning is done on a frontend running on the master backend.
>
> Looking at the mythfrontend.log when trying to retrieve coverart I see that the frontend is trying to store the coverart on the slave backend! The IP address .147 is the slave .146 is the master.
>
> e.g.
>
> Feb 13 11:37:19 fair mythfrontend[9134]: E MetadataImageDownload metadataimagedownload.cpp:251 (run) Image Download: Failed to open remote file (myth://Coverart@XX.XXX.129.147:6543/122_coverart.jpg) for write. Does Storage Group Exist?
> Feb 13 11:37:19 fair mythfrontend[9134]: I MetadataImageDownload metadataimagedownload.cpp:222 (run) Metadata Image Download: http://d3gtl9l2a4fn1j.cloudfront.net/t/p/original/tWJgplIbMptB1RYRVgWieROYH7n.jpg -> myth://Fanart@XX.XXX.129.147:6543/122_fanart.jpg
>
> It seems to me that my MythTV system is a little confused, it's been running well since 2005, 1291 shows, 18889 episodes apparently.
>
> I've built many mythtv systems and sorted out problems on various friend's systems but this one is stumping me.
>
> Anyone?
>
The problem is that--although you've properly cleaned up all of your
Storage Groups--the Video Library still thinks you have some shows on
the old host, melbourne, since the host that owns the videos is stored
along with the video metadata. Therefore, it's trying to contact
melbourne to see if any videos exist on that host. Since it's unable to
contact melbourne (since it doesn't exist, anymore), it refuses to
delete the videos. This was done to prevent people from losing half of
their videos every time they did a scan when one of their systems was
powered off.
Unfortunately, though, it makes things more complicated when you don't
properly decommission an old host (and, yes, based on this inquiry and
the information Raymond Wagner provided to me, I need to update the wiki
page to explain more about how to handle Video Library information).
There are basically 2 good ways you can fix the problem at this point:
a) The best way to fix the issue is to let MythTV figure out those
videos are now on another host. This will work if the old host was
sufficiently new (0.24+? or was it 0.23+?) that Video Library created a
hash for the video files. If so, simply putting those videos into the
Video Library Storage Group directories on another host will cause Video
Library to see the same video on another host and "move" the metadata to
the other host.
b) If you used melbourne with an ancient version of MythTV and Video
Library didn't create hashes for your videos, you can start up
mythbackend temporarily on your remote backend using a LocalHostName
override (in config.xml) that specifies the profile name melbourne.
That way, the backend would "act like" the one that used to exist on
melbourne. Then, by ensuring that the Videos Storage Group directories
are empty, you can run a scan and Video Library will remove all the
videos associated with melbourne. Then, just remove the LocalHostName
override and restart your remote backend using the "proper" profile
information/configuration.
Assuming "manually" deleting the video in Manage Videos (i.e. highlight
it and press D) doesn't work, we may allow manual deletion (possibly
with prompt) of videos from "non-existent" hosts in the future... Just
one of those things that hasn't been done, yet.
Mike
More information about the mythtv-users
mailing list