Fixes - #103
Conversation
… & auto-queue with fuzzy search
…ep timer fade-out & double-tap to seek
…nt upcoming queue
…YouTube Music and bulk playlist downloads
…ibility for local and cloud playlists
… and I/O buffer throughput
… case cleaner and YouTube transcript fallback
…to LRCLIB, and require synchronized lyrics only
…e playback control
…& 5 rich Home sections
… fix multi-category search classification
…s all filters, fix online artist/album navigation & song count badges
…e thumbnails to 1024px HD, and implement song liking for all song types
…position across screen transitions
…inz scrobbling, unified search, and modern architecture
…rs, Quick Picks, and New Releases carousels
…ne download bundling, and CI workflow runner
|
| Filename | Overview |
|---|---|
| app/src/main/java/com/lostf1sh/pixelplayeross/data/worker/CloudTrackDownloadWorker.kt | Implements resumable cloud downloads and metadata post-processing, but exposes files as complete before mutation finishes. |
| app/src/main/java/com/lostf1sh/pixelplayeross/data/offline/CloudOfflineRepository.kt | Coordinates offline records and WorkManager jobs, but bulk cleanup races with active workers. |
| app/src/main/java/com/lostf1sh/pixelplayeross/data/database/YouTubeSongEntity.kt | Adds cached YouTube tracks, but its primary key prevents one video from retaining multiple collection memberships. |
| app/src/main/java/com/lostf1sh/pixelplayeross/data/database/MusicDao.kt | Extends most source filters for YouTube, while several library queries omit the new mode. |
| app/src/main/java/com/lostf1sh/pixelplayeross/data/stream/CloudStreamProxy.kt | Adds disk caching, request validation, URL deduplication, and stale-upstream retry handling; no publishable defect was established. |
| app/src/main/java/com/lostf1sh/pixelplayeross/data/youtube/YouTubeRepository.kt | Adds YouTube browsing, radio, library persistence, and model mapping, including the collection replacement path. |
| app/src/main/java/com/lostf1sh/pixelplayeross/data/database/Migrations.kt | Adds the v5-to-v6 YouTube table migration consistent with the exported Room entities. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart LR
YT[YouTube Music API] --> Repo[YouTube Repository]
Repo --> DB[(Room YouTube tables)]
Repo --> Proxy[YouTube Stream Proxy]
Proxy --> Cache[Stream Disk Cache]
Proxy --> Player[Media3 Player]
Proxy --> Worker[Cloud Download Worker]
Worker --> Offline[(Offline track files and DB)]
Offline --> Player
DB --> UI[Library, Search, Dashboard]
Comments Outside Diff (2)
-
app/src/main/java/com/lostf1sh/pixelplayeross/data/worker/CloudTrackDownloadWorker.kt, line 156-165 (link)Completion precedes file finalization
When playback starts immediately after this update, the repository exposes the file as complete while
postProcessDownloadedTrackis still rewriting it, causing truncated playback, failed seeks, or a source error.Prompt To Fix With AI
This is a comment left during a code review. Path: app/src/main/java/com/lostf1sh/pixelplayeross/data/worker/CloudTrackDownloadWorker.kt Line: 156-165 Comment: **Completion precedes file finalization** When playback starts immediately after this update, the repository exposes the file as complete while `postProcessDownloadedTrack` is still rewriting it, causing truncated playback, failed seeks, or a source error. --- For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
-
app/src/main/java/com/lostf1sh/pixelplayeross/data/database/MusicDao.kt, line 920-930 (link)When
StorageFilter.YOUTUBE_MUSICsupplies mode 4, this predicate handles only modes 0, 1, and 2, causing the favorite count to return zero despite matching source-type 7 songs. The album and artist queries contain the same omission and therefore render those YouTube views empty as well.Prompt To Fix With AI
This is a comment left during a code review. Path: app/src/main/java/com/lostf1sh/pixelplayeross/data/database/MusicDao.kt Line: 920-930 Comment: **YouTube filter matches no favorites** When `StorageFilter.YOUTUBE_MUSIC` supplies mode 4, this predicate handles only modes 0, 1, and 2, causing the favorite count to return zero despite matching source-type 7 songs. The album and artist queries contain the same omission and therefore render those YouTube views empty as well. --- For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
Prompt To Fix All With AI
### Issue 1
app/src/main/java/com/lostf1sh/pixelplayeross/data/worker/CloudTrackDownloadWorker.kt:156-165
**Completion precedes file finalization**
When playback starts immediately after this update, the repository exposes the file as complete while `postProcessDownloadedTrack` is still rewriting it, causing truncated playback, failed seeks, or a source error.
### Issue 2
app/src/main/java/com/lostf1sh/pixelplayeross/data/offline/CloudOfflineRepository.kt:194-200
**Bulk cleanup deletes active downloads**
When delete-all runs during an active download or post-processing operation, this unconditionally removes every file in the shared directory without cancelling the worker, causing the download to fail or the worker to recreate orphaned files after its database row is gone.
### Issue 3
app/src/main/java/com/lostf1sh/pixelplayeross/data/database/YouTubeSongEntity.kt:21-23
**Primary key destroys collection membership**
When the same video is saved to another collection, `REPLACE` reuses this video-derived primary key and overwrites its single `playlistId`, causing the track to disappear from whichever library or favorites collection previously contained it.
### Issue 4
app/src/main/java/com/lostf1sh/pixelplayeross/data/database/MusicDao.kt:920-930
**YouTube filter matches no favorites**
When `StorageFilter.YOUTUBE_MUSIC` supplies mode 4, this predicate handles only modes 0, 1, and 2, causing the favorite count to return zero despite matching source-type 7 songs. The album and artist queries contain the same omission and therefore render those YouTube views empty as well.
### Issue 5
app/src/main/java/com/lostf1sh/pixelplayeross/data/network/youtube/InnertubeApiService.kt:63
**Direct logging bypasses release policy**
The new YouTube networking code uses `android.util.Log` throughout its request and failure paths, bypassing the repository's `ReleaseTree` filtering. Use Timber consistently here and in `YouTubeExtractorManager` so these diagnostics follow the configured release logging policy.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "fix(playback): Stream resolution resilie..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| suspend fun deleteAllDownloaded() = withContext(Dispatchers.IO) { | ||
| val completed = dao.getCompleted() | ||
| completed.forEach { entity -> | ||
| entity.localPath?.let(::File)?.delete() | ||
| dao.deleteBySourceUri(entity.sourceUri) | ||
| } | ||
| downloadDirectory(context).listFiles()?.forEach(File::delete) |
There was a problem hiding this comment.
When delete-all runs during an active download or post-processing operation, this unconditionally removes every file in the shared directory without cancelling the worker, causing the download to fail or the worker to recreate orphaned files after its database row is gone.
Prompt To Fix With AI
This is a comment left during a code review.
Path: app/src/main/java/com/lostf1sh/pixelplayeross/data/offline/CloudOfflineRepository.kt
Line: 194-200
Comment:
**Bulk cleanup deletes active downloads**
When delete-all runs during an active download or post-processing operation, this unconditionally removes every file in the shared directory without cancelling the worker, causing the download to fail or the worker to recreate orphaned files after its database row is gone.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.| @PrimaryKey val id: String, | ||
| @ColumnInfo(name = "video_id") val videoId: String, | ||
| @ColumnInfo(name = "playlist_id") val playlistId: String = "__library__", |
There was a problem hiding this comment.
When the same video is saved to another collection, REPLACE reuses this video-derived primary key and overwrites its single playlistId, causing the track to disappear from whichever library or favorites collection previously contained it.
Prompt To Fix With AI
This is a comment left during a code review.
Path: app/src/main/java/com/lostf1sh/pixelplayeross/data/database/YouTubeSongEntity.kt
Line: 21-23
Comment:
**Primary key destroys collection membership**
When the same video is saved to another collection, `REPLACE` reuses this video-derived primary key and overwrites its single `playlistId`, causing the track to disappear from whichever library or favorites collection previously contained it.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.| userPreferencesRepository.youTubeAuthCookiesFlow.collect { cookies -> | ||
| authCookies = cookies | ||
| val sapisid = cookies?.let { extractCookieValue(it, "SAPISID") ?: extractCookieValue(it, "__Secure-3PAPISID") } | ||
| android.util.Log.d("YouTubeMusic", "InnertubeApiService updated authCookies (length=${cookies?.length ?: 0}, hasSapisid=${!sapisid.isNullOrBlank()})") |
There was a problem hiding this comment.
The new YouTube networking code uses android.util.Log throughout its request and failure paths, bypassing the repository's ReleaseTree filtering. Use Timber consistently here and in YouTubeExtractorManager so these diagnostics follow the configured release logging policy.
Context Used: CONTRIBUTING.md (source)
Prompt To Fix With AI
This is a comment left during a code review.
Path: app/src/main/java/com/lostf1sh/pixelplayeross/data/network/youtube/InnertubeApiService.kt
Line: 63
Comment:
**Direct logging bypasses release policy**
The new YouTube networking code uses `android.util.Log` throughout its request and failure paths, bypassing the repository's `ReleaseTree` filtering. Use Timber consistently here and in `YouTubeExtractorManager` so these diagnostics follow the configured release logging policy.
**Context Used:** CONTRIBUTING.md ([source](https://github.com/pixelplayerhq/pixelplayeross/blob/main/CONTRIBUTING.md))
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
2 participants
No description provided.