Adding FLAC files causes hang #149
Labels
No labels
2230
2243
App version
Apple OS errata
Apple SDK
bug
bugsnag
build
dlt
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: chris/Cog#149
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Describe
Adding FLAC files causes hang.
To Reproduce
Steps to reproduce the behavior:
2021-05-07 12:34:59.921071+0200 Cog[47253:1966326] -[CoreAudioDecoder close] (line 83) Error closing ExtAudioFile
2021-05-07 12:34:59.921124+0200 Cog[47253:1966326] -[CoreAudioDecoder close] (line 88) Error closing AudioFile
Expected behavior
Progress sheet or adding files in the background. Alternatively, very short beach ball.
Version information:
c5ac867
Additional context
I have only tried adding files from my server.
Huh, it shouldn't be logging that when closing on remote files.
Please email me one such FLAC file, and post here what method you are using to access the file. HTTP/S, SMB share, etc.
I brought back background loading for all but the first track of an operation, with queued loading for up to 8 tracks at once.
Thanks @kode54. I will test this soon. Do you still require a sample file? I’m accusing the server (Mac OS X 10.12 Server) via SMB. The data is on a disk attached via USB 2.0, but debugging instrumentation shows that bandwidth at least doesn’t appear to be the issue.
Prior to the latest update, it would sequentially fetch the properties and metadata for all tracks added to the player. Now it will fetch the first one in the foreground so it can start playing immediately, while it fetches the rest in the background, up to 8 at a time. VGMStream still uses a properties and metadata cache, because its file access API is kind of inefficient, and would end up eating a lot of file handles during the process.
Please test again.
Closing until OP responds. @JanX2 Please test again.