[mythtv-users] ERROR: LocalFilePath unable to find local path for ...

[Michael T. Dean]

On 02/27/2017 05:50 PM, Brian J. Murrell wrote:
> So, I have a strange problem here with 0.28-fixes.  I have this
> recorded (table) entry:
>
> $ echo "select title,subtitle,basename from recorded where title = \"Arrow\" order by starttime;" | mysql -h pvr -u mythtv -p[redacted] mythconverg
> title	subtitle	basename
> Arrow	Invasion!	Arrow: S05E08 - Invasion! (3).mkv
>
> Yes, the basename really is "Arrow: S05E08 - Invasion! (3).mkv"[1] and
> the file does exist:
>
> -rw-rw-r-- 2 mythtv mythtv 1.1G Dec  7 08:03 Arrow: S05E08 - Invasion! (3).mkv
>
> This all seems to work fine for some clients including the official
> Myth FE client and Daniel's Android client.  Kodi 16/17 (myth.pvr
> addon) clients (which use mythcpp) however have some strange issue
> where the "ANN FileTransfer" is getting a "filetransfer_filename_empty"
> response and the BE log reports:
>
> ERROR: LocalFilePath unable to find local path for 'arrow: S05E08 - Invasion! (3).mkv'
>
> Notice that the name in the error message has the first letter lower-
> cased and indeed, if I rename (or create a hardlink) to the name as it
> is in the error message, the Kodi 17 (cppmyth) clients work.
>
> For a client that works the protocol exchange looks like this:
>
>> 30      MYTH_PROTO_VERSION 88 XmasGift
> < 13      ACCEPT[]:[]88
>> 85      ANN FileTransfer localhost 0 0 1000[]:[]Arrow: S05E08 - Invasion! (3).mkv[]:[]Default
>> 25      OK[]:[]102[]:[]1074011455
>> [file contents]
> For a client that doesn't the protocol exchange looks like this:
>
>> 30      MYTH_PROTO_VERSION 88 XmasGift
> < 13      ACCEPT[]:[]88
>> 85      ANN FileTransfer localhost 0 0 1000[]:[]Arrow: S05E08 - Invasion! (3).mkv[]:[]Default
> < 37      ERROR[]:[]filetransfer_filename_empty
>
> I don't see any difference.  It does seem to be asking for the correct
> file so I can't see why the BE is not finding it and is reporting an
> error with the file it was looking for with it's first letter lower-
> cased.
>
> Any ideas?
>
> Cheers,
> b.
>
> [1] Just because I know people will want to know how/why, post-
> recording, I have a job which transcodes my recordings to .mkv and
> renames them something more meaningful than the default format.

FWIW, this general problem is why we stopped the plan to support 
user-definable/user-specifyable/prettier(even if still a single format) 
file names for recording files.  Specifically, different file systems 
have different allowable file name requirements (involving length, 
permitted characters, ability to handle non-ASCII characters and/or 
non-en_US character sets) and different protocols have different 
requirements for characters and escaping and such. However numbers, 
underscore, and a simple all-ASCII/en_US file extension are easily 
supported on all known file systems and protocols in use.

I'm sure there's something that can be done to make things work for you 
(if nothing else, on your system), but the idea of supporting renamed 
recording files isn't likely to work--users shouldn't be required to 
learn the intimate details of file system naming requirements just to 
use MythTV.  So, as a compromise, links to 
named-using-the-internal-default-format files are meant to provide 
user-friendly file names (and have the huge benefit of being able to 
provide multiple different formats (i.e. for different sorting) of 
friendly file names).

I don't know what's going on specifically here, and if it is a bug in 
MythTV (from some improper toLower() or whatever), it should be fixed.  
We do appreciate your noticing the issue, and digging into it, and if 
you find a bug, please report it.  However, I just wanted to give you 
(and anyone else reading the thread) some idea of why we're still using 
"ugly" file names in MythTV.  It's not so much that it can't be done 
differently, but that it's not worth the time required to develop, 
debug, and--especially--maintain (as file systems and protocols change 
and/or are added) and, most importantly, we want MythTV to just work for 
users regardless of their file system(s), locale settings, etc., rather 
than requiring them to become tech experts on a bunch of topics before 
they can use MythTV successfully.

Mike