Fix recording genre artwork under public base paths - #134
Draft
hotzenplotz5 wants to merge 5 commits into
Draft
Conversation
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.
Visible failure
Recordings 2 rendered the Genre artwork elements, but the cover areas were black when VDR-Suite was served below the public base path
/vdr-suite. Ordinary folders such asGhiblicontinued to show the normal folder icon.Confirmed root cause
web/frontend/recordings2-folder-artwork.jsassigned root-relative CSS image URLs directly for both the Genre sprite and the individual Genre SVGs. The module therefore depended on global CSS property/prototype adapters to rewritestyle.backgroundImage, which is not a sufficiently reliable module contract.What changed
publicPath()helper that explicitly callsVdrSuitePublicUrl.resolvePath()when the public URL runtime is available;Regression coverage
The new focused Recordings-2 frontend test proves:
/vdr-suiteprefixes both paths exactly once;/vdr-suite/vdr-suite/...is never produced;CSSStyleDeclarationprototype patch;Ghiblistill returns no Genre artwork and therefore keeps the normal folder presentation;The test is registered in the existing
test-recordings2-runtimetarget; no new Make target was invented.Validation
Executed in the agent's isolated validation workspace against the exact changed file contents:
node --check web/frontend/recordings2-folder-artwork.jsnode --check web/frontend/tests/test_recordings2_folder_artwork_public_url.jsnode web/frontend/tests/test_recordings2_folder_artwork_public_url.jsgit diff --check, including a separate whitespace check for the new untracked test fixtureThe complete existing Recordings-2 and frontend contract targets are left to the repository's GitHub Actions checkout, because the canonical yaVDR checkout is not mounted in the agent environment.
Real-system evidence
Before this repository fix, the equivalent bounded change was applied directly to
/usr/share/vdr-suite/web/frontend/recordings2-folder-artwork.json the real system.node --checksucceeded there and the user confirmed:Die Cover sind wieder da.This is positive runtime evidence for the approach, but the direct/usr/shareedit is not treated as repository source of truth or as proof that this branch has already been installed.Scope and safety
This PR changes only the Recordings-2 frontend module, its focused frontend test and the existing Recordings-2 test registration. It changes no daemon code, database, recording cache, artwork cache, series-artwork provider, TVmaze logic, TMDB logic or PR #133 state.