Stop dropping Jellyfin playlists without a media type

[lostf1sh]

Fixes #89.

Problem

getPlaylists() asked the server for IncludeItemTypes=Playlist&MediaTypes=Audio. Since Jellyfin 10.10 playlists can hold mixed content, so audio playlists are frequently reported with an empty or Unknown MediaType — the server-side filter drops them and the response comes back with zero items.

That matches the report exactly: the account is connected, Jellyfin tracks play fine, the server shows a playlist, but the app reports 0 synced playlists and the Playlists tab is empty.

Change

• Drop MediaTypes=Audio from the request and reject only playlists that explicitly declare another media type (Video, Photo, Book), via JellyfinResponseParser.isAudioPlaylist. Non-audio content in a kept playlist is already ignored, since syncPlaylistSongs() parses items as audio.
• syncPlaylists() now logs when the server reports no audio playlists, so a genuinely empty result is distinguishable from a filtered-away one in a bug report.
• Unit tests for the new predicate.

Testing

./gradlew testDebugUnitTest --tests '*JellyfinResponseParserTest*' — 3 passing.

Not verified against a live Jellyfin 10.10+ server; the reporter offered to test.

[greptile-apps]

Greptile Summary

The PR restores Jellyfin playlists whose media type is absent or unknown while filtering non-audio children before song parsing and persistence.

• Removes the server-side audio media-type restriction from playlist discovery.
• Adds client-side predicates for playlist and child-item classification.
• Adds focused parser tests and diagnostics for empty playlist results.
• Adds a pull-request APK build workflow and updates the changelog.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
app/src/main/java/com/lostf1sh/pixelplayeross/data/network/jellyfin/JellyfinApiService.kt	Removes the server-side media-type filter and applies client-side playlist and child filtering; the previous mixed-child persistence issue is addressed.
app/src/main/java/com/lostf1sh/pixelplayeross/data/network/jellyfin/JellyfinResponseParser.kt	Adds case-insensitive predicates that retain ambiguous playlists while requiring playlist children to identify as audio.
app/src/test/java/com/lostf1sh/pixelplayeross/data/network/jellyfin/JellyfinResponseParserTest.kt	Covers audio, ambiguous playlist, explicit non-audio playlist, and mixed-child classification cases.
app/src/main/java/com/lostf1sh/pixelplayeross/data/jellyfin/JellyfinRepository.kt	Adds a diagnostic warning when no audio playlists are returned without altering synchronization behavior.
.github/workflows/pr-build.yml	Adds a minimally permissioned pull-request workflow that builds, verifies, and uploads signed split APKs.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    A[Jellyfin playlists API] --> B[Keep Audio, Unknown, or missing MediaType]
    B --> C[Fetch playlist children]
    C --> D{MediaType or Type is Audio?}
    D -- Yes --> E[Parse and persist as songs]
    D -- No --> F[Skip child]

Loading

_{Reviews (3): Last reviewed commit: "Skip non-audio children of mixed Jellyfi..." | Re-trigger Greptile}

[lostf1sh]

Good catch — fixed in 4572856. getPlaylistItems now keeps only children that declare themselves audio (JellyfinResponseParser.isAudioItem), so a retained mixed-content playlist can no longer push video entries into the playlist or the unified library. Real media items always carry a concrete media type, so unlike the playlist containers they can be filtered on it. Covered by two more parser tests.