Can't play movies in STRM files generated from ISO format.

[blueyeti 1]

Hello, I've encountered a critical bug. Specifically, I generate STRM files from ISO format via the QMediaSync container, but when trying to play movies using strm 302, the STRM files generated from ISO format fail to play. Could you please look into this when you have time? I've attached the log link below.

paste.coreelec.org/TerrifyHester

kodi.log

[quickmic 1703]

Please send me the strm file

[blueyeti 1]

https://paste.coreelec.org/RoshmanPuncture

Edited December 5, 2025 by blueyeti

[blueyeti 1]

双子杀手 (2019) 2160p TrueHD Atmos.strm

 

strm file

[quickmic 1703]

1 hour ago, blueyeti said:

双子杀手 (2019) 2160p TrueHD Atmos.strm 80 B · 0 downloads

 

strm file

Thanks, I can see the strm includes a http link with no info about the content. This is probably the issue. Did you try the "follow http" option in the playback settings?

Edited December 5, 2025 by quickmic

[blueyeti 1]

I tried playing the strm file for the generated MKV movie, and it played normally.

[quickmic 1703]

And how about the iso's? Did you try change the setting?

Edited December 8, 2025 by quickmic

[blueyeti 1]

It is possible to play locally stored ISO format movies. How to set it up?

[GrimReaper 4739]

@blueyeti

Kindly do not use "Report Malicious" for troubleshooting purposes, you'll get all the assistance in respective topic.

Thanks

[quickmic 1703]

1 hour ago, blueyeti said:

It is possible to play locally stored ISO format movies. How to set it up?

Yes, but only if you have direct access to the file from Kodi (no http). Direct file access is not that easy to configure.

Basically, Kodi must play the iso (without the plugin at all). When you nailed this challenge, we can talk about Embyserver path substitution. However, this is the second step. 

Edited December 12, 2025 by quickmic

[forbxy 0]

On 2025/12/12 at PM7点35分, quickmic said:

是的，但前提是你能通过 Kodi 直接访问该文件（不能使用 HTTP）。直接文件访问的配置并不容易。

基本上，Kodi 必须能够播放 ISO 文件（完全不需要插件）。当你成功解决这个问题后，我们才能讨论 Embyserver 路径替换。不过，这只是第二步。 

I wrote a plugin to replace Kodi's HTTP and WebDAV VFS implementations, allowing Kodi to play HTTP and WebDAV ISO files. However, due to limitations in the Kodi plugin interface, the playback link for ISO files must end with a file extension. I had to modify the next-gen plugin to improve compatibility. I also fixed some bugs in version 12.3.7. Maintaining a long-term branch of next-gen might not be the best solution, but I don't know what else to do at the moment. Branch: https://github.com/forbxy/plugin.video.emby.vfs/tree/vfs
(Translated from Chinese to English by Google Translate)

[quickmic 1703]

I had a quick look into the code. As far as I can see, the core change is in common.py / def set_path_filename, right?

Seems you are detecting strm (http) content's file extension with a HEAD request for the actual filename so Kodi/the plugin can handle the content.

Not sure about the other modification you did e.g. in the player.py. Once the file extension is correct (e.g. with your modifications), the player should already handle iso.

Not sure why you disable nodes via "disableEmbyNodesVar" etc, but I think that's only minor changes. The core seems to be in def set_path_filename.

-> "redirect-limit=1000" has already changed in 12.4.X for artwork. btw, this is a Kodi protocol option and is necessary for content/webservice http redirects to keep the http timeout low, but prevent Kodi/http timeouts when a user interaction (selection box) must be open during the webservice (http) request. -> Kodi/http-response is delayed by user inpuy. The webservice is sending redirects to itself as a sort of "keepalive"

Edited February 2 by quickmic

[forbxy 0]

2 hours ago, quickmic said:

我快速浏览了一下代码。根据我所见，核心位于 common.py 的 def set_path_filename 函数中，对吗？

看来您正在使用 HEAD 请求来检测 strm (http) 内容的文件扩展名以获取实际文件名，以便 Kodi/插件可以处理内容。

不确定你对player.py文件做的其他修改。一旦文件扩展名正确（例如经过你的修改后），播放器应该可以处理ISO文件了。

