Proposal: Fetch Lower Qualities when Desired Quality for Track not Found

[omnunum]

Add fallback quality support for Deezer downloads

Problem

When requesting a specific audio quality (e.g., FLAC) from Deezer, the download fails if that quality isn't available, even if lower qualities are accessible.

Solution

Add a lower_quality_if_not_available configuration option to DeezerConfig that automatically falls back to an alternative quality when the requested quality is unavailable.

Changes

• Add lower_quality_if_not_available field to DeezerConfig dataclass
• Implement fallback logic in DeezerClient.get_downloadable() method
• Update test configuration files to include the new field
• Add comprehensive tests for fallback behavior

Implementation Details

The fallback logic checks if the requested quality has a file size of 0 (unavailable) and if lesser qualities are available. If so, it automatically switches to the next best quality and logs a warning.

Configuration

[deezer]
quality = 2  # Requested quality (FLAC)
lower_quality_if_not_available = true  # Fallback to MP3 if FLAC unavailable

Testing

• Unit tests verify fallback logic with mocked data
• Integration test confirms fallback works with actual track 77874822
• All existing tests pass

Notes

This is a proposal for handling unavailable track qualities. The author may prefer a different approach or implementation strategy. At the very least this should get the ball rolling on a problem that was driving me nuts.

[omnunum]

Example taken from the ☝️ linked issue.

Deezer info for downloadable:    downloadable.py:123
{'quality': 2, 'id': '82318690',
'quality_to_size': [4062980,
10157452, 0], 'url':
'https://e-cdns-proxy-f.dzcdn.ne
t/mobile/1/645058c13629e3477faf4
27b01f9fdbf3ba8433394624e66787f3
a9d3de406ee067019209a1c04de944ae
a74171a70d4d954cf5be5c8f7cd48191
ebc05d32619a1879c599a2e858532e1b
eda02a9ea52'}

Quality is 2 (FLAC) but the track does not seem to be available in FLAC (see [4062980, 10157452, 0] having a 0 size. Because the call to the deezer api get_url endpoint does not return a stream url, streamrip attempts to create a cdn proxy link at the assumed shard for the track based on hash. This file does not seem to exist here.

Maybe there is some aspect of the deezer API, cdn strategy, or some other context I am unaware of that would be able to access the FLAC correctly. Because I don't really know anything about Deezer, this was the first solution that came to mind.

Either way, while I would prefer to have FLAC files for everything I would rather mix in some 320 MP3s than be high and dry entirely.

[omnunum]

If anyone wants to run this fix in unraid, you can use the following config

Add the path maps

• unraid: /mnt/user/{downloads_or_music_share} -> container: /downloads
• unraid: /mnt/user/appdata/streamrip -> container: /config/.config/streamrip
  And set env vars
• PUID=99
• PGID=100

if you want to host it on your account, this is the dockerfile i used

FROM lscr.io/linuxserver/baseimage-alpine:3.19

ENV PUID=99 \
    PGID=100 \
    UMASK=002

RUN apk add --no-cache python3 py3-pip ffmpeg gcc python3-dev musl-dev

COPY . /app/

RUN cd /app && \
    pip3 install --no-cache-dir --break-system-packages . && \
    apk del gcc python3-dev musl-dev && \
    rm -rf /tmp/* /root/.cache

# Wrapper that runs the app as abc
RUN <<'EOF'
cat > /usr/local/bin/rip <<'SCRIPT'
#!/bin/sh
export HOME=/config
cd /downloads
exec s6-setuidgid abc /usr/bin/rip "$@"
SCRIPT
chmod +x /usr/local/bin/rip
EOF

VOLUME /config /downloads
WORKDIR /downloads

# Keep container alive for Unraid console
CMD ["sleep", "infinity"]

Then you can just open a new console and run rip url https://www.deezer.com/us/album/7740248 and you'll see that its a mix of mp3 and flac instead of only the one flac and a bunch of errors.

[omnunum]

@nathom take a look when you get a chance.

[omnunum]

After using this for a few days, a more useful setting for me would be closer to fetch_highest_quality_available or something. Some tracks (from phonk artists) aren't even available in 320 but I want them anyway.

[omnunum]

I have updated the branch with the new approach that just gets the next best quality. I was still finding some tracks that were only in low res mp3.

[nathom]

How thoroughly have you tested this?

[omnunum]

I have been using a different version of this on my forked repo to great success. I can re-test this exact code and make sure to fix the failing tests (sorry about that).

[omnunum]

Fixed the tests btw so should be good to merge.