README.md

@@ -403,6 +403,10 @@ Then put it behind your existing reverse proxy like everything else
       falling back to its album's artwork — see docs/architecture.md
       (probably not the whole "images are hard to find" story — flagged
       there)
+- [x] Fixed the music bar's mobile now-playing screen not fitting a
+      phone rotated to landscape — the art now sits beside the title
+      instead of above it, sized off the viewport height instead of a
+      fixed width-based cap — see docs/architecture.md
 - [ ] Try a full party end-to-end with two real accounts (still the main gap)
 - [ ] Try casting to a real Chromecast (only the SDK's own bootstrap is
       confirmed here — no real device/session)

client/src/musicBar/MusicBar.css

@@ -388,6 +388,41 @@
   }
 }
 
+/* Rotated: the block above stacks the art on top of everything else and
+   sizes it off the viewport's WIDTH (60vw) - reported directly as
+   overflowing/needing to scroll once width and height swap roles in
+   landscape, where width is the one dimension this screen never lacks.
+   Same fixed-overlay itself, just laid out differently - the art moves
+   beside the title/artist instead of above them (freeing most of the
+   vertical stack this screen otherwise spends on it), and every size
+   below is capped by `vh`, the scarce dimension here, not `vw`. Button
+   sizes are deliberately left alone (56px .musicBarPlayBig, the same
+   above) - a touch target sizes to a finger, not the screen, in any
+   orientation. */
+@media (max-width: 720px) and (orientation: landscape) {
+  .musicBarPanel {
+    padding-top: 10px;
+    padding-bottom: calc(10px + env(safe-area-inset-bottom, 0px));
+  }
+
+  .panelCloseBtn { margin-bottom: 6px; }
+
+  .musicBarPanelTrack {
+    flex-direction: row;
+    text-align: left;
+    margin-bottom: 8px;
+  }
+
+  .musicBarPanelTrack .musicBarImage {
+    width: min(120px, 20vh);
+    height: min(120px, 20vh);
+  }
+
+  .musicBarInfo { align-items: flex-start; }
+
+  .musicBarPanelTransport { margin-bottom: 8px; }
+}
+
 /* One queue entry - a plain flex row (image, then a shrinking/truncating
    info column, then the duration), NOT views/album's shared .trackRow
    grid (styles/trackList.css) - that one's 4 fixed columns assume

docs/architecture.md

@@ -4517,6 +4517,51 @@ request includes `Fields=AlbumId` (a mocked `EmbyClient.fetch` capturing
 the real path/query it was called with, not just asserting on the
 already-separately-tested `imageUrlFor` logic downstream of it).
 
+## The music bar's mobile now-playing screen didn't fit landscape
+
+Reported directly, along with a fair general complaint: the mobile
+now-playing overlay used mostly fixed sizes, and the one that mattered
+most - the album art - was sized off `vw` (`min(220px, 60vw)`), the
+viewport dimension a phone in landscape has *plenty* of. Stacked
+vertically (art, then text, then the transport row, then the side row)
+with that same art staying pinned near its 220px cap regardless of how
+little vertical room was actually left, the screen ran well past a
+typical landscape phone's height and needed to scroll to reach the
+transport controls - not adapted to the rotation at all.
+
+Fixed with a dedicated `@media (max-width: 720px) and
+(orientation: landscape)` block, not by chasing every fixed value in
+the portrait rules: the art moves beside the title/artist instead of
+above them (`.musicBarPanelTrack` becomes `flex-direction: row`),
+freeing most of the vertical space the portrait layout spends stacking
+them - and every size that actually needs to respond to the rotation is
+now capped by `vh` (`min(120px, 20vh)`), the dimension landscape
+actually constrains, instead of `vw`. A few fixed margins shrink
+alongside it in this same block, same reasoning: adapting to less
+vertical room, not arbitrary tightening.
+
+Deliberately NOT changed: `.musicBarPlayBig`'s 56px transport button
+and the other icon buttons. A touch target's size answers to a
+finger, not the screen - shrinking it in landscape to "adapt" would
+trade a real usability problem (nothing to tap accurately) for a
+cosmetic one, the opposite of the actual ask.
+
+Verified: full `typecheck`/`build` (client only). Checked directly, not
+just reasoned about - real compiled CSS with the real markup loaded
+into `<iframe>`s sized to a wide (700x320) and a deliberately extreme,
+narrow (650x280) landscape shape (this sandbox's own `resize_window`
+viewport emulation doesn't reflect orientation reliably - iframes do,
+same workaround as every other viewport-shaped check this session).
+Both matched `(orientation: landscape)`, both switched
+`.musicBarPanelTrack` to a real `row` layout with the art measurably to
+the image's left, both image sizes tracked the shrinking `vh` cap
+correctly (64px/56px respectively, not the old fixed 220px), and both
+fit their entire content within the viewport's own height with zero
+overflow - even the extreme 280px-tall case, which the pre-fix numbers
+would have overflowed by well over 200px. A separate portrait check
+(375x700) confirmed this landscape block changes nothing there: still
+`column`, still the original 220px `vw`-capped art, unaffected.
+
 ## Known limitations
 
 - Playback always goes through `hls.js` against whatever Emby's