我不确定你为什么要通过“ disableEmbyNodesVar”等方式消除节点，但我认为这只是最关心的问题。核心问题似乎出在 `def set_path_filename`函数中。

-> “ redirect-limit=1000”在12.4.X版本中已针对艺术作品进行了更改。顺便一提，这是一个Kodi协议选项，对于/Web服务HTTP重定向是必要的，它减少HTTP超时时间，同时可以防止在Web服务（HTTP）请求期间用户交互（选择框）必须保持打开状态时导致Kodi/HTTP超时。-> Kodi/HTTP响应会因用户内容而输入延迟。Web服务会向自身发送重定向，作为一种“保持连接”机制。

The main changes are in the `set_path_filename` function. I tried extracting the format from the strm file path or the URL path and parameters within the strm file, but this was very messy and didn't follow any public specifications. Using a HEAD request to get the final redirected URL was a last resort, but this is very expensive and makes the synchronization process extremely slow. I don't think this is suitable for implementation in the main repository. Perhaps I can maintain a branch that only contains the `set_path_filename` changes and regularly pull updates from the main repository. Below are my explanations for the other changes. There doesn't seem to be any code for version 12.4.x on GitHub, so I'm not entirely sure if these issues still exist.
1. Removed HTTP parameters: The VFS plugin actually takes over all HTTP link requests written by the next-generation Kodi database. Currently, the VFS plugin simply discards these parameters. Support for them might be considered in the future. Another reason is that this parameter makes the next-generation Kodi code difficult to understand, but this is just my personal opinion.
2. Fixed ClearLogo: The next-generation system seems to incorrectly cache video responses when making ClearLogo requests with HTTP Follow redirects enabled. https://github.com/forbxy/plugin.video.emby.vfs/commit/b1c2290f33ca7f89fb276ffd2eab71de42e2a726
3. Fixed STRM music: Made the STRM music library work the same way as the STRM movie library. However, this is a very niche requirement. https://github.com/forbxy/plugin.video.emby.vfs/commit/c7ceec4c0d8e691c8a6547afc9236f6bdebd0956
4. Saving playback progress for ISO files: Kodi needs to store the track information of Blu-ray discs in bookmarks (Kodi database - bookmarks - player state) to resume playback of ISO files. Currently, I store this information in `display_preferences`, but there might be a more elegant way. https://github.com/forbxy/plugin.video.emby.vfs/commit/5a4fb97b054b3098ab179bc696cb86be02104141
5. Fixed the issue where the cast list was not displayed on the TV show information page: the root cause was the missing `xxxx/http/tvshows/`. https://github.com/forbxy/plugin.video.emby.vfs/commit/75d9556e0e7b74cc21639da675b6977a84d7cdea
6. Fixed a memory crash issue when fetching TV series: `json.loads` used too much memory when fetching details of a single episode from a very large series library. A user reported this issue to me, and I confirmed it was a memory issue, but I haven't verified if this change is effective yet. https://github.com/forbxy/plugin.video.emby.vfs/commit/0bea0fe81f357a094f5e2a3c03a224da7332b84c
7. Fixed Emby library posters: Kodi does not support HTTP links for icons (tested on Windows Kodi 21.2). I also found that using `/emby_addon_mode/picture/` doesn't seem to trigger poster caching; perhaps downloading to `addon_data` first would be a better approach.
https://github.com/forbxy/plugin.video.emby.vfs/commit/e55b2a2eab487b8c71dd340a84ba96c190a4e77a
8. disableEmbyNodesVar: This is just a personal preference, but I want Kodi to remain unchanged after integrating Emby. https://github.com/forbxy/plugin.video.emby.vfs/commit/9eb28a032c98d7368806e111bc0bb21390d496df

Edited February 2 by forbxy

[quickmic 1703]

8 hours ago, forbxy said:

