Modify

Ticket #4932 (closed defect: Won't Fix)

Opened 4 years ago

Last modified 13 months ago

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

Reported by: anonymous Owned by: mdean
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.

Attachments

Change History

comment:1 Changed 4 years ago by kormoc

  • Owner changed from ijr to kormoc
  • Status changed from new to accepted

comment:2 Changed 3 years ago by kormoc

  • Owner kormoc deleted
  • Status changed from accepted to new
  • Component changed from contrib to Contributed Scripts & Apps

comment:3 Changed 3 years ago by stuartm

  • Owner set to mdean
  • Status changed from new to assigned

comment:4 Changed 2 years ago by mdean

(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 2 years ago by mdean

  • Priority changed from major to minor
  • Status changed from assigned to closed
  • Resolution set to wontfix
  • Milestone changed from unknown to 0.23

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 13 months ago by jjones@…

  • Status changed from closed to new
  • Resolution wontfix deleted

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 follow-up: ↓ 8 Changed 13 months ago by robertm

  • Status changed from new to closed
  • Resolution set to Won't Fix

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

View

Add a comment

Modify Ticket

Action
as closed
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.