Opened 12 years ago

Closed 8 years ago

Last modified 8 years ago

#4932 closed defect (Won't Fix)

mythrename.pl should truncate the basename to ensure it fits in the recorded table

Reported by: anonymous Owned by: sphery
Priority: minor Milestone: 0.23
Component: Contributed Scripts & Apps Version: unknown
Severity: medium Keywords:
Cc: Ticket locked: no

Description

One of my local tv broadcasters has seen fit to put the description of the show in the subtitle, and as a result whenever I run mythrename.pl these files can no longer be accessed from the database as they don't match the files in the recordings folder because the name in the recorded table in the DB gets cut off at 128 characters.

Change History (9)

comment:1 Changed 11 years ago by Rob Smith

Owner: changed from Isaac Richards to Rob Smith
Status: newaccepted

comment:2 Changed 11 years ago by Rob Smith

Component: contribContributed Scripts & Apps
Owner: Rob Smith deleted
Status: acceptednew

comment:3 Changed 10 years ago by stuartm

Owner: set to sphery
Status: newassigned

comment:4 Changed 10 years ago by sphery

(In [23474]) Remove the file-renaming support from mythrename.pl. Trying to automatically rename recording files based on listings-provided data is causing problems and isn't really necessary. Instead of renaming files, users should create symlink (with this script--to be renamed mythlink.pl after this change) or FUSE-based (with contrib/exports/mythfs.py) views of recordings. If there is any strong reason to support "human-readable" file names, such support should probably be added to mythbackend.

After this change, mythrename.pl (soon to be mythlink.pl) with no arguments will create pretty-formatted symlinks under the "show_names" directory of the first storage group directory. Typically the program will be called with the --link or --dest argument (as before) to specify a destination for the symlinks. (However, this change means that the default behavior of the script is non-destructive.)

The file-renaming support was changed to only support renaming files back to their default file names and is only used when the --rename argument is specified. Any --format argument is ignored when the --rename argument is specified.

Though this change looks very invasive in the diff, it mostly just moved the "else" handling renaming to its own subroutine and unshifted code that was previously in an if conditional. Though the separate subroutine means there is redundant code for setting up and looping over the recordings, the structure will allow easy removal of the "rename to default" code after a release version or so.

Refs #4932. Refs #7535.

comment:5 Changed 10 years ago by sphery

Milestone: unknown0.23
Priority: majorminor
Resolution: wontfix
Status: assignedclosed

After [23474], mythrename.pl no longer renames recording files (and after 23475 is called mythlink.pl). Different file systems have different requirements for allowed characters and allowed file name lengths and allowed path lengths, making it difficult to safely handle all cases. Users should instead use symlink (created with mythlink.pl) or FUSE-based (with mythtv/contrib/exports/mythfs.py ) views of recordings files, rather than renaming the actual files.

If you had previously renamed files, you may revert them to default file names with: mythlink.pl --rename

comment:6 Changed 8 years ago by jjones@…

Resolution: wontfix
Status: closednew

I know this was closed for good reason, and that it was opened before mythrename was changed over to mythlink, but I think this would still be a helpful fix. Maybe it should be viewed not as a defect, but rather an enhancement. If there is a way to do this within the perl script itself, I would be glad to work on the coding, but it looks like the script is using a function that is built into mythtv for actually naming the symlinks. If, however, the perl script could retrieve the information for the symbolic link name, then I may be able to add the code to truncate the name based on a passed argument for the truncate length. That way we are not overly complicating the script by trying to check for possible errors based on possible filesystems.

As stated before I will take a stab at the coding for the passing of a new argument and the truncation, if I could get some help in the area of retrieving the symbolic link name.

comment:7 Changed 8 years ago by robertm

Resolution: Won't Fix
Status: newclosed

We don't support the modification of the DB tables any more, and mythrename doesn't even exist any more-- there's no reason for this ticket to be reopened. If you'd like coding answers please take your requests to the mailing lists.

comment:8 in reply to:  7 Changed 8 years ago by jjones@…

Replying to robertm:

We don't support the modification of the DB tables any more, and mythrename doesn't even exist any more-- there's no reason for this ticket to be reopened. If you'd like coding answers please take your requests to the mailing lists.

Sorry to have upset you. I do not want to use mythrename at all. I am using mythlink.pl, and am having the same problem as the original post because the filename that is attempted to write is too long. I understand that the program should not attempt to anticipate the limitations of whatever filesystem I am using, but I would like to have the option to pass an argument to restrict or truncate the symbolic link name to the number of characters passed. If this was an inappropriate place for that post I apologize.

Should this be a new ticket on mythlink, or should I take this to the mailing lists to figure out how to do it myself?

comment:9 Changed 8 years ago by robertm

If you want to enhance mythlink, start on the mailing lists, produce a patch, and then open a ticket with a patch, this is how we perform enhancements.

Note: See TracTickets for help on using tickets.