Repository navigation
Conversation
libgpod reads its thumbnail write offset with ftell right after fopen("ab").
musl reports 0 there, so artwork saved after the first database save points
at images already in the .ithmb file.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On musl builds, albums end up with another album's artwork once a sync saves the database more than once.
podkit doctorstill says all checks passed, so you only see it on the iPod.src/ithumb-writer.c:1065in libgpod 0.8.3 runswriter->cur_offset = ftell (writer->f)right afterfopen (writer->filename, "ab"). C leaves that position up to the implementation: glibc returns the end of the file, musl returns 0. libgpod then records the new thumbnails' offsets starting from 0, so they point at images already in the file. Saves happen every 10 tracks, so a sync of more than 10 tracks can hit this.The fix adds
fseek (writer->f, 0, SEEK_END)before theftell, in the Linux branch ofbuild-static-deps.sh, with agrepso the build fails if the line ever moves. Changing that file also changes the static-deps cache key. I left the macOS branch alone.To reproduce without an iPod, sync a few albums with different artwork into a directory that has
iPod_Control/Device/SysInfoandSysInfoExtendedfrom a nano 3G, then compare the thumbnails each ArtworkDB entry points at. Same 3 albums and 7 artwork entries on a musl build ofabaf519(Alpine 3.21), for format 1060:doctorpasses in both cases. On a real iPod nano 3G the artwork was wrong without the fix and right with it, including adding and removing albums anddoctor --repair artwork-rebuild -c main. That iPod run used the same substitution applied from a small script, the table above uses this exact diff. I did not run your test suite or a glibc build with this patch, and I did not add a regression test.I don't know if this explains the corruption described in ADR-013. The diff applies cleanly on
build-static-deps.shfrom #77 and #83.Claude (Claude Code) found the cause and wrote this patch. I checked the artwork on the iPod myself.