[mythtv-users] I need to reinstall my backend

[Michael T. Dean]

On 02/27/2010 04:23 PM, Nick Rout wrote:
> On Sun, Feb 28, 2010 at 5:12 AM, Michael T. Dean wrote:
>    
>> On 02/27/2010 08:12 AM, Ian Oliver wrote:
>>      
>>> Ian Oliver wrote:
>>>        
>>>> Thanks, re-install done, mythconverg restored, recordings all back in
>>>> place, and everything set up more or less how I want it.
>>>>          
>>> Drat, I didn't notice but I must have restored an old database and I've
>>> lost a few recordings.  Is there any way to put these back into the
>>> database or do I need to move the mpg files across to the videos
>>> directory?
>>>        
>> Best bet is to put them in MythVideo.
>>
>> You can, if you like, use the old, legacy, unmaintained,
>> use-at-your-own-risk scripts myth_find_orphans.pl and
>> myth.rebuilddatabase.pl to put the data into the database (but note that
>> they will not insert some required information and will put some bad
>> information in the database--thus my recommendation that you just stick the
>> shows in MythVideo).
>>      
> If those scripts are so bad, why are they still distributed with
> mythtv and why is there no warning in the wiki? I could put something
> in the wiki but I don't know enough about why they are bad to say
> anything too intelligent (other than to point to this thread).
>
> More importantly does anyone know what to do to fix them? They seem to
> be useful :)
>    

To fix them we need to put the functionality where it belongs--in 
mythbackend and mythfrontend, not in a hacked-together script that's not 
updated when code in MythTV changes (or new features like Storage Groups 
are added or ...).  This is on my TODO--mythbackend will automatically 
find stuff in your recordings directories and add it, and you'll be able 
to request a list of all the data in the database for which files are 
missing using mythfrontend or MythWeb.

Until then, "Best bet is to put them in MythVideo."  (Meaning I don't 
plan to waste time on those scripts that I could instead spend on doing 
things right with a more useful interface and a more-robust solution.)

Mike