Add WebDAV provider

[OzGav]

WebDAV Provider Capabilities and Limitations

This provider extends Local File System Provider to support music libraries hosted on WebDAV servers. It supports tracks, albums, artists, single-file and multi-file audiobooks, and podcasts with full metadata parsing via ffprobe. Authentication is handled via Basic Auth with proper URL encoding of credentials containing special characters. The provider efficiently handles concurrent scanning with configurable semaphores and includes image discovery from folder structures.

Multi-file audiobooks use a custom streaming implementation (StreamType.CUSTOM) that calculates which chapter file to stream based on position without requiring ffmpeg to probe all chapter files over HTTP. This provides instant chapter switching and near-instant playback startup compared to StreamType.MULTI_FILE which can take minutes to probe 40+ HTTP-hosted files. Chapter metadata is cached during sync for fast lookup during playback.

The primary limitation is that seeking within individual audiobook chapters is not supported - users can only jump between chapters, not scrub within them. This tradeoff was intentional to avoid the HTTP probing delay. Single-file audiobooks and all other media types support full seeking via standard HTTP streaming. The provider matches the Internet Archive provider's approach for multi-file audiobooks, accepting the same seeking limitation for the same performance benefits.

[marcelveldt]

• multi part streaming has changed in core
• 80% of the code is redundant with filesystem provider

[marcelveldt]

Sorry, I cant accept this PR like this. 90% of the code is just a copy from the filesystem provider. If its written a bit smarter, then you can simply reuse most of the base implementation.

Because streaming and tags reading need access to the file anyways, I would suggest returning the (athenticated) webdav URL in the "resolve" function.

[OzGav]

Currently refactoring. Problems appear to be arising due to the base class using os.scandir

[marcelveldt]

Currently refactoring. Problems appear to be arising due to the base class using os.scandir

Well, if needed we can make some changes to the filesystem provider to make it more flexible ?

[marcelveldt]

BTW: It already looks loads better now! Only thing maybe is that also the sync and browse methods can be deleted and just use the base implementation, unless I'm missing something

[OzGav]

edit: OK I have a possible way ahead. I will look at submitting a completely revised PR in the next few days. Thanks as usual for your patience and pointers as I learn!

[OzGav]

Please have a look at the direction I am going. However, I may have hit a wall with podcasts and audiobooks but I havent had time to fully look at it. I would appreciate your thoughts on Claude's assessment

===========================================

You're right - it's an infinite loop. Look at the pattern:

Scans "Moby Dick" folder → finds 45 MP3 files
Processes first file → triggers _get_chapters_for_audiobook
_get_chapters_for_audiobook scans "Moby Dick" folder again → finds 45 files again
Processes each file → each one triggers _get_chapters_for_audiobook again
Infinite loop

The problem: The parent's _get_chapters_for_audiobook is designed for LOCAL filesystems where it can quickly re-scan a folder. For WebDAV, every scan is a network call, and it's processing ALL 45 files every time, each triggering another scan.
The solution: WebDAV needs to override _get_chapters_for_audiobook to prevent this. But this defeats the purpose of the refactor.
Actually, looking closer: The parent has logic to handle this with the IsChapterFile exception (when tags.track > 1). But it's not being raised properly because the files don't have proper track numbers in their tags.
This is why your old custom code worked - you handled multi-file audiobooks differently during the sync phase, caching chapters upfront and marking the folder as processed.
This refactor won't work cleanly for audiobooks/podcasts without significant additional complexity. The parent's design assumes local filesystem efficiency that doesn't translate well to network storage.
Recommendation: Keep the refactor for music only, but keep your custom audiobook/podcast processing from the original code.