Reply to thread

Message

<blockquote data-quote="MJGraf" data-source="post: 1123690" data-attributes="member: 17886">[Edit: Lehmden was faster with typing than me <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink&nbsp; &nbsp; ;)" loading="lazy" data-shortname=";)" />]Yep, there is <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin&nbsp; &nbsp; :D" loading="lazy" data-shortname=":D" />We already test it internally and so far it looks very well. However, we stumbled upon a bug that we already spotted a while ago in the NetworkNeighborhoodResourceAccessor (that's what is needed when you access media files on a Windows share). So it currently only works on local MediaSources. Additionally, it's still relatively slow as there is a lot of code in it that I want to test for future use and that code needs to be disabled.But we are nearly there!As to &lt;filenameandpath&gt;: This is unfortunately not as easy as it looks like. We currently look for video-files and if we found one, we check whether we can find a corresponding nfo-file. For supporting &quot;movie-stubs&quot;, we would have to import the nfo-file itself as a MediaItem into our library. This needs a different logic. But it wouldn't be too hard to implement it. However, we would have to adapt the frontend, i.e. MP2-Client, because currently it just tries to play the file that was imported as a MediaItem. This would obviously not work for nfo-files and so we need to introduce logic into our frontend that detects that the MediaItem is not an actual media file and that it needs to ask the user to insert dvd-x. That is certainly possible, but it will take longer and will therefore not be contained in the first release of this nfo-MetadataExtractor.Cheers,Michael</blockquote>

[QUOTE="MJGraf, post: 1123690, member: 17886"] [Edit: Lehmden was faster with typing than me ;)] Yep, there is :D We already test it internally and so far it looks very well. However, we stumbled upon a bug that we already spotted a while ago in the NetworkNeighborhoodResourceAccessor (that's what is needed when you access media files on a Windows share). So it currently only works on local MediaSources. Additionally, it's still relatively slow as there is a lot of code in it that I want to test for future use and that code needs to be disabled. But we are nearly there! As to <filenameandpath>: This is unfortunately not as easy as it looks like. We currently look for video-files and if we found one, we check whether we can find a corresponding nfo-file. For supporting "movie-stubs", we would have to import the nfo-file itself as a MediaItem into our library. This needs a different logic. But it wouldn't be too hard to implement it. However, we would have to adapt the frontend, i.e. MP2-Client, because currently it just tries to play the file that was imported as a MediaItem. This would obviously not work for nfo-files and so we need to introduce logic into our frontend that detects that the MediaItem is not an actual media file and that it needs to ask the user to insert dvd-x. That is certainly possible, but it will take longer and will therefore not be contained in the first release of this nfo-MetadataExtractor. Cheers, Michael [/QUOTE]

Verification