This update broke my WebDav connection. I verified by comparing versions on my Mac vs my updated Apple TV versions. Apple TV’s do not work. I was able to stop the update on my one Apple TV, so it still works on 8.5 however 2 Apple TV’s that automatically updated to the newest release no longer can play media from my webdav, they just error out with the generic firecore media message. I strongly advise to not update if you are running a webdav that doesn’t have connectivity issues right now.
If you’re able to drop us a quick note from your device we can look further into this.
I submitted a ticket and included diagnostic code as a follow up to the email. thanks for looking into it if possible.
Thanks for sharing those logs.
It looks like this server is doing a few things in a non-standard way. These behaviors weren’t explicitly supported in previous versions of Infuse either, but they happened to work by chance.
We’ll be making one specific adjustment that should address the most obvious issue. Though in the long term, it would probably be a good idea to make some changes on the server side so it behaves in a more standard and predictable way.
I’ll send some additional details via PM.
Why is Infuse unable to play a .m3u8 link? I get an error whenever I paste the link into Infuse.
m3u8 files are not yet supported, but support for these will be added in an upcoming version.
I was able to reproduce this while watching the Zurg WebDAV server logs. When Infuse fails, Zurg logs Not implemented: PROPFIND /dav/movies/movies/ and Not implemented: PROPFIND /dav/shows/shows/. The root PROPFIND /dav/ works and returns 207 Multi-Status. It appears Infuse 8.5.1 is requesting these nested paths, which Zurg doesn’t implement. Could this be the behavior you were referring to?
I ended up troubleshooting and resolving on my end. I’ve set up a more traditional WebDAV, rather than relying on Zurgs implementation of it. I’m guessing that was the “non-standard way” you were describing. All is fixed for me, but hopefully this at least helped in some way.
Thanks for sharing that info. It’s helpful to know and may allow us to make a few more tweaks, but it wasn’t the main issue Infuse 8.5.1 was hitting.
Infuse uses range requests to access files over WebDAV and has some logic to fallback to another method if the server doesn’t have support for these. What was happening here is the server was returning HTTP 200 but with a valid Content-Range. This isn’t standard behavior: the server should either return the full file with 200 or the requested range with 206. We currently don’t handle this case, which causes playback errors. Previous versions of Infuse didn’t explicitly handle it either, but it happened to work by chance.
We’ll add support for handling Range requests that return HTTP 200 in the next update so these files can be played.
There are a few other issues we observed in the logs which don’t affect playback in Infuse, but I guess are not ideal.
- Many GET requests return HTTP 423 Locked. This appears to be a server-side issue - we don’t lock files ourselves. Unfortunately, the logs don’t show what is locking the files.
- Many requests for file contents return 404 right after the parent folder contents are received. It looks like the server is returning entries for files that don’t actually exist. This doesn’t affect playback, but it results in unnecessary requests.
This has been resolved in today’s 8.5.2 update: 