Intermittent Playback Error with STRM Files: Inconsistent Behavior from WebDAV Source

[sunmagic 2]

Hello author, I've been struggling with an issue all day that I still haven't resolved, and it's really bothering me.  

In Emby, I used STRM files:  
Video 1:  
http://sun:sun@192.168.0.3:19798/dav/3.国剧/S/生万物 (2025)/Season 1/生万物.This.Thriving.Land.S01E36.2025.1080p.WEB-DL.H264.AAC-ColorTV.mkv  
Video 2:  
http://sun:sun@192.168.0.3:19798/dav/3.国剧/Z/足迹 (2025)/Season 1/足迹.Footprints.of.Change.S01E30.2025.1080p.WEB-DL.H264.AAC-ColorTV.mkv  

I am certain that:  
- Both files are fine, with consistent permissions and no encoding differences.  
- The URLs are correct.  

Now, the strange thing is:  
- Playing Video 1 gives an error: "An error occurred while processing the request. Please try again later."  
- Playing Video 2 works normally.  

I extracted logs from Emby and my WebDAV service(WebDAV service requires username and password authentication):  
- Both Video 1 and Video 2 made 3 requests each, but the results were different.  
- Other videos have similar issues. Sometimes, after restarting Emby, videos that couldn’t be played before start working, but some still don't.

I hope you can help me figure out what is causing the issue. I would be extremely grateful.

embyserver.txt webdav-2025-10-07.txt

Edited October 6, 2025 by sunmagic

[Abobader 3464]

Hello sunmagic,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[Luke 42077]

HI, maybe you're running into request limits with your webdav?

[sunmagic 2]

Hi, hello.
There should be no request limit on this WebDAV service. Today, I tried another WebDAV server using Synology NAS's WebDAV service, and Emby exhibited the same behavior—it also returned a 401 request error. When playing via a browser or the Emby Android app, the playback statistics and server would show "Recovering from playback error." However, when using the Emby Windows client, it directly prompts: "Playback Error. An error occurred while processing the request. Please try again later."

I shared the related error logs with an AI for analysis, and the response indicated that during the two types of authentication (scanning and playback), the scanning failed WebDAV authentication, while playback passed the authentication. Below are the three WebDAV access logs when playing a video. The first one, likely the scanning request, failed authentication, while the subsequent two requests with user_agent="Lavf/59.27.100" passed authentication:

[2025-10-07 11:46:42.203] module=webdav method=GET url="http://192.168.0.3:19798/dav/Emby_NAS/0.Movie/Swallowed.Star.S01E01.2020.1080p.WEB-DL.H264.AAC-ColorTV.mp4" client=::ffff:192.168.32.1:56184 status=401 error="Authentication required"
[2025-10-07 11:46:43.102] module=webdav method=GET url="http://192.168.0.3:19798/dav/Emby_NAS/0.Movie/Swallowed.Star.S01E01.2020.1080p.WEB-DL.H264.AAC-ColorTV.mp4" client=::ffff:192.168.32.1:56188 status=401 user_agent="Lavf/59.27.100" error="Authentication required"
[2025-10-07 11:46:44.604] module=webdav method=GET url="http://192.168.0.3:19798/dav/Emby_NAS/0.Movie/Swallowed.Star.S01E01.2020.1080p.WEB-DL.H264.AAC-ColorTV.mp4" client=::ffff:192.168.32.1:56192 status=206 username="sun" user_agent="Lavf/59.27.100"

I also suspected whether it was caused by the presence of Chinese characters in the path, so I switched to an all-English path, but the issue persisted.
The Emby logs are similar to the ones previously submitted, also showing that a 401 request result was received.

The log shows:

Initial Failure Phase (11:46:43)
Direct Play Failure: Attempt to directly access the original MP4 file returned 401 Unauthorized.
Error Response: Returned 500 Internal Server Error.

Automatic Recovery Mechanism Activated (11:46:43)
Session Management: The system automatically created a new playback session: cfa462918c86480b9145613803df6a85.
Transcode Decision: Due to the direct play failure, the system decided to enable transcoding.
Transcode Reason: TranscodeReasons=DirectPlayError.

