MediaMonkey forum

Hi,
What about MM5? As MM5 have updated libraries that can't be used in MM4, so issues is maybe already fixed?

I will test later today when I get home and upload log files via the same ticket - did my previous log files confirm that there is a problem with MM4?

I tested with MM5 and uploaded log files - same behavior as MM4. I tried Universal Media Server and it was able to stream native ALAC, AAC-LC and MP3 files error free - no transcoding needed, but UMS has other issues that would prevent me from wanting to use it - so for now it's MM4 with transcoding ALAC+AAC to MP3.

Hi,
can you post URL to UMC? So that I can try to setup test enviroment?

You can find it here:

https://www.universalmediaserver.com/

I've been working with MM5 DLNA playback recently and it doesn't work very well with M4A-ALAC and M4A-AAC encoded files and Denon equipment - This issue also exists with MM4 as I first reported here:

https://www.mediamonkey.com/forum/viewtopic.php?t=98289

The problem involves playback of M4A (ALAC and AAC) files - the only way they seem to work at all with Denon Home speakers is to transcode the content to mp3, but even then, there is a long delay (of varying lengths) in between tracks that occurs frequently. Only native mp3 content seems to play without a long delay. If this were fixed and if the monkeymote would allow selection of speakers, then I could drop using iTunes + Apple remote. Does anyone else see this problem? If so, is there a work-around?

Do you know if the Denon supports these formats over DLNA?

Yes, Denon supports those formats - when I previously looked at this issue with MM4 (see thread), I was able to use Universal Media Server (another DLNA program) to stream native ALAC and AAC to the Denon equipment.

I used the latest test build (2682) to capture the playback to Denon Heos problem - file is here:

https://1drv.ms/u/s!Ao022bFhgFV4hGyjxMG ... P?e=bUZdtK

For the test, I created a playlist with 9 very short tracks. I play these from MM5 to a Denon Home 150 speaker. The first 6 tracks play back with no delays between tracks. After track #6, there is a significant delay between each tracks.
Search for text "BEGIN - HERE", Track 6 is 27 seconds long and starts playing around time = 199 - the next track should play around 226 but doesn't start until about 320. Look for text "NEXT TRACK" where track #7 starts. I am transcoding all ALAC/M4A files to FLAC 0, but it doesn't seem to matter what I transcode to, the delay happens. The same delay also happens if I use the Denon HEOS software to play tracks from the MM5 DLNA server. This problem actually may be worse than I previously found last year with MM4 because even .mp3 files can have this delay. The problem repeats between tracks 6,7,8,9. Tracks 1-7 are ALAC/M4A but tracks 8 and 9 are mp3 files. I hope that this may help to shed some light on this problem.

Hi, in the log I see that MM casted song
N:\Tunes\cd-m4a\Soundtracks\The Best Of Schoolhouse Rock\01 Schoolhouse Rock.m4a
as
http://192.168.2.198:54407/ItemID=32105.flac
being transcoded to
N:\Temp\Transcode\32105.FLAC
where the client 'Study' read 25% of the file and played 13 seconds then it transited to STOPPED state.

In the log I see that length of the file is 13 seconds, so it sounds that either the length detection is incorrect or the file is really only 13 seconds short?
Can you right click N:\Tunes\cd-m4a\Soundtracks\The Best Of Schoolhouse Rock\01 Schoolhouse Rock.m4a and go to Properties to see the length?
And if the length is not 0:13 then please try to disable transcoding if it has any effect, trascoding can be disabled by clicking the cast icon on the player and click the 'gear' button next to the 'Study' player.
I mean this button: https://www.dropbox.com/s/7kqjl9jvgrq3x ... 1.png?dl=0

EDIT: Another possibility might be that the files were transcoded in the past, but for some reason incomplete. In that case you might try to delete all files in N:\Temp\Transcode\ to force re-encoding of the cached files to see whether this might be the case?

The length of that track is 14 seconds -

I cleared the folder N:\Temp\Transcode and turned off transcoding and played the playlist 2X - each time an error message "Playback Failed: ... cannot decode <filename>" randomly appeared - the 1st time I got the error on the first track, on the second playback attempt, the first track played fine, but the second one had the error

telecore wrote: ↑Mon Nov 07, 2022 9:18 am The length of that track is 14 seconds -

And is this expected length for the track? Also for the others tracks in the log I see very short lengths like 9 seconds, 21 seconds etc.

I cleared the folder N:\Temp\Transcode and turned off transcoding and played the playlist 2X - each time an error message "Playback Failed: ... cannot decode <filename>" randomly appeared - the 1st time I got the error on the first track, on the second playback attempt, the first track played fine, but the second one had the error

OK, and if you re-enable the transcoding again after clearing the N:\Temp\Transcode\ does it resolve the issue?

Ludek wrote: ↑Mon Nov 07, 2022 4:07 pm And is this expected length for the track? Also for the others tracks in the log I see very short lengths like 9 seconds, 21 seconds etc.

This is a test playlist of very short tracks, all less than 30 seconds long, to test the problem

OK, and if you re-enable the transcoding again after clearing the N:\Temp\Transcode\ does it resolve the issue?

No - but there seems to be some new information - if I turn off transcoding and un-check "Level Volume..." - the test playlist can play back with no errors and no pausing, however, when I try a playlist with normal length songs of 3-5 minutes, the problem re-occurs where tracks get a "Playback Failed.. cannot decode <filename.m4a>" error message - Is this a clue? That shorter files can play back? (Most of my library is M4A ALAC encoded by iTunes)

AFAIR ALAC isn't supported by Chromecast
(details in https://www.ventismedia.com/mantis/view ... 277#c49678) where we added the auto-convert rule M4A above 528 kbps -> MP3 VBR 192 to workaround this.

So I guess enabling this rule should solve it for you? If not then feel free to open eSupport ticket with DbgView log attached (or sameple ALAC file).

Ludek wrote: ↑Tue Nov 08, 2022 11:21 am AFAIR ALAC isn't supported by Chromecast
(details in https://www.ventismedia.com/mantis/view ... 277#c49678) where we added the auto-convert rule M4A above 528 kbps -> MP3 VBR 192 to workaround this.

So I guess enabling this rule should solve it for you? If not then feel free to open eSupport ticket with DbgView log attached (or sameple ALAC file).

This doesn't work - I tried exactly what you suggested, but I had already tried a very similar approach before (I converted ALAC to MP3 when > 299 kbps and used 320 kbps MP3) - there is just something that doesn't work with Denon / Denon Heos equipment and MM4 or MM5, which is why I have to export to iTunes.xml and use iTunes for home playback but MM5 for everything else - but in my testing over 1 year ago, Universal Media Server (an open source DLNA server) worked fine with Denon equipment

To be clear, converting high bitrate ALAC to mp3 does play the file, however, after the end of the track, there is a very long delay before the next track starts and the Denon HEOS app indicates "Unable to play media. Please try again later". So, could this be an issue with how MM5 ends and starts the next file?