yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

Android: writing tags to files on the device has never been run #87

New Issue
Open
opened 2026-08-18 20:05:18 +00:00 by yonlu · 0 comments
yonlu commented 2026-08-18 20:05:18 +00:00
Owner
Copy Link
Copy Source

Writing tags on Android has never been run. It is the last unfinished item of the Android parity assessment (.planning/plans/pending/016-android-feature-parity.md section B3), whose every other section has shipped; that plan moves to completed/ and this is what it leaves.

Why it is only now possible

The plan recorded B3 as blocked on storage access. It is not any more: the app took the MANAGE_EXTERNAL_STORAGE route (option 1, "the full librarian"), which keeps the path-keyed model intact — audio_files.file_path stays the primary key of ownership and the scanner still walks a real directory. With all-files access, tagwriter can write in place exactly as it does on desktop.

So this is a verification-and-fix task rather than a design task, and it needs a device.

What has to be checked on the phone

  • An atomic write over a real file on shared storage — tagwriter's write-to-temp-then-rename path, on a filesystem the app reaches through an all-files grant rather than its own sandbox. Rename across storage boundaries is the failure to look for.
  • That a rewritten file is still readable by the scanner afterwards, and that the row is re-synced rather than re-imported.
  • That the media scanner / MediaStore does not fight the change. The app does not read through MediaStore, but the rest of the phone does.
  • The autotag apply path end to end, since that is the one flow that rewrites files in bulk and is gated behind a first-apply irreversibility warning.

Related gap, worth doing in the same pass

tagwriter writes track and disc numbers but not totals, which is the field GetAlbumCompleteness rests on — so autotagging a folder currently degrades album completeness from "known" to "unknown". That is a desktop bug too, not an Android one, but it lives in the same file.

Done when

Applying an autotag match on the device rewrites the files, the library reflects it without a re-import, and the completeness badge does not regress.

Writing tags on Android has never been run. It is the last unfinished item of the Android parity assessment (`.planning/plans/pending/016-android-feature-parity.md` section B3), whose every other section has shipped; that plan moves to `completed/` and this is what it leaves. ## Why it is only now possible The plan recorded B3 as blocked on storage access. It is not any more: the app took the `MANAGE_EXTERNAL_STORAGE` route (option 1, "the full librarian"), which keeps the path-keyed model intact — `audio_files.file_path` stays the primary key of ownership and the scanner still walks a real directory. With all-files access, `tagwriter` can write in place exactly as it does on desktop. So this is a verification-and-fix task rather than a design task, and it needs a device. ## What has to be checked on the phone - An atomic write over a real file on shared storage — `tagwriter`'s write-to-temp-then-rename path, on a filesystem the app reaches through an all-files grant rather than its own sandbox. Rename across storage boundaries is the failure to look for. - That a rewritten file is still readable by the scanner afterwards, and that the row is re-synced rather than re-imported. - That the media scanner / MediaStore does not fight the change. The app does not read through MediaStore, but the rest of the phone does. - The autotag apply path end to end, since that is the one flow that rewrites files in bulk and is gated behind a first-apply irreversibility warning. ## Related gap, worth doing in the same pass `tagwriter` writes track and disc **numbers** but not **totals**, which is the field `GetAlbumCompleteness` rests on — so autotagging a folder currently degrades album completeness from "known" to "unknown". That is a desktop bug too, not an Android one, but it lives in the same file. ## Done when Applying an autotag match on the device rewrites the files, the library reflects it without a re-import, and the completeness badge does not regress.
yonlu added the Kind/BugPlatform/Android
Priority
Medium
3
Area/Metadata labels 2026-08-18 20:05:18 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Area/Metadata Kind/Bug Platform/Android
Priority
Medium
3
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#87