Repository navigation
Build library rows from the track, and remove the Recent section - #683
Merged
Merged
Conversation
added 2 commits
September 23, 2026 17:06
It listed the three newest tracks above the folders, and every one of them is also in its folder, where a new import already lands at the top. So each new track appeared twice in one panel, and two imports of the same song four times, which is what the #656 reporter's screenshot shows: Hallelujah four times, and a library that has to scroll to get past it. Nothing it offered is lost. Recent imports are at the top of the first folder, and a track still being processed says so in its own row, which is the inline, Moises-style handling the reporter asked for. The one thing it did that a folder does not is reach across folders, which is a sort order rather than a section if it turns out to matter. The no-match message for a library search was hard-coded English and keyed on the Recent list being empty. It is translated now, beside the Favorites and Trash messages it mirrors, and library.recent has nothing left to label.
Two copies of the same song sat in the library reading "Extracted · 6 stems" and " · 6 stems" (#656). The line under a title was `channel · N stems`, and channel was never a channel. Six code paths stored a status label in it, and they disagreed: foreground and background completion "Extracted", translated queued imports "Processing", hard-coded English playlist imports "Processing", translated startup sync of a server job nothing The last is the empty one, and it is what the reporter saw: a job the local library did not know about is adopted on startup with no label, so the line began with a bare dot. Reproduced by starting with an empty library. Its count was wrong too, taken from the stems the job had asked for, which an adopted job may not have recorded, so it read "0 stems". The label also froze in whatever language was active when it was written, so switching language left old rows behind, and the key it borrowed is the "Extracted" that precedes a date in the track panel: 抽出日時, "extraction date", in Japanese. Nothing is stored now. The line is built when the row is drawn: length and stem count for a finished track, Processing or Import failed while it is not, the re-import warning when its files are gone, Removed in the Trash. The count is of the stem files that exist, the same rule the track panel already used, now in one helper both share. Every writer of the label is gone, and search no longer matches it, since tracks saved before this still carry it. Seven tests, all failing against main: a track adopted from the server reads like any other, an old stored label is neither shown nor searched, processing and failed tracks say so, the line follows the language, each track is listed once, and the empty search message is translated.
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
1 participant
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.
Closes #656
Every row reads the same way
The line under a library title was
channel · N stems, andchannelwas never a channel. Six code paths stored a status label in it, and they disagreed:That last path produced the " · 6 stems" row in #656, next to "Extracted · 6 stems" on the other copy. I reproduced it by starting with an empty library. The adopted row's count was also wrong: it came from the stems the job had asked for, not the ones it has, and read "0 stems".
The line is now built when the row is drawn:
The count uses the stem files that exist, the same rule the track panel already used, now shared through one helper. Every writer of the label is gone, and search no longer matches it. It also follows the language now, where a stored label kept whatever language it was written in.
The Recent section is gone
It listed the three newest tracks, each of which is also in its folder, so the reporter's screenshot shows one song four times. New imports already land at the top of the first folder, and a processing track says so in its own row. The library's no-match search message was hard-coded English and is translated now.
Verification
library-rows.spec.mjs: 7 new tests, all failing against main.