Inconsistent checking of file paths in playlists
yoshiask opened this issue · comments
Describe the bug
Most playlist formats specify a list of URIs to music streams. In most cases, these URIs will be to local files the core already has in its track repository, but some formats allow links to external resources. For example, the HLS streaming extension for M3U/M3U8 uses https:// URIs to link to segments of a streamed track on the web. This feature is essential for supporting certain streaming services, such as Soundcloud.
The initial implementation of PlaylistScanner used helper methods designed to handle this transparently and gracefully, but it appears that at some point the code was refactored incompletely. The initial design used a few helper methods in PlaylistMetadataScanner, exposed by ResolveFilePath(string path, string currentPath). The sole purpose of this method was to get a full, absolute path given the current path. This was necessary because playlists often specify paths relative to the playlist file's location, so the path would have to expanded in order for the file to be played. At some point, the TryGetHashFromExistingTracks(Uri path, IEnumerable<Models.FileMetadata?> files) helper was added, which checks the list of files for one with a matching path. This means that all external/web resources will be rejected, because the audio metadata scanner could not have found it. (The same applies to local audio files outside the directory specified by the local files core, though that is a much more complicated issue because the core does not have immediate access to the file, unlike web resources that can easily be acquired.)
The new checks also have been applied inconsistently. For example, some parser methods use only TryGetHashFromExistingTracks, others use the old ResolveFilePath, while still others use the result of ResolveFilePath and pass that to TryGetHashFromExistingTracks.
Affected area
- Strix Music SDK
- Strix Music App
Regression
pre-alpha
Steps to reproduce
I don't think a specific repro is useful here, but in general any `https://` URLs in a playlist will be considered invalid and ignored.
Visual repro steps
No response
Expected behavior
PlaylistMetadataScanner should be able to recognize and handle external but still accessible resources, not only local and already scanned files.
Additional context
No response
Help us help you
Yes, I'd like to be assigned to work on this item.
https is definitely something we should support in the PlaylistMetadataScanner, especially considering that some files are pulled from the web directly and not locally (e.g. OneDrive)
@yoshiask I appreciate the volunteer to help with this one! I've assigned you to work on this.
Before you start working on this, let's get some unit tests set up around the PlaylistScanner for this specific thing. Once we've got that and the test is failing successfully, we can fix the bug and make the test pass. That way, we'll know right away if this breaks again.
Pinging @amaid as he has prior experience with the Playlist scanner. You can ask any questions in this issue or in the #strix-music channel of the UWPC Discord, whichever is more convenient.
At some point, the TryGetHashFromExistingTracks(Uri path, IEnumerable<Models.FileMetadata?> files) helper was added, which checks the list of files for one with a matching path. This means that all external/web resources will be rejected, because the audio metadata scanner could not have found it
It's just occurred to me that undoing this may not be an option. A playlist is just a list of tracks, and the core is the data source for those tracks. The core provides both tracks and playlists to whoever consumes it, and if the core doesn't know about the tracks (scanned audio files) then it can't return them in a playlist.
The playlist scanner checking known tracks first is by design, and undoing it would be a regression and cause other bugs.
If you can find a reproduceable bug that manifested because of our implementation, we'll have an easier time fixing this without accidentally creating a regression.