The main changes are in the `set_path_filename` function. I tried extracting the format from the strm file path or the URL path and parameters within the strm file, but this was very messy and didn't follow any public specifications. Using a HEAD request to get the final redirected URL was a last resort, but this is very expensive and makes the synchronization process extremely slow. I don't think this is suitable for implementation in the main repository. Perhaps I can maintain a branch that only contains the `set_path_filename` changes and regularly pull updates from the main repository. Below are my explanations for the other changes. There doesn't seem to be any code for version 12.4.x on GitHub, so I'm not entirely sure if these issues still exist.
1. Removed HTTP parameters: The VFS plugin actually takes over all HTTP link requests written by the next-generation Kodi database. Currently, the VFS plugin simply discards these parameters. Support for them might be considered in the future. Another reason is that this parameter makes the next-generation Kodi code difficult to understand, but this is just my personal opinion.
2. Fixed ClearLogo: The next-generation system seems to incorrectly cache video responses when making ClearLogo requests with HTTP Follow redirects enabled. https://github.com/forbxy/plugin.video.emby.vfs/commit/b1c2290f33ca7f89fb276ffd2eab71de42e2a726
3. Fixed STRM music: Made the STRM music library work the same way as the STRM movie library. However, this is a very niche requirement. https://github.com/forbxy/plugin.video.emby.vfs/commit/c7ceec4c0d8e691c8a6547afc9236f6bdebd0956
4. Saving playback progress for ISO files: Kodi needs to store the track information of Blu-ray discs in bookmarks (Kodi database - bookmarks - player state) to resume playback of ISO files. Currently, I store this information in `display_preferences`, but there might be a more elegant way. https://github.com/forbxy/plugin.video.emby.vfs/commit/5a4fb97b054b3098ab179bc696cb86be02104141
5. Fixed the issue where the cast list was not displayed on the TV show information page: the root cause was the missing `xxxx/http/tvshows/`. https://github.com/forbxy/plugin.video.emby.vfs/commit/75d9556e0e7b74cc21639da675b6977a84d7cdea
6. Fixed a memory crash issue when fetching TV series: `json.loads` used too much memory when fetching details of a single episode from a very large series library. A user reported this issue to me, and I confirmed it was a memory issue, but I haven't verified if this change is effective yet. https://github.com/forbxy/plugin.video.emby.vfs/commit/0bea0fe81f357a094f5e2a3c03a224da7332b84c
7. Fixed Emby library posters: Kodi does not support HTTP links for icons (tested on Windows Kodi 21.2). I also found that using `/emby_addon_mode/picture/` doesn't seem to trigger poster caching; perhaps downloading to `addon_data` first would be a better approach.
https://github.com/forbxy/plugin.video.emby.vfs/commit/e55b2a2eab487b8c71dd340a84ba96c190a4e77a
8. disableEmbyNodesVar: This is just a personal preference, but I want Kodi to remain unchanged after integrating Emby. https://github.com/forbxy/plugin.video.emby.vfs/commit/9eb28a032c98d7368806e111bc0bb21390d496df

Well, first things first. The goal is "set_path_filename" should detect the format. I can totally imagine that HEAD request slow down the scan dramatically. My pragmatic solution would be, adding the extension into the http url. You could simple attach a fake http param. I do that as well to keep Kodi happy. e.g. a link "http://192.168.1.75:12333/115/newurl?pickcode=dshx15rc6h2hox23l&userid=101314175" could be simply modified to "http://192.168.1.75:12333/115/newurl?pickcode=dshx15rc6h2hox23l&userid=101314175&stream.iso"

This usually has no impact as the url is still valid and, the server receiving this request, is also happy as all info are still there. If you use a generator for strm files, you could patch it or write a script to add it to existing strm files.

With this extension, Kodi, the server and the plugin set_path_filename has its data.

btw, 12.4.X is not in github, correct. 12.4.x is still public testing, only public an beta versions are in the repo to speed up the development process.

 

...more info later...

 

Edited February 2 by quickmic

[quickmic 1703]

Quote

1. Removed HTTP parameters: The VFS plugin actually takes over all HTTP link requests written by the next-generation Kodi database. Currently, the VFS plugin simply discards these parameters. Support for them might be considered in the future. Another reason is that this parameter makes the next-generation Kodi code difficult to understand, but this is just my personal opinion.

I totally agree, all these workarounds are unfortunately necessary due to Kodi limitations. One example, Kodi introduced native (internal) multiversion support by Kodi 21 and I thought, finally I can remove several of this nasty things in the plugin code, but guess what they did.

