[ryamoo]

I've been doing some more digging and I'm not sure how to solve this. 

Kodi's URLEncoding uses lower case (so %2c), whereas Lighttpd's webdav (and general) encoding uses upper case characters (so %2C). 
For a library that began life using a webdav source, that's not an issue, because the library files will use the webdav responses (uppercase, %2C). 

However for path subtitution use cases, kodi will "store" the subtitution using lower case encoding (%2c) so when it checks for a file that contains encoding that has a character (rather than just numbers), then the check fails and kodi believes the file doesn't exist. 

I can't find a way to make lighttpd respond to the propfind request using lower case encoding for files - it doesn't seem possible without editing the source code, or I'm just not spotting it. 

I'm not sure if Kodi can encode using upper case, but maybe a solution could be to decode any web-based filenames, and then re-encode them and use that?

[ryamoo]

I've made the change locally.
*note, I've had to edit the code below to put a space between :: and string in the examples below, so it doesn't get interpreted as a smiley. Not sure how to stop that happening here. 

In URIUtils.h I've added the below so these can be called from DAVDirectory.cpp:

cpp:
  static std:: string URLEncodePath(const std:tring& strPath);

  static std:: string URLDecodePath(const std:tring& strPath);

In URIUtils.cpp I've amended lines 445 and 454 to add URIUtils:: to the above functions, so now they look like this and can be called from other places:

cpp:
std:: string URIUtils::URLEncodePath(const std:tring& strPath)

and

cpp:


std:: string URIUtils::URLDecodePath(const std:tring& strPath)

In DAVDirectory.cpp I've edited this function:

cpp:
bool CDAVDirectory::GetDirectory(const CURL& url, CFileItemList &items)

and amended line 150 from this:
     

cpp:
std:: string itemPath(URIUtils::AddFileToFolder(url2.GetWithoutFilename(), url3.GetFileName()));

to this:

cpp:
      std:: string itemPath(URIUtils::AddFileToFolder(

          url2.GetWithoutFilename(),

          URIUtils::URLEncodePath(URIUtils::URLDecodePath(url3.GetFileName()))));

That takes the filename element (eg, /TV/Series Names/Season 1/Episode File.mkv) and decodes it, then re-encodes it using Kodi's encoding format (lower case % encoding). 
So now when Kodi compares the path subsituted webdav filenames with the webdav directory listing filenames, everything mathes. And the webdav server doesn't care about encoding being in upper or lower, it all gets decoded the same. 

I've tested it on Windows, and tried to play back a few files that previously wouldn't play, and they all play fine. 
I don't know if opening up the encode/decode functions to other modules breaks anything, or if my other edits affect anything else. 

I've got a small new test library I created using the webdav as the original source, so that library has all original webdav paths with no subsitution. I'll swap libraries over and see if it presents any issues with this code change.

[ryamoo]

I kinda suspected it would break existing libraries that use webdav as their media source, and it does break it so my changes would not work there. 
I might just have to edit and compile my own versions or find another way of doing this.

Existing libraries have had the original webdav listing stored in the library using upper case encoding straight from the webdav server - so %2c for a comma, whereas Kodi is now replacing the webdav response with lower case encoding, and so the two don't match. 

I guess one solution would be to do the decode/encode to change case when the m_map.find() is done, so both values then have lower case encoding, but that's messy.
Or perhaps just decode for comparison? No, that wouldn't work because m_map.find is just searching through what's already been added to the map, and it's been added encoded, and no way to interact with it. 
Or maybe my changes above should occur in the next kodi version with a database change (I guess when Kodi 20 gets it's own database version), and de-code/re-encode during the migration? Just a thought.

[ryamoo]

I've posted this on the github issues:
https://github.com/xbmc/xbmc/issues/20194