[mythtv-users] mythrename.pl kills myth2ipod?

[come se fosse antani]

On 3/7/07, Michael T. Dean <mtdean at thirdcontact.com> wrote:
> On 03/07/2007 07:14 AM, come se fosse antani wrote:
> > On 3/7/07, Michael T. Dean <mtdean at thirdcontact.com> wrote:
> >
> >> On 03/07/2007 03:15 AM, Dmitry Shesterin aka dscheste wrote:
> >>
> >>> Is there a way to get myth2ipod working after recordings were renamed
> >>> using mythrename.pl?
> >>>
> >>> I stumbled upon this problem when I realized that myth2ipod does not
> >>> convert anything. When I looked into the code I realized that it
> >>> reverse-parses the filenames and, logically, if the names were changed
> >>> by mythrename.pl, parsing fails, the subsequent SQL query fails and
> >>> the script just exits.
> >>>
> >>>
> >>> Does anybody have a workaround?
> >>>
> >> mythrename.pl --format '%c_%Y%m%d%H%i%s' --live
> >>
> >> And from then on use mythrename.pl's "--link" option to create links to
> >> your files with pretty names.  I have 5 different directories of links
> >> in different formats giving me differently-sorted views.  It's /much/
> >> more powerful than renaming the actual files, and when I want a copy of
> >> the file on a laptop or whatever, I can scp the link and it copies the
> >> file using the link name.  So, ugly filenames are only used by Myth and
> >> I only use link names.  Really, it makes me wonder why anyone would want
> >> to rename the files...
> >>
> > Sorry Mike but:
> > If i create the links with mythrename and then I delete some of the
> > recordings using the frontend, the links are still there, right?
>
> Until the next time you run mythrename.pl--which deletes all the links
> below the destination directory before creating new links.
>
> $ ls -al views/original_airdate/*.{mpg,nuv} | wc -l
> 200
> $ ls -al recordings/*.{mpg,nuv} | wc -l
> 200
>
> And I delete everything right after watching it...  I run mythrename.pl
> on a 30-minute cron job, so there is a small window in there where right
> after I delete a show, the link still exists, but it's never been a
> problem before.
>

thanks!