I have already opened a Mantis ticked for this feature request, but wanted to open it up for some discussion.
Currently, recording created with MythTV have a very cryptic filename consisting of the channelID (not necessarily the Channel Number), creation date, etc. It makes it a mess to try to edit attributes via Media Files Sync, or try to find any particular recording at all without using a MythTV frontend. This makes managing a large recording library in LMCE extremely difficult.
The prolem is, this is just how MythTV stores recordings, and there is no user-defined way of changing it. Manually renaming the files is not a great option either, as the MythTV database tables will be out of sync, making the MythTV frontend not work for these files.
So what are some options?
1) Add another User Job that executes after recording that renames the file, then also renames the entries in the database. The problem here is that LMCE move/rename/delete functionality would have to take into consideration MythTV's database.
2) Creat another directory full of Symbolic Links to the original files, but with human-readable names. This has the positive side that MythTV frontends will work as normal with no changes, but then you have the problem of keeping the symbolic links in sync with the actual files, considering they can be moved/deleted/renamed by both MytTV and LMCE. It would almost make sense to have the sym links created right in the appropriate /home/data/video directory used by LMCE, and have the symlinks added to the LMCE database instead of the original MythTV files. Again, the big problem here is sorting out the mess of keeping the symLinks in sync with the files knowing that there are 3 ways they could change (from MythTV, from LMCE, and from the OS level)
3) New Feature/Sourcecode change to MythTV that allows users to specify their recording filename format. However, this should be done on the MythTV end, and not applied as a patch as it would turn into a headache keeping up with MythTV releases. The good is that it would fix the problem, the bad is that it would need implemented of course.
Anyone else have some input on this?