Transcode Successfully Running (11:46:43-11:46:45)
Transcode command executed → HLS segments generated → Client successfully obtained video segments.

Stable Transmission Phase (11:46:45)
Continuous Success: The client continuously requested and successfully obtained multiple TS video segments.
Normal Response Time: Gradually decreased from 1509ms to 13ms, indicating a stable transcoding pipeline.

Does the above information help in identifying the issue? I look forward to your reply.

embyserver.txt

[sunmagic 2]

21 hours ago, Luke said:

HI, maybe you're running into request limits with your webdav?

Hi !

Could you help me take a look at this issue? I've updated the troubleshooting log below the post.

[Luke 42077]

The webdav url is returning a 401 unauthorized error. Can you find out why? Does it have logging?

[sunmagic 2]

3 hours ago, Luke said:

The webdav url is returning a 401 unauthorized error. Can you find out why? Does it have logging?

Hello, I think I've identified the issue, but I'd like to confirm it with you.

Let me describe my experimental setup first :

- On a Windows PC(192.168.0.2), I have installed: Emby Server(version 4.9.1.80)and the packet-capturing tool Fiddler.
- Emby media library directory: D:\Emby\Movie
- Content of the .strm file:    http://sun:sun@192.168.0.3:19798/dav/0.Movie/The.Lychee.Road.2025.1080p.mp4

I used Fiddler to capture the network requests when clicking "Play" in the Emby web interface.

My WebDAV server uses HTTP Basic Authentication.  
The normal WebDAV HTTP Basic Authentication flow should be:
1. First request: No authentication header → Server returns `401 Unauthorized`
2. Second request: With authentication header (Authorization: Basic ...) → Server returns `200 OK`

However, in the Fiddler capture logs, I only see the first request — there is no second request with the authentication header. This is likely the root cause of the playback failure.

The video playback error message "Recovered from error" suggests that Emby might have bypassed the issue by transcoding the stream via HLS, effectively avoiding direct access to the authenticated WebDAV resource.

I've attached relevant screenshots for your review. Could you please help me verify this analysis?
 

Edited October 7, 2025 by sunmagic

[sunmagic 2]

I conducted more omparative experiments.
The post above mentioned that Emby only sent one request, which might be because the Content-Type in the 401 response was empty, causing the Emby server to skip sending a second request (I wonder if this issue can be optimized in Emby. I will also contact the WebDAVS author to make corresponding optimizations).

The basis for this analysis is as follows: When I selected another Synology WebDAVS service(192.168.0.3:5005), Emby would send a second request, but there were two scenarios:

1. When the account password does not contain special characters,such as "@!", the Emby server's second request receives a 401 response from the WebDAVS service (which is the reason for the playback error I mentioned in my previous post).

2. When the account password contains special characters, the Emby server's second request receives a 200 response from the WebDAVS service.

Can this issue be optimized?



 

[Luke 42077]

OK I think there are cases where it's not using the credentials. I think this will be resolved on the next build of the beta channel in case you'd like to try that. Thanks.

[sunmagic 2]

On 10/9/2025 at 12:50 PM, Luke said:

OK I think there are cases where it's not using the credentials. I think this will be resolved on the next build of the beta channel in case you'd like to try that. Thanks.

I was genuinely excited about the beta release and installed it eagerly, only to discover that it remains unchanged, with the same issues still present. I really can't understand why there are cases where the second authentication request isn't sent. As a result, I've had to temporarily abandon using STRM links with WebDAV as a solution, leaving me feeling quite frustrated.

[Luke 42077]

On 10/9/2025 at 12:50 AM, Luke said:

next build of the beta channel in case you'd like to try that. Thanks.

 

[sunmagic 2]

23 minutes ago, Luke said:

 

Thank you for your endless patience in replying to me. You've given me renewed hope. I'll be eagerly looking forward to the next version, and will update and provide feedback as soon as possible.

[sunmagic 2]

On 10/10/2025 at 11:25 PM, Luke said:

 

Hello!
I upgraded to beta version 4.9.2.3 today, but unfortunately, the issue persists. I can only look forward to further optimizations.

Edited October 12, 2025 by sunmagic