support relative paths when loading DBPL playlists #3115
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oleksiy-Yakovenko
requested changes
Aug 24, 2024
This seems like some sort of test setup problem. I'm sure I'll be able to figure it out, but I'm a bit time constrained in the next few weeks. |
- dynamically allocate memory instead of big stacks - treat legacy and metadata URI values equally
now we just need one alloc/free per playlist as opposed to one alloc/free per item
memory for the directory name and the true uri should be allocated at the very top of the function so that it can be unconditionally free()'d at the end. also, no need to check for NULL when calling free().
Oleksiy-Yakovenko
added a commit
that referenced
this pull request
Sep 7, 2024
|
I fixed the issue with tests and merged everything to master. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
related to: #1798
when loading an M3U playlist deadbeef supports interpreting the paths relative to the location of the playlist file. this feature is currently missing from the code loading native (DBPL) playlists, but is implemented in this pull request.
this PR will not pass CI due to a segmentation fault in the Playlist test suite. the segmentation fault occurs only if the Playlist test suite is not run first. that is,
the segfault occurs here, when checking if loading the playlist should be handled by a plugin:
deadbeef/src/playlist.c
Lines 2707 to 2711 in a50e3a5
if the Playlist test suite is run first, the array
plugis empty (plug[0] == NULL), but if not it contains an invalid pointer. I do not understand why this happens and don't know how to trace it further.