Audio HLS with TranscodingContainer=mp4: the playlist is served, the segments throw a 500

[vdatanet 1645]

On Emby 4.9.5.0, requesting an audio HLS stream with fMP4 segments produces a correct playlist whose segments cannot be fetched. Every segment request — and the init segment — returns:

HTTP 500  "Object reference not set to an instance of an object."

The same request with TranscodingContainer=ts works. Same code, same token, same track; the only thing that changes is the container.

GET /Audio/{itemId}/universal
    ?UserId={userId}&DeviceId={deviceId}
    &MaxStreamingBitrate=192000
    &Container=mp3,aac,m4a,flac
    &AudioCodec=aac
    &TranscodingProtocol=hls
    &TranscodingContainer=mp4          <-- ts works, mp4 does not
    &MaxSampleRate=48000
    &PlaySessionId={uuid}
    &api_key={token}

Follow the master playlist to main.m3u8, then request either the #EXT-X-MAP init segment or any hls1/main/N.mp4, carrying the auth query params through as usual. Retried over several seconds in case it was a transcoder warm-up: it is not, the 500 is immediate and consistent.

Worth saying plainly: the playlist itself is authored correctly — version 7, an EXT-X-MAP pointing at init.mp4, segment durations, the lot. Whatever is missing looks like it sits between the playlist writer and the segment handler.

Two small things that might narrow it down, or might be irrelevant — you'll know which:

The ts and mp4 playlists are generated from the same request and differ exactly as you'd expect (version 3 vs 7, EXT-X-MAP present only on the second), so playlist generation looks complete.

The 500 is identical for init.mp4 and for every media segment, which suggests it's one path rather than a per-segment condition.

That's the whole report. I'm not asking for a feature here — just flagging that a route the server advertises can't be followed.