[ryamoo]

Posted here because I'm not sure this is specific to Android (my client) or Raspberry Pi (my server). I'll test it on a Windows client later.
May also be a known drawback of webdav via substitution that I'm not aware of.

Library files containing a comma in the path played on Android TV's Kodi via a WebDAV server using path substitution cannot be played (Kodi says file not found).
This only happens when playing via the library - if I go to the WebDAV source via the "Videos" menu, and using WebDAV as a media source, the files play fine without issues.

My setup:
- Media stored on Raspberry Pi.
- Kodi 19 running on same raspberry pi, maintaining library, SQL server for library.
- File servers set up for NFS, FTP, SMB, and recently WebDAV (trying to improve 2160p x265 local streaming).

- Android TV, running Android 9.
- Kodi 19.1 installed via Play Store.
- Advanced settings file contains Path substitution from raspberry pi path (/mnt/2tb2) to server path (WebDAV://user:password@Pi-ip/webdav <- points to /mnt/2tb2) - this works fine, has worked fine for FTP, NFS, SMB, and most files via WebDAV.

Episodes of Jimmy Fallon's The Tonight Show contain commas separating the guest names - issue occurs.
Movies that have a prefix such as "The", with a folder format of "Movie, The" - issue occurs.
Other TV show episodes containing a comma in the folder or filename - issue occurs.
Any movie or TV show that doesn't contain a comma anywhere in the path - no issue, file is played.

Not got a logfile yet - will install the plugin after this show and upload one.
Will test if the issue occurs on windows too.
For now, I've swapped back to FTP instead of webdav.

[ryamoo]

Posted here because I'm not sure this is specific to Android (my client) or Raspberry Pi (my server). I'll test it on a Windows client later.
May also be a known drawback of webdav via substitution that I'm not aware of.

Library files containing a comma in the path played on Android TV's Kodi via a WebDAV server using path substitution cannot be played (Kodi says file not found).
This only happens when playing via the library - if I go to the WebDAV source via the "Videos" menu, and using WebDAV as a media source, the files play fine without issues.

My setup:
- Media stored on Raspberry Pi.
- Kodi 19 running on same raspberry pi, maintaining library, SQL server for library.
- File servers set up for NFS, FTP, SMB, and recently WebDAV (trying to improve 2160p x265 local streaming).

- Android TV, running Android 9.
- Kodi 19.1 installed via Play Store.
- Advanced settings file contains Path substitution from raspberry pi path (/mnt/2tb2) to server path (WebDAV://user:password@Pi-ip/webdav <- points to /mnt/2tb2) - this works fine, has worked fine for FTP, NFS, SMB, and most files via WebDAV.

Episodes of Jimmy Fallon's The Tonight Show contain commas separating the guest names - issue occurs.
Movies that have a prefix such as "The", with a folder format of "Movie, The" - issue occurs.
Other TV show episodes containing a comma in the folder or filename - issue occurs.
Any movie or TV show that doesn't contain a comma anywhere in the path - no issue, file is played.

Not got a logfile yet - will install the plugin after this show and upload one.
Will test if the issue occurs on windows too.
For now, I've swapped back to FTP instead of webdav.

I don't think I can edit my post.
I've tried webdav on Kodi for windows and the issue with library paths containing a comma played via webdav and path subsitution also happens there. 

Here's the logfile from Android TV: https://paste.kodi.tv/lanaqavuha
I enable debug logging, enabled component logging for database and curl, quit, relaunched, tried to play the episode with Benedict.Cumberbatch (You can find it in the log by searching that) - kodi says playback failed:


If I try to play a problem file after that I get told the file is no longer available: 

[ryamoo]

[ryamoo]

http/1.1 vs http/2 doesn't make a difference to playback. 
I've updated lighttpd to a later version that supports http/2, and added some self signed certificates and enabled ssl. 
The outcome is still the same - anything with a comma (,) in the path will not play.

[Klojum]

I don't think I can edit my post.

That is because of it is part of the active antispam measures on this forum. Your edit powers will come in due course.
BTW, quoting your post feels a bit unnecessary to me. Just start a new post until you can use the edit function.

[wsnipex]

comma is a reserved character (used as sub delimiter)

[ryamoo]

BTW, quoting your post feels a bit unnecessary to me. Just start a new post until you can use the edit function.

I agree. I did realise, and simply replied afterwards.

[ryamoo]

comma is a reserved character (used as sub delimiter)

Thanks - I think that gives me something to work with. I think I saw something in the lighttpd docs for http parseopts mentioning reserved characters so I'll check that out and see if it helps.

Short of any renaming all my media, any thoughts on how else I might work around this (if the above parseopts doesn't work)?
I may end up just ditching WebDAV I guess, but it's been the best for responsiveness so far.

[wsnipex]

Having the webserver urlencode such chars should work. I don't really see an easy fix on the kodi side, because this goes deep into url parsing and kodi library.

[ryamoo]

I've tried a couple of things.

Code:

dir-listing.encoding = "utf-8"

I added that because if I browse the webdav server via chrome, an apostrophe in the filename on directory view was being displayed like the below. 
  - that should say "Didn't.Laught,.You'd.Cry". Adding the above, meant it displayed correctly when browsing, but that doesn't affect how it interpret's what kodi requests. 

I've then added this:

Code:

server.http-parseopts = ( "url-normalize-required" => "enable" )

It doesn't get the problematic files to play, but attempting to play some of them will cause kodi to get stuck trying to play it (spinning icon, but player doesn't open). If I try to Stop it from the "Options" slideover, kodi locks up. 

My hunt continues...

[ryamoo]

What's the difference between the requests when coming from a library file, versus a Videos/media source file? 
If I try to play the file through the library, i get the error and it doesn't play.
If I go to the Videos menu, then the media sources and select the same webdav share, then the file play fine without issues. That's without any "parseopts" on the server too. 

Could the request to the webdav server be getting jumbled when path subsitution is used?

[ryamoo]

Slight correction - the files play via media sources (instead of the library), but Stopping them sometimes causes kodi to freeze/not respond.

[ryamoo]

I've been comparing logfile for lighttpd for requests for the file when playing via library, and requests when playing via files/media sources. 
The requests appear to be the same - the commas (and apostrophes) all get requesting using the same URI, and lighttpd cleans them all to the same string. 
Looking back at my Kodi log, it even looks like the request comes back ok - there's an initial "401 unauthorised" response and it seems that's because Kodi is requesting the path without authorisation first, then there's a request straight after with authentication, and that returns "200 ok". 

So I'm not sure I can do anything with the lighttpd server, because all requests appear to come in and go back out the same, whether it's for library playback (which isn't playing) or media source playback (which is working). 

I might test it and backup my kodi folder, start a new local library with the webdav server as the source, and scan content and see if it plays back. 
If that works, then I guess it might be to do with path subsitution and webdav being used together.

[ryamoo]

I've tested that, using webdav server as a new library's content, so it accessed the webdav server directly to scan new content to the library, and didn't use the path subsitution (from a different Kodi with the media stored locally, scanning locally). 
The problematic files play fine, so it only fails when it tries to play them with path subsitution in place. 
Not sure that's something I can fix myself.

[ryamoo]

I think this may be a CASE issue with the encoded webdav filenames/paths and path subsitutions. Encoded % characters are sometimes in lower case (%e2 for example), and sometimes in upper case (%E2). 
m_map.find() is case sensitive, so the find fails even though m_map contains the file (but with upper case encoded characters). 

Bare with me here, because I'm not a developer, and I don't know C++, so I might not know the right terms and names for things, but I can follow logic, so the below will be messy. 

I've spent the last few days adding LOGDEBUG lines in the source to trace the error and googling what I needed to know in C++ to be able to get here. 

I narrowed it down to:

cpp:
bool CFileItemList::Contains(const std:tring& fileName) const

in "FileItem.cpp" returning

cpp:
false

because of the m_map.find() looking for a filename with lowercase URI encoding, as opposed to the upper case encoding contained in the filenames in m_map.

That was called from: 

cpp:
return (URIUtils:: PathEquals(strPath, storedPath) || dir->m_Items->Contains(strFile));

(beware the extra space before PathEquals - added to stop it putting a smiley in)
in function:

cpp:
bool CDirectoryCache::FileExists(const std:tring& strFile, bool& bInCache)

in file DirectoryCache.cpp
Which is in turn called by this line:

cpp:
if (g_directoryCache.FileExists(url.Get(), bPathInCache))

in function:

cpp:
bool CFile::Exists(const CURL& file, bool bUseCache /* = true */)

in file File.cpp. 

I've lost track at that point, can't remember how I got there. 

In this function:

cpp:
bool CFileItemList::Contains(const std:tring& fileName) const

in "FileItem.cpp" I put in a 'for' loop to LOGDEBUG the m_map strings (some iterating, and logging "it->first") because that's where the various "fileexists" functions were looking for the path. 
For files with a comma or apostrophe in the path, it was looking for filenames with %e2 and %2c (lower case letters), however in m_map they were listed as %E2 and %2C (upper case letters). 
So I googled some more, and found how to replace the lower case with upper case, and ended up doing a string.replace on the occurences in the string. 

After that, and another build (lost count of how many times I've built!), and the problematic files play. Success! 
I've no idea why the encoded characters in the filename it's searching for are lower case, and in m_map entries they are upper case. That'll have to be for someone else to look into... 
I can't share my logs, because I didn't use GetRedacted, so my usernames and passwords are in there, and I'm not sure the logs would be any good to you anyway with my rambling debug entries. 
If there's any more info I can provide, I'll try. If I need to be logging this on github issues, let me know. 
If this is a known issue or something, that would be cool to know too.