Skip to content

Fix recording genre artwork under public base paths - #134

Draft
hotzenplotz5 wants to merge 5 commits into
mainfrom
agent/recordings2-genre-cover-public-url
Draft

Fix recording genre artwork under public base paths#134
hotzenplotz5 wants to merge 5 commits into
mainfrom
agent/recordings2-genre-cover-public-url

Conversation

@hotzenplotz5

Copy link
Copy Markdown
Owner

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 as Ghibli continued to show the normal folder icon.

Confirmed root cause

web/frontend/recordings2-folder-artwork.js assigned 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 rewrite style.backgroundImage, which is not a sufficiently reliable module contract.

What changed

  • add a small publicPath() helper that explicitly calls VdrSuitePublicUrl.resolvePath() when the public URL runtime is available;
  • resolve the shared Genre sprite through that helper;
  • resolve every individual Genre SVG through that helper;
  • retain the direct-daemon root-relative path as the tested fallback when the resolver is unavailable;
  • leave Genre mapping, sprite positions, single-recording leaf handling and ordinary-folder behavior unchanged.

Regression coverage

The new focused Recordings-2 frontend test proves:

  • empty public base path keeps the Sprite and individual SVG paths root-relative;
  • /vdr-suite prefixes both paths exactly once;
  • /vdr-suite/vdr-suite/... is never produced;
  • the module works without any available CSSStyleDeclaration prototype patch;
  • the established Genre slugs and Sprite positions remain unchanged;
  • an unmapped folder such as Ghibli still returns no Genre artwork and therefore keeps the normal folder presentation;
  • the existing exported Recordings-2 folder-artwork runtime API remains intact;
  • the resolver-unavailable direct-daemon fallback remains covered.

The test is registered in the existing test-recordings2-runtime target; 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.js
  • node --check web/frontend/tests/test_recordings2_folder_artwork_public_url.js
  • node web/frontend/tests/test_recordings2_folder_artwork_public_url.js
  • git diff --check, including a separate whitespace check for the new untracked test fixture

The 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.js on the real system. node --check succeeded there and the user confirmed: Die Cover sind wieder da. This is positive runtime evidence for the approach, but the direct /usr/share edit 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant