README.md

@@ -403,10 +403,6 @@ 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,41 +388,6 @@
   }
 }
 
-/* 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,51 +4517,6 @@ 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