Process frozen, server resources exhausted when trying to view recently added

[gryphonmyers]

I don't know if this was a specific consequence of viewing recently added, but I installed beetstream to try it out, ran the process, pointed DSub at it. At first it seemed like it was working alright - Recently Added view rendered normally. I then installed DSub on my wife's phone and tried to repeat the same process. Responses errored, the process locked up and actually my entire server became unresponsive.

I'm guessing I triggered some kind of infinite loop. I will investigate further to see if I can get more reliable repro.

[BinaryBrain]

Hi, I don't really know what could cause this and I cannot reproduce it on my side. Do you have the logs from the Beetstream server? Also the request to query the newest albums is very similar to others. Maybe it could be a performance issue? How many albums to you have on beets?

[gryphonmyers]

Hi, I don't really know what could cause this and I cannot reproduce it on my side. Do you have the logs from the Beetstream server? Also the request to query the newest albums is very similar to others. Maybe it could be a performance issue? How many albums to you have on beets?

My library is huge, definitely could be a factor. I'll dig for clues today

[gryphonmyers]

I'm not sure this is the same issue, because I don't recall seeing these errors before, but while messing around with the search endpoint to try and figure out repro, I got it to do this:

File "REDACTED/lib/python3.10/site-packages/beetsplug/beetstream/utils.py", line 244, in path_to_content_type
    raise RuntimeError(f"Unable to determine content type for {path}")
RuntimeError: Unable to determine content type for REDACTED/07 Good & Bad.m4a
192.168.50.213 - - [10/Jun/2023 10:45:05] "GET /rest/search3.view?u=&s=cisd4mvgt4m06b0r6nl28orcd4&t=61c0ab3c278eb514a6c854a5a3b4dc0c&v=1.2.0&c=DSub&query=bad&artistCount=20&albumCount=20&songCount=50 HTTP/1.1" 500

[mgoltzsche]

Unable to determine content type

I ran into the same problem with .m4a and .opus files. I fixed that part of the issue within #14 by explicitly mapping mime types for these file extensions and not making the endpoint fail when it sees an unknown extension but let it fallback to using mime type application/octet-stream in that case.