Supporting multiversions only for movies and I still need workarounds for episodes and musicvideos. That's a typical Kodi approach, they have no proper modular design. They must add/fix things on multiple spots in the Kodi code even if they providing more or less the same functionality. ...and don't get me started on the database design.

Also the API is very limited, callback are sometimes completely missing and the timing (triggers) is also bad.

Another example, Kodi has a database, but they are not storing playlists there. Instead they use m3u files. Actually I could live with that, but the m3u files has not access to the metadata in the database, even it's the exact same file. Therefore I had to duplicate/inject Songs/Videos in the database, to keep the order (tracknumber right) and get the metadata.

The same for favorites, but this way at least they use the metadata even the favorites are stored in xmls files and not in the database.

Another example, Kodi supports tags for video-content in the database, but not for episodes or seasons.

The musicdatabase is completely different and doesn't even support tags at all.

http redirections  where content changed e.g. from mp4 to hls: HTTP protocol is supporting it more or less correctly (it's a kinda broken but not fully broken), but DAV (which is actually the same as HTTP with some extensions) is not capable doing so. Same thing, different code in Kodi.

The list could go on and on, but I think you see my point.

... in the end, don't count on cleaner plugin code.

Edited February 2 by quickmic

[quickmic 1703]

Quote

2. Fixed ClearLogo: The next-generation system seems to incorrectly cache video responses when making ClearLogo requests with HTTP Follow redirects enabled. https://github.com/forbxy/plugin.video.emby.vfs/commit/b1c2290f33ca7f89fb276ffd2eab71de42e2a726

HTTPResponseCaches completely removed/rewritten in 12.4.X

Quote

4. Saving playback progress for ISO files: Kodi needs to store the track information of Blu-ray discs in bookmarks (Kodi database - bookmarks - player state) to resume playback of ISO files. Currently, I store this information in `display_preferences`, but there might be a more elegant way. https://github.com/forbxy/plugin.video.emby.vfs/commit/5a4fb97b054b3098ab179bc696cb86be02104141

Kodi should keep progress internally, but might be another Kodi limitation. On the very long term agenda, I might disable Kodi's progress tracking completely, and write it myself.

Quote

5. Fixed the issue where the cast list was not displayed on the TV show information page: the root cause was the missing `xxxx/http/tvshows/`. https://github.com/forbxy/plugin.video.emby.vfs/commit/75d9556e0e7b74cc21639da675b6977a84d7cdea

I need to check that but I think this is due your modification, and yes. Kodi also handels TVShows paths differently. They must follow a pattern (different as for movies etc). Actually this is another Kodi design flaw. They use the path as a "parent detection". TVShow -> Season -> Episode even if all required info are stored as IDs in the database (again an example doing the same thing in different ways).

Edited February 2 by quickmic

[forbxy 0]

In version 12.3.7, the ISO file appears to be using native mode. Based on the previous discussion, a parameter might be needed to determine whether the next-gen proxy address or the original address is written to the database.
Another issue is URL decoding; Next-gen systems should perhaps decode first and then encode, to avoid double encoding.
https://github.com/forbxy/plugin.video.emby.vfs/commit/8d6090b1acf18b99d250ec59a9f633b436fde591
https://github.com/forbxy/plugin.video.emby.vfs/commit/1e5d79e1c024f32a93acf30e7e3266759ef50a73

[quickmic 1703]

As I have no testcase, I can only give some advise.

To keep things straight, native mode does not necessary mean file access. It means, whatever Emby server reports as path is put into Kodi's database as path (on the right spots of course as there is not only one). If it's http url, sync the url into Kodi.

strm files are a bit different. The plugin tries to read the actual link in the strm file, and put that one into Kodi's database. I wouldn't be surprised if there are bugs, as you have several "layers" between the actual content and what Emby server reports.

My approach would be, forget the plugin during development. Use stock Kodi and put the urls/links directly in the sqlite database myvideoXXX.db. Kodi must be capable to play it, keep track of progress etc...everything. When you know what Kodi exactly expects, then we can think about the sync/upsync progress to Emby.

I'm quite sure, there are minimal changes required, when Kodi can handle the file from its database.