Error in streamed MPEG4 handling - Movie.pm or Audio::Scan error ?

[bpa]

I've pushed that PR https://github.com/Logitech/slimserver/pull/749, let me know if this works for you

The update works and it is done in a way I prefer (i.e. looking for STCO 1st chunk) rather than hidden in Audio::Scan.
In your comments you say "find optional stco" - according to spec "stco" is "mandatory".

> I've pushed that PR https://github.com/Logitech/slimserver/pull/749

Thanks a lot philippe_44! I'll wait for bpa's thumbs up before merging. Ok?

A quick test with both Accuradio and Tidal MPEG-4 streams and they play OK.
I'll do a bit more testing later today with MPEG-4 audio podcasts which are harder to find but have greatest variations.

[bpa]

Summary: I think the PR can be merged.

I did some more testing with a variety of m4a audio podcasts as well as some more Tidal (m4a) and Accuradio tracks. I'm summarising the results to record them somewhere, not to get more changes.

All podcast I tested had an "stco" atom.

A couple of podcasts didn't play on LMS but I think not related to the proposed fix (e.g. incorrect MIME type)
http://images.anandtech.com/reviews/...odcast_048.m4a
https://mbse-podcast.rocks/wp-conten...MPCT_19-24.m4a

One podcast which played OK on LMS, had an "stco" atom but its offset was not used. This podcast had "moov" after "mdat" and so technically is not a streaming MPEG-4 file. Great that LMS managed to play it.
https://www.smarterartschool.com/upl...0_12.04_pm.m4a

I haven't seen any recent comments about non-playing m4a podcasts, so I think not necessary to make more changes.

With regard to why there are extra 8 zeros in Accuradio mdat field - my current theory is related to the encoder implementation. Without knowing the total size of audio data when creating the header, the encoder is allowing for a very large mdat atom (i.e. audio data) which would require the 64 bit largesize field.