Doesn't work with Infuse App
Wamy-Dev opened this issue · 9 comments
Describe the bug
When hosting a webdav using wsgidav, and connecting using the Infuse app (Mac or iOS), it sends a propfind to /, with a depth of 1. This returns the folders properly, but they are seen as files on Infuse. I have tried other webdavs with Infuse and they all work fine. The folders are seen as files.
To Reproduce
Host webdav
Add to Infuse
Connect on Infuse
Expected behavior
Being able to navigate folders to files.
Which WSGI server was used (cheroot, ext-wsgiutils, gevent, gunicorn, paste, uvicorn, wsgiref, ...)?
Any, though tested with cheroot and uvicorn.
Which WebDAV client was used (MS File Explorer, MS Office, macOS Finder, WinSCP, Windows, file mapping, ...)?
Infuse (sees folders as files), Finder (works fine), Windows (works fine), Linux (works fine)
I have already contacted Infuse, they basically told me that they cannot fix it.
Hi,
please reproduce the problem while running the client in verbose mode (-vv) and share the logs
(make sure to not include sensitive data like credentials)
16:24:16.136 - INFO : Got OPTIONS '/' request
16:24:16.648 - INFO : 100.107.73.41 - (anonymous) - [2024-03-07 22:24:16] "PROPFIND /" length=153, depth=1, elap=0.512sec -> 207 Multi-Status
It seems to only fail when I am using files from Rclone mount. I guess I never tested with local files. I am going to try figuring out about the permissions.
This is a weird issue. Sending a PROPFIND request using an http tester (postman, insomnia) just never yields a response.
Here's some more information. For a large directory (with over 100k files in total), it seems like the propfind just takes FOREVER. I waited about 10 minutes and it was still loading.
I'm slowly figuring things out, when using a smaller directory, it loads fast, but this is the response:
<?xml version='1.0' encoding='UTF-8'?>
<D:multistatus
xmlns:D="DAV:">
<D:response>
<D:href>/</D:href>
<D:propstat>
<D:prop>
<D:resourcetype>
<D:collection/>
</D:resourcetype>
<D:creationdate>2024-02-18T16:58:38Z</D:creationdate>
<D:quota-used-bytes>0</D:quota-used-bytes>
<D:quota-available-bytes>1125899906842624</D:quota-available-bytes>
<D:getlastmodified>Sun, 18 Feb 2024 16:58:38 GMT</D:getlastmodified>
<D:displayname>0a3a8b769669be92dc6b6433fdf3d61df142b437</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/XXXFOLDERXXX/</D:href>
<D:propstat>
<D:prop>
<D:resourcetype>
<D:collection/>
</D:resourcetype>
<D:creationdate>2024-02-17T16:59:32Z</D:creationdate>
<D:quota-used-bytes>0</D:quota-used-bytes>
<D:quota-available-bytes>1125899906842624</D:quota-available-bytes>
<D:getlastmodified>Sat, 17 Feb 2024 16:59:32 GMT</D:getlastmodified>
<D:displayname>XXXFOLDERXXX</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/XXXFOLDERXXX/XXXITEMXXX.mkv</D:href>
<D:propstat>
<D:prop>
<D:resourcetype></D:resourcetype>
<D:creationdate>2024-02-17T16:59:32Z</D:creationdate>
<D:getcontentlength>30931047</D:getcontentlength>
<D:getcontenttype>video/x-matroska</D:getcontenttype>
<D:getlastmodified>Sat, 17 Feb 2024 16:59:32 GMT</D:getlastmodified>
<D:displayname>XXXITEMXXX.mkv</D:displayname>
<D:getetag>11658933646639649267-1708189172-30931047</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/XXXFOLDERXXX/XXXITEMXXX.mkv</D:href>
<D:propstat>
<D:prop>
<D:resourcetype></D:resourcetype>
<D:creationdate>2024-02-17T16:59:32Z</D:creationdate>
<D:getcontentlength>5077136691</D:getcontentlength>
<D:getcontenttype>video/x-matroska</D:getcontenttype>
<D:getlastmodified>Sat, 17 Feb 2024 16:59:32 GMT</D:getlastmodified>
<D:displayname>XXXITEMXXX.mkv</D:displayname>
<D:getetag>10955713599619190573-1708189172-5077136691</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>What Infuse shows is simply:
XXXFOLDERXXX
It doesn't show anything deeper. The request that was received from Infuse is this:
16:59:06.167 - INFO : 100.107.73.41 - (anonymous) - [2024-03-07 22:59:06] "PROPFIND /" length=153, depth=1, elap=0.001sec -> 207 Multi-Status
While the request from Insomnia (http tester) was:
16:58:54.255 - INFO : 127.0.0.1 - (anonymous) - [2024-03-07 22:58:54] "PROPFIND /" depth=infinity, agent="insomnia/2023.5.8", elap=0.003sec -> 207 Multi-Status
It seems like this is an Infuse issue more and more. I tested with some local file directories that had video inside, and it seems like Infuse simply does not dive into directories at all. I'm gonna close this, sorry for my rambling. Seems like it is an Infuse issue as I suspected. I will see if their forums will be a little more helpful. If you have any more insight on how I can force Infuse to use a depth of infinity instead, please let me know.
@Wamy-Dev can you test wsgidav with Kodi, please? Kodi fails to scan files when I'm using basic/digest authentication, but works with anonymous. I tried with another WebDAV server, Kodi works with authentication just fine.
Kodi says:
2024-08-03 14:48:53.274 T:5212 error <general>: CCurlFile::XFILE::CCurlFile::Stat - <dav://USERNAME:PASSWORD@192.168.1.101:8080/Download/Videos/Movies/Leo%20(2023)/> Failed: Unsupported protocol(1)WSGIDAV says:
14:48:55.647 - INFO : 192.168.1.100 - (anonymous) - [2024-08-03 08:48:55] "HEAD /Download/Videos/Movies/Leo (2023)/" elap=0.001sec -> 401 Not Authorized
14:48:55.659 - INFO : 192.168.1.100 - (anonymous) - [2024-08-03 08:48:55] "PROPFIND /Download/Videos/Movies/Leo (2023)/" depth=1, range=bytes=0-, elap=0.001sec -> 401 Not Authorized
14:48:55.661 - INFO : 192.168.1.100 - RGX - [2024-08-03 08:48:55] "HEAD /Download/Videos/Movies/Leo (2023)/" elap=0.006sec -> 200 OK
14:48:55.688 - INFO : 192.168.1.100 - RGX - [2024-08-03 08:48:55] "PROPFIND /Download/Videos/Movies/Leo (2023)/" depth=1, range=bytes=0-, elap=0.020sec -> 207 Multi-Status
14:48:55.701 - INFO : 192.168.1.100 - (anonymous) - [2024-08-03 08:48:55] "PROPFIND /Download/Videos/Movies/Leo (2023)/" depth=1, range=bytes=0-, elap=0.001sec -> 401 Not Authorized
14:48:55.729 - INFO : 192.168.1.100 - RGX - [2024-08-03 08:48:55] "PROPFIND /Download/Videos/Movies/Leo (2023)/" depth=1, range=bytes=0-, elap=0.016sec -> 207 Multi-StatusCan you please test it for me? I'm kind of a newb in this and I need some help from someone.
Yeah, Kodi was one that I tested before, you need to make sure you use "dav://username:password@hostname:port" or "davs://username:password@hostname.com" (If SSL protected).
You can't use HTTP(S) cause then it just uses the website, which works entirely differently.
I know your log says that you are using dav, but other than that, make sure the auth is 100% correct.
Yeah, Kodi was one that I tested before, you need to make sure you use "dav://username:password@hostname:port" or "davs://username:password@hostname.com" (If SSL protected).
You can't use HTTP(S) cause then it just uses the website, which works entirely differently.
I know your log says that you are using dav, but other than that, make sure the auth is 100% correct.
The auth is correct, I can browse my media files in Kodi. It's only when I'm scraping. And I don't understand why, but I narrowed it down to a server issue. Because I tried with another DAV server, hosted in mixplorer with same credentials, and the unsupported protocol issue was nonexistent.
Will you be able to check one more time, if it works for you?
If it works without the unsupported protocol issue, can you share your .yaml config file with me, please? I'm using the sample_wsgidav.yaml and modified username, password, and folder paths. And everything else is untouched.