If you fill in the LAN network path, it cannot be played in the WAN

[wxg1015 9]

emby theater  windows  desktop 

When the network path filled in on the emby server cannot be accessed by emby theater (for example, fill in the LAN path, but use emby theater to connect and play the movie on the external network) emby theater will always buffer but not play. May be related to mpv?  Because uwp emby theater does not have this problem and the Android client

Edited September 20, 2021 by wxg1015

[Luke 40137]

Hi, what path do you mean exactly?

[wxg1015 9]

I mean, when I fill in the absolute path and the absolute path is inaccessible, when I select the movie to be played, it will keep spinning but cannot be played unless I delete the absolute path

[wxg1015 9]

path？For example, nfs://192.168.0.10/movie, but when my client is not in the LAN, it will always load but cannot be played.

[wxg1015 9]

让我简要地说。我的媒体库填写了图中显示的网络路径。当我的播放设备在同一局域网上时，一切都很正常。当播放设备不在同一个局域网中时，它将无法播放。

[Happy2Play 9458]

Please refrain from using the Report button unless there is a issue with the post.  You should quote or tag the dev.  Will tag @Lukefor this as I am not sure this optional path will work.

[wxg1015 9]

Sorry, I seem to understand it wrong. Thank you for your reminder. 

Edited September 22, 2021 by wxg1015

[wxg1015 9]

On 9/20/2021 at 10:48 PM, Luke said:

Hi, what path do you mean exactly?

One sentence summary is "the wrong or unreachable network path will cause emby theater to not be able to play movies unless you don't fill in any content."

[wxg1015 9]

On 2021/9/20 at PM10点48分, Luke said:

你好，你说的具体路径是什么？

Well, I did some more tests. I found that not all movies will be affected, only those sub-directory names or movies that contain Chinese in the movie name will be affected. The specific performance is that the movie is loaded but cannot be played, or only audio is played. When I delete the network address, everything becomes normal

[wxg1015 9]

On 9/22/2021 at 9:56 AM, Happy2Play said:

Please refrain from using the Report button unless there is a issue with the post.  You should quote or tag the dev.  Will tag @Lukefor this as I am not sure this optional path will work.

Uh, why no one responded to this topic

[Luke 40137]

It's supposed to try the network path first, then stream through the server if it can't be reached. It must be getting hung up there somewhere. We'll look into it. Thanks.

[Luke 40137]

I've updated the test build here with a fix if you'd like to try that:

Thanks.

[wxg1015 9]

2021年9月28日上午12：12，卢克说：

如果您想尝试，请在此处更新了测试构建程序：

谢谢。

问题仍然存在

[wxg1015 9]

On 9/28/2021 at 12:12 AM, Luke said:

I've updated the test build here with a fix if you'd like to try that:

Thanks.

The problem is still

[SmileFlower 21]

On 9/28/2021 at 12:12 AM, Luke said:

I've updated the test build here with a fix if you'd like to try that:

Thanks.

It is recommended to ignore the network path and use the physical path directly, so that the loading speed will be fast

[wxg1015 9]

3 minutes ago, SmileFlower said:

It is recommended to ignore the network path and use the physical path directly, so that the loading speed will be fast

This is not a question of speed, but a question of whether you can play. My kodi needs this way

你说的这些 我当然知道  没有这个绝对路径  就没有任何问题

[Happy2Play 9458]

6 minutes ago, SmileFlower said:

It is recommended to ignore the network path and use the physical path directly, so that the loading speed will be fast

Not all clients have access to the filesystem so the optional shared network path can assist with that to allow "file" direct play instead of "http" direct play.

[wxg1015 9]

4 minutes ago, Happy2Play said:

Not all clients have access to the filesystem so the optional shared network path can assist with that to allow "file" direct play instead of "http" direct play.

But now when the path contains Chinese, there will be a problem that it cannot be played     et desktop

[wxg1015 9]

5 minutes ago, Happy2Play said:

Not all clients have access to the filesystem so the optional shared network path can assist with that to allow "file" direct play instead of "http" direct play.

et uwp does not have this problem

[SmileFlower 21]

9 minutes ago, Happy2Play said:

Not all clients have access to the filesystem so the optional shared network path can assist with that to allow "file" direct play instead of "http" direct play.

The local physical path can be accessed first, and the timeout may be better when accessing the network path

[SmileFlower 21]

11 minutes ago, Happy2Play said:

Not all clients have access to the filesystem so the optional shared network path can assist with that to allow "file" direct play instead of "http" direct play.

This is also because of the same problem encountered in the network path. I hope the development team can pay attention to it. Thank you

[wxg1015 9]

The problem has been solved. Someone has fixed the problem. End it

[Luke 40137]

4 hours ago, wxg1015 said:

The problem has been solved. Someone has fixed the problem. End it

Hi, what do you mean? What was the solution? Or are you saying it's just all of a sudden working now?

[SmileFlower 21]

4 hours ago, Luke said:

Hi, what do you mean? What was the solution? Or are you saying it's just all of a sudden working now?

Using webdv instead of NFS is fine

 

Or delete the network share path

Edited November 18, 2021 by SmileFlower

[Luke 40137]

OK thanks for the update.