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

Andre Newman mythtv-list at dinkum.org.uk
Wed Feb 13 16:59:06 UTC 2013


On 13 Feb 2013, at 16:31, Michael T. Dean wrote:

> 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.

Replying to myself, oh dear!

It seem if I scan for new videos with the slave backend turned off completely, then the master fetches and stores the coverart/fanart correctly, odd but I have working coverart again after about 6 months of puzzling.



>> 
>> 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:

Thanks for following this up, I've had a lot (a huge lot) of experimental frontends and quite a few slave backends too so I suspect there is considerable messiness in my database, this is the first time it's bitten me though. I'll be a lot more careful to de-commission things in future.


> 
> 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.

It was fairly recently so 0.25fixes, just trying out a DVBT2 card without messing up the main system.

I thought those videos were in the current library but perhaps not that exact file, if not they are truly gone as I didn't recall adding any videos on that host, I have been clearing up recently.

Nice to know that Videos searches all directories in the SG, same as recordings.

> 
> 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.

This sounds like the one, I had considered this but hadn't gone quite that far, wish me luck :-)


> 
> Assuming "manually" deleting the video in Manage Videos (i.e. highlight it and press D) doesn't work,

It doesn't, I was hoping for the same behaviour as in recordings, deletes but with a warning that the file can't be found but no.

> 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.

That would be a useful addition, consistent between videos and recordings.

I'm working towards keeping most things in videos, as you frequently advocate but it seems that videos isn't quite well behaved enough just yet, or at least I don't know all the wrinkles I need to know, yet…

Thanks again.

Andre


More information about the mythtv-users mailing list