2017-12-10, 12:26
No I didn't attempt Frodo, even going back to v15 was futile really, Kodi moves ever forwards...
The library scanning of metadata and resulting DB entries are fine. In fact this issue has little to do with the music library itself, more about the player and how the Kodi UI requests playback of something you have selected while navigating the music library.
The longstanding fault is that when the item sent to the player is a music library entry, parts of the player that want to be given a filename are given the VFS path instead (a fake path used by Kodi internaly that describes the library entry e.g. "musicdb://albums/3167/76277.flac?albumid=3167"). So some essential processing gets missed, but no one noticed this because the player is so clever that it adapts, and uses the first part of the file data to determine the file format that the other procedure failed to get. This works 99.99% of the time, hence it has been like it for years as far as I can tell. But there are some files, like the examples you have both given, that the ffmpeg parser can not do this trick for. Also changes to ffmpeg may impact the ability to rescue playback from this design mistake.
Ffmpeg should not be having to do this, the fix is to ensure that the procedure that needs the file name actually gets a filename. That sounds trivial, but I am finding it quite a challenge as I'm unfamiliar with the bowels of the player to FileItem interface.
(2017-12-10, 12:00)Geeeronimo Wrote: Also, since you're suspecting parsing problems, does it mean the Library parses the whole file, and not only the metadata ?No, you have misinterpreted my meager information, I will try to explain more because you are interested but it is hard if you are not familiar with Kodi code.
The library scanning of metadata and resulting DB entries are fine. In fact this issue has little to do with the music library itself, more about the player and how the Kodi UI requests playback of something you have selected while navigating the music library.
The longstanding fault is that when the item sent to the player is a music library entry, parts of the player that want to be given a filename are given the VFS path instead (a fake path used by Kodi internaly that describes the library entry e.g. "musicdb://albums/3167/76277.flac?albumid=3167"). So some essential processing gets missed, but no one noticed this because the player is so clever that it adapts, and uses the first part of the file data to determine the file format that the other procedure failed to get. This works 99.99% of the time, hence it has been like it for years as far as I can tell. But there are some files, like the examples you have both given, that the ffmpeg parser can not do this trick for. Also changes to ffmpeg may impact the ability to rescue playback from this design mistake.
Ffmpeg should not be having to do this, the fix is to ensure that the procedure that needs the file name actually gets a filename. That sounds trivial, but I am finding it quite a challenge as I'm unfamiliar with the bowels of the player to FileItem interface.
(2017-12-10, 12:00)Geeeronimo Wrote: On my side I tried another thing. I used fre:ac audio converter to convert from FLAC to FLAC, using the "fastest encoding" setting of the FLAC encoder. For some reason I don't understand, the output FLAC files are smaller in size than the input ones (why?). Then I imported these new files into Kodi Library, and they play fine.Yes, you have managed to remove whatever was different about the file, and the part of ffmpeg that does the "trick" is able to cope with the new one.
