[mythtv-users] Mythvidexport problem

[Mike Carron]

On 1/4/2014 1:50 PM, Roger Siddons wrote:
> On Sat, 04 Jan 2014 15:51:19 -0000, Mike Carron 
> <jmcarron at starstream.net> wrote:
>
>     I installed mythvidexport.py on my system (Mythbuntuj12.04.3/Myth
>     0.25) yesterday and am getting about a 50% success rate on
>     exporting to the Video Library. Those that succeed are great and I
>     really like the appearance of the videos page so far.
>     Unfortunately, the mythbackend.log hasn't been very informative
>     about failures, saying only that the userjob failed.
>     The Backend Status page on MythWeb is better:
>
>         6 of the failures were "Failure to overwrite e",
>         2 were "External system call failed: code 1" and
>         1 was "User job returned non-zero, check logs."
>
>     There was no user job entry in the backend log for that last
>     failure at the time given on the Backend Status page. If there is
>     a mythvidexport log it isn't in /var/log/mythtv and I haven't been
>     able to find it.
>
>     Those which failed with the "Failure to overwrite e" message also
>     left the name of the series in the first column of the Videos page
>     and I'm not able to delete it.
>
>     Any suggestions?
>
>
> I've recently started using mythvidexport and also found that it 
> doesn't play nice with Mythbuntu/rsyslog logging (even with a modified 
> configuration). I haven't got to the bottom of that yet. A work-around 
> is to try the --logpath option.
>
> 'Failure to overwrite' occurs because your video library already 
> contains a file with the same name and mythvidexport (sensibly) won't 
> overwrite it. You mention series so I'm guessing episode 1 exported ok 
> but subsequent episodes were trying to overwrite it because they were 
> assigned the same filename. I don't export TV series but I suspect the 
> filenames can end up being very generic when the metadata lookup fails 
> (ie. no matches/multiple matches). You may have to manually edit the 
> filename before before exporting more episodes of the same series.
That explains why two different series behave so much differently. One, 
which apparently has good metadata, is putting episodes in 
sub-directories of /Television/Series/Season x/Intuitive-FileName.mpg 
while the other, which apparently has incomplete metadata, attempts to 
use /Videos/SeriesName.mpg.
>
> 'external system call failed' usually indicates the metadata lookup 
> grabber bombed out for some reason.
>
> Any new directories/files created will be owned by mythtv user (ie. 
> the backend) so the frontend won't have permissions to delete them. 
> That's good, isn't it ? You can delete them manually by using 'sudo rm 
> <file>' from a terminal.
When I first read that is seemed a bit inconvenient but after a few 
seconds thought it makes perfect sense, when things are straightened out 
I won't be doing frequent deletes from the video library anyway.
>
> The easiest solution for problem jobs is to run mythvidexport from the 
> command line. The backend log does show you the 4 digit job id in the 
> form of 'UserJob_<jobid>' so you should be able to simply re-use that;
I wish I could do that but for some strange reason mythvidexport runs 
fine as a UserJob but it won't run from the command line, I get 'command 
not found' whenever I try, regardless of whether I'm logged in as 
myself, as mythtv or as root.
>
> mythvidexport.py  <jobid>
>
> You'll probably still have permissions issues but it should give you a 
> clue as to what the problem is.
>
> Note there's been some discussion lately about metadata grabber API 
> changes. Your 0.25 grabbers may have been affected by those.
I have noticed those discussions but I don't think I'll be going away 
from 0.25 soon, the wife really likes having "Record any time on channel 
XX" and I'm really not looking forward to taking it away from her no 
matter what it is replaced by.

Hopefully I have enough now to proceed and work around incomplete 
metadata. Thank you very much.

mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140104/d10a6df6/attachment.html>