[mythtv-users] Video storage group problems with slave